הסבר על ReDoS: מהו DoS של ביטוי רגולרי וכיצד למנוע זאת

DoS של ביטויים רגילים (ReDoS) הוא סיכון הולך וגדל בתוך אבטחת יישומים מודרניתככל שיותר ויותר צוותים מסתמכים על אימות קלט והתאמת תבניות, רגנקס גרוע יכול להציג פגיעויות ביצועים שתוקפים יכולים לנצל כדי להאט שירותים או לגרום להפסקות פעילות. למעשה, OWASP מתאר את ReDoS כמתקפת מניעת שירות המנצלת את העובדה שמימושים רבים של ביטויים רגולריים יכולים להיות איטיים ביותר, לפעמים עם זמן ריצה שגדל באופן אקספוננציאלי עם גודל הקלט.

במקביל, התקפות ReDoS מסוכנות במיוחד במערכות ענן מקוריות ו- CI/CDסביבות מונחות, שבהן רגסקס פגיע יחיד ב-API, שער או זרימת אימות יכול להשפיע על הזמינות בקנה מידה גדול. מסיבה זו, צוותים צריכים להתייחס ל-ReDoS כאל סיכון זמינות אמיתי, ולא רק כאל מקרה בקצה הנישה.

חשוב מכך, פגיעויות אלו לרוב נותרות בלתי מזוהות במהלך הפיתוח, מכיוון שגישות מסורתיות מתמקדות בתחביר ולא בהתנהגות הביצוע. כתוצאה מכך, תבניות רגולריות לא יעילות יכולות להגיע בקלות למצב ייצור מבלי להעלות התראות.

כאן נכנסות לתמונה פלטפורמות AppSec מודרניות כמו Xygeni. על ידי הטמעת בדיקות אבטחה ישירות בתהליכי עבודה של פיתוח, הן עוזרות לחשוף בעיות אלו מוקדם יותר ולתעדף את הסיכונים שבאמת ניתנים להשגה ובעלי השפעה, במקום פשוט לייצר עוד רעש.

מה זה ReDoS (ביטוי רגולרי DoS)?

ReDoS (מניעת שירות של ביטויים רגילים) היא פגיעות המתרחשת כאשר תבנית ביטוי רגולרי גורמת למעקב חוזר מוגזם, מה שמוביל לזמן ביצוע אקספוננציאלי.

במילים פשוטות, קלט זדוני יכול לאלץ את האפליקציה שלך להשקיע כמות קיצונית של זמן בהערכת ביטוי רגולרי, לחסום את המערכת ולפגוע בביצועים.

לדוגמה, תבניות עם כמותיות מקוננות כמו:

				
					(a+)+

יכול להפוך לבלתי יעיל ביותר בעת עיבוד קלטים מסוימים, במיוחד כאשר הם נוצרו במכוון על ידי תוקף.

למרות שזה אולי נראה כמו מקרה קצה, זה נפוץ באופן מפתיע ביישומים בעולם האמיתי, במיוחד בלוגיקת אימות, קלט טפסים וטיפול בבקשות API.

כיצד פועלות מתקפות ReDoS

מתקפת ReDoS אינה דורשת ניצול מתקדם. במקום זאת, היא מנצלת לרעה את התנהגות מנוע ה-regex הצפויה.

חזרה קטסטרופלית

התוקף מכוון לביטוי רגולרי שיכול לקחת מספר נתיבים תואמים. לאחר מכן הוא מספק קלט שמאלץ את המנוע לחקור את רוב או את כל הנתיבים.

קלט שנוצר על ידי תוקפים

תוקפים בדרך כלל שולחים:

מחרוזות ארוכות עם תווים חוזרים.
קלט שכמעט תואם, ואז נכשל בסוף.
עומסי מטען המתמקדים בחלק המעורפל ביותר של התבנית.

ירידה בביצועים

מכיוון שכל בקשה יכולה לשרוף את המעבד, האפקט מצטבר במהירות:

השהייה גבוהה יותר בין נקודות קצה.
תשישות מאגר השרשור.
לולאת אירועים נתקעת בזמני ריצה בעלי הליך משנה יחיד.

התקפות אלו אינן דורשות פרצות מורכבות. במקום זאת, הן מנצלות התאמת תבניות לא יעילה, מה שמקשה על זיהוין אם הכלים שלכם בודקים רק תחביר או CVE ידועים.

ההשפעה של פגיעויות ReDoS על העולם האמיתי

ReDoS מגיע למקום ה-A בשלישייה של ה-CIA: זמינות. זה יכול להיראות כמו בעיית יציבות, לא תקרית אבטחה, עד שמחברים את הנקודות.

האטה ב-API

נקודת קצה יחידה המשתמשת בביטוי רגולרי פגיע עלולה להגביר את עוצמת המעבד במהלך אימות קלט, ניתוב בקשות או בדיקות אימות.

הפסקת שירות

תחת עומס, נקודה חמה של ReDoS יכולה לגרום להפעלה מחדש של פודים, לפגוע בקנה מידה אוטומטי ולגרום לכשלים מדורגים.

מיצוי משאבים

ReDoS יכול לצרוך:

מעבד בצמתי האפליקציה.
זיכרון עקב מצב מעקב אחורה.
שרשורי עובדים שחוסמים בקשות אחרות.

מכיוון ש-ReDoS מתמקד בביצועים ולא בחשיפת נתונים, צוותים רבים ממעיטים בחשיבותו. עם זאת, זמינות היא חלק מרכזי באבטחת יישומים, ושיבושים עלולים להתבטא במהירות בסיכון עסקי.

שבירת שינויים היא בעיית האמון האמיתית

כאשר מפתחים אומרים שהם לא סומכים על autofix, הם מתכוונים לעתים קרובות לדבר ספציפי אחד: הם לא סומכים עליו שלא ישבור משהו.

בעיית האמון הזו בולטת ביותר בתיקון תלות.

ייתכן שלחבילה פגיעה יש גרסה מתוקנת זמינה, אך אין זה אומר שהשדרוג בטוח. הגרסה המתוקנת עשויה להסיר שיטה שהאפליקציה שלך משתמשת בה. היא עשויה לשנות שם של ממשק API. היא עשויה להדק חוזה סוג. היא עשויה לשנות התנהגות באופן שעובר מבחני יחידה אך גורם לרגרסיות ייצור. בצוותים רבים, העלות בפועל של תיקון אינה החלת התיקון. היא חקירת רדיוס הפיצוץ.

קחו לדוגמה דוגמה פשוטה בג'אווה. בסיס קוד תלוי בספרייה שבה מתודה נפוצה קיימת בגרסה 1.x אך הוסרה בגרסה 2.x.

מתקפות ReDoS ואירועי אבטחה בעולם האמיתי

ReDoS אינו רק פגיעות תיאורטית. היא נוצלה ביישומים בעולם האמיתי, ומשפיעה על ספריות ומערכות ייצור הנמצאות בשימוש נרחב.

הנה כמה דוגמאות בולטות המדגישות את ההשפעה של דפוסי רגולציה לא יעילים:

פגיעות ב-Moment.js ReDoS

אחת מפגיעויות ReDoS הידועות ביותר שנפגעו Moment.js, ספריית תאריכים ב-JavaScript הנמצאת בשימוש נרחב.

תבנית רגולציה שתוכננה בצורה גרועה גרמה למעקב חוזר מוגזם
תוקפים עלולים לגרום לשימוש גבוה במעבד באמצעות קלט בעל מבנה
יישומים המשתמשים ב-Moment.js הפכו פגיעים לתנאי מניעת שירות

בעיה זו הדגימה כיצד אפילו ספריות מהימנות יכולות להכניס פגיעויות מבוססות ביצועים לאלפי יישומים.

ספריית אימות Node.js (validator.js)

דוגמה נוספת מעורבת validator.js, המשמש בדרך כלל לאימות קלט.

פונקציות אימות מסוימות הסתמכו על ביטוי רגולרי לא יעיל
קלט זדוני עלול לעכב משמעותית את הביצוע
זה השפיע על ממשקי API ושירותי backend המסתמכים על אימות קלט מהמשתמש

מכיוון ש-validator.js נמצא בשימוש נרחב, ההשפעה התפשטה על פני יישומים ושירותים מרובים.

הפסקת פעילות Cloudflare (כשל מבוסס Regex)

אירוע מתוקשר Cloudflare, שבו תבנית רגולציה פגומה גרמה להפסקה משמעותית.

ביטוי רגולרי שנפרס בסביבת הייצור גרם לשימוש מופרז במעבד
מערכות הפכו ללא מגיבות באופן גלובלי
חלקים גדולים מהאינטרנט הושפעו זמנית

למרות שלא מדובר בהתקפה זדונית, אירוע זה מראה בבירור כיצד חוסר יעילות של ביטויים רגולריים (regex) יכול להיות בעל השלכות בעולם האמיתי ובקנה מידה גדול.

מדוע כלי אבטחה מסורתיים מפספסים את ReDoS

זהו סעיף ההמרה מכיוון שהוא מסביר את הפער שרוב הצוותים חשים: סורקים רצים, dashboardמילוי, ו-ReDoS עדיין מחליק דרכו.

כלים סטטיים מתמקדים בתחביר

סורקים רבים יכולים לסמן "תבניות רגולריות מסוכנות", אך לעתים קרובות הם חסרים ביטחון לגבי האם התבנית באמת ניתנת לניצול בהקשר שלך.

אין הקשר ביצוע

ReDoS עוסק בהתנהגות בזמן ריצה. OWASP מציין כי מימושים רבים של רגאקס יכולים להגיע למצבים קיצוניים ולעבוד לאט מאוד, לפעמים ביחס אקספוננציאלי לגודל הקלט.
אם כלי לעולם לא יחשוב על צורת הקלט, תנאי כשל בהתאמה או נתיבי ביצוע, הוא יפספס את הסיכון או יטביע אתכם בתוצאות חיוביות שגויות.

אין ניתוח ניצול

רגנקס יכול להיות "מסוכן תיאורטית" אך בלתי ניתן להשגה בפועל. לעומת זאת, אימות "קטן" בנקודת קצה ציבורית יכול להיות תקרית של ממש. ללא הקשר, צוותים מתעלמים מהתראות או מתקנים יתר על המידה.

סורקים מסורתיים לעיתים קרובות נכשלים בזיהוי ReDoS מכיוון שהם אינם מעריכים כיצד ביטויים רגולריים מתנהגים בזמן ריצה או בתנאי קלט זדוניים. כאן פלטפורמות כמו Xygeni עושות את ההבדל על ידי שילוב ניתוח עם הערכת סיכונים קונטקסטואלית, ועוזר לצוותים להבין האם חולשה אכן ניתנת להשגה ובעלת השפעה.

כיצד לזהות פגיעויות ב-ReDoS

ניתן לזהות ReDoS באמצעות שילוב של תחום עיצוב ובדיקות. בנוסף, תרצו בדיקות שרצות באופן רציף, לא רק במהלך סקירת אבטחה.

עיצוב רגולרי מאובטח

התחילו עם תבניות שממזערות עמימות. הימנעו מכמתים מקוננים וחלופות חופפות.

ערפול ובדיקה

בדיקת תבניות רגולריות עם:

קלט ארוך מאוד.
קלטים כמעט-החמצתיים שנכשלים באיחור.
אסימונים חוזרים שנועדו להפעיל מעקב אחורה.

ניתוח סטטי

השתמש בניתוח שמסמן מבנים ודפוסים מסוכנים ידועים התואמים ל CWE-1333.

אימות בזמן ריצה

החל מגבלות אורך קלט וטיולי זמן סביב הערכת ביטויים רגולריים במידת האפשר. הנחיות אימות קלט של OWASPe מזהיר במפורש מפני ReDoS ומדגיש את החשיבות של הגדרת אורך קלט מינימלי ומקסימלי.

פתרונות AppSec מתקדמים כמו Xygeni חורגים מזיהוי תבניות על ידי... ניתוח קוד בהקשר של זרימת עבודה ולסייע לצוותים להתמקד בנושאים שסביר להניח שחשובים להם בתרחישים אמיתיים, מה שמפחית תוצאות חיוביות שגויות ומאיץ את התיקון.

כיצד למנוע התקפות ReDoS

מניעה היא שילוב של דפוסים בטוחים יותר, קלט בטוח יותר ובחירות זמן ריצה בטוחות יותר.

הימנעו מכימותים מקוננים

חזרה מקוננת יוצרת לעתים קרובות את פיצוצי המעקב הגרועים ביותר.

הגבלת גודל הקלט

זוהי דרך ההפחתה הפשוטה והאמינה ביותר. קבעו מגבלות אורך מקסימליות עבור קלטים שעוברים אימות רגולקס. OWASP מדגיש את מגבלות האורך כחלק מרכזי באימות קלט בטוח.

השתמש במנועי regex בטוחים במידת האפשר

כאשר אתם יכולים לבחור את המנוע, העדיפו מנוע שתוכנן למנוע חזרה למסלולו בצורה קטסטרופלית. RE2 של גוגל ממוקמת כחלופה בטוחה למנועי רגולקס חוזרים.

אימות קלטים באמצעות בדיקות שכבתיות

אל תסתמך על רֶגֶקס יחיד לכל האימות. שלב:

רשימות היתרים של דמויות,
בדיקות אורך קפדניות,
ודפוסים פשוטים יותר לכל שדה.

מניעת ReDoS דורשת שיטות קידוד מאובטחות ו אימות מתמשך לאורך מחזור חיי הפיתוח, במיוחד ככל שיישומים גדלים והתלות שלהם גדלה.

כיצד Xygeni מסייע בזיהוי ומניעת ReDoS

Xygeni עוזרת לצוותי DevSecOps לזהות ולמנוע פגיעויות ReDoS על ידי שילוב של שכבות ניתוח מרובות.

יכולות מפתח כוללות:

זיהוי דפוסי רגולקס פגיעים במהלך הפיתוח
ניתוח זרימות נתונים ונתיבי ביצוע
זיהוי פגיעויות הניתנות לניצול, לא רק תיאורטיות
אינטגרציה לתוך CI/CD pipelines לסריקה רציפה
הנחיות יישומיות לתיקון למפתחים

במקום להציף צוותים בהתראות, Xygeni נותנת עדיפות ל... פגיעויות שבאמת ניתנות להשגה ובעל השפעה.

זה מאפשר לצוותים לתקן בעיות אמיתיות מהר יותר, מבלי להאט את הפיתוח.

שיטות עבודה מומלצות עבור צוותי DevSecOps

אבטחה Shift-left

הפוך את בדיקות ReDoS לחלק מאותה שגרה כמו סקירת קוד ובדיקות יחידה.

סריקה אוטומטית

בצע בדיקות על כל pull request כך שסיכון רגולרי אינו ממתין לבדיקות תקופתיות.

ניטור תלויות

פגיעויות של תגובות רגולריות מופיעות גם בתלות ובספריות ניתוח קלט, לכן יש לשמור על היגיינת התלות.

אימות קלט באופן רציף

החל מגבלות אורך וכללי קלט בקצוות, ולאחר מכן אימות שוב בתוך שירותים קריטיים.

על ידי הטמעת אבטחה ישירות בזרימות עבודה של פיתוח, צוותים יכולים למנוע פגיעויות מבוססות ביצועים כמו ReDoS לפני שהן מגיעות למצב הייצור.

מניעת ReDoS מתחילה בנראות ללא צל

ReDoS לעיתים קרובות מתעלמים ממנו, אך יכולה להיות לו השפעה משמעותית על ביצועי וזמינות היישומים. OWASP מתאר את ReDoS כסיכון של מניעת שירות שמקורו בהתנהגות זמן ריצה קיצונית של ביטויים רגולריים.
זה אומר שאתם צריכים יותר מסריקה בסיסית. אתם צריכים הקשר, תעדוף ואוטומציה.

אם תתייחסו ל-regex כמו לקוד שעלול להיכשל תחת קלט הנשלט על ידי תוקף, תזהו את ReDoS מוקדם יותר ותשלחו מערכות בטוחות יותר. בעזרת Xygeni, צוותים יכולים להפחית רעש, לתעדף סיכונים אמיתיים ולחזק את בקרות ה-AppSec בפנים. CI/CD זרימות עבודה.

סיכום

קל להציג פגיעויות ב-ReDoS וקשות לגילוי ללא ההקשר הנכון.

בעוד שכלים מסורתיים מתמקדים בזיהוי בעיות, AppSec מודרני דורש הבנה של אילו נקודות תורפה באמת חשובות.

לכן, כדי להישאר צעד אחד קדימה, צוותים זקוקים לנראות, קביעת סדרי עדיפויות ואוטומציה, תוך שיתוף פעולה לאורך מחזור חיי הפיתוח.

כאן Xygeni עושה את ההבדל. על ידי התמקדות בסיכונים הניתנים לניצול, היא עוזרת לצוותים לזהות בעיות מוקדם יותר, להפחית רעש ולאבטח יישומים משלב הפיתוח ועד לפריסה.

בסופו של דבר, בניית תוכנה מאובטחת כיום פירושה ללכת מעבר לסריקה ולאמץ גישה הקשרית בזמן אמת לאבטחה.

התחילו לבנות יישומים מאובטחים ועמידים עם זיהוי בזמן אמת ואבטחה הקשרית.