פגמים בלוגיקה עסקית - מה זה ולמה זה מסוכן¶
יש חולשות שקל להסביר בפגישה של חמש דקות - הזרקת SQL, XSS, קלט שלא עבר סניטציה. יש קטגוריה אחרת לגמרי, שקשה יותר להסביר בגלל שאין בה שום דבר "שבור" במובן הטכני. הקוד רץ בדיוק כמו שהוא נכתב, אין באג, אין הודעת שגיאה, ואף כלי סריקה בעולם לא ידווח על שום דבר חריג. ובכל זאת, יש כאן חולשה אמיתית. זה נקרא פגם בלוגיקה עסקית, ואני חושב שזו אחת הקטגוריות המעניינות ביותר בכל תחום האבטחה.
אז מה זה בעצם פגם בלוגיקה עסקית?¶
פגם בלוגיקה עסקית הוא לא באג בקוד - הוא פער בין מה שהמפתחים חשבו שהמשתמש יעשה, לבין מה שהמשתמש יכול בפועל לעשות. הפיצ'ר עצמו תקין לגמרי מבחינה טכנית. הבעיה היא שהוא נבנה סביב הנחה שקטה שאף אחד לא כתב במפורש, ותוקף שמבין את זרימת המערכת לעומק מוצא את הדרך לעקוף בדיוק את ההנחה הזאת.
תחשבו על זה כמו על משחק עם חוקים מוגדרים היטב, אבל בלי בורר. אם אף כלל לא נשבר טכנית, אבל השחקן מצא דרך לנצח בצורה שהמעצבים של המשחק בכלל לא דמיינו, זו בדיוק התחושה של פגם בלוגיקה עסקית.
דוגמאות שממחישות את זה¶
- שימוש חוזר בקוד הנחה. קופון שאמור להיות חד-פעמי, אבל הבדיקה נעשית רק בצד הלקוח, או שהשרת לא נועל אותו אחרי שימוש ראשון - כך אפשר להפעיל אותו שוב ושוב.
- שינוי מחיר או כמות בצד הלקוח. תהליך תשלום ששולח את המחיר הסופי כפרמטר מהדפדפן, ומצפה מהשרת רק "לקרוא" אותו במקום לחשב אותו מחדש.
- דילוג על שלב בתהליך רב-שלבי. תהליך הרשמה או רכישה שבנוי מכמה שלבים, כשכל שלב שולח בקשה נפרדת, אבל השרת לא בודק אם השלבים הקודמים באמת הושלמו - אז אפשר לקפוץ ישר לשלב האחרון.
- מספרים שליליים במקומות לא צפויים. מערכת שמאפשרת להזין כמות מוצרים או סכום העברה, ומניחה שהערך תמיד חיובי - הזנת מספר שלילי לפעמים הופכת חיוב לזיכוי, בגלל שאיש לא חשב לבדוק את הכיוון ההפוך.
חשוב להדגיש - אלה דוגמאות עקרוניות שמטרתן להמחיש את הקטגוריה, לא מדריך יישום נגד מערכת אמיתית כלשהי.
למה כלים אוטומטיים עיוורים לזה לגמרי¶
סורק אוטומטי עובד לפי חתימות ודפוסים - הוא מחפש קלט שגורם לשגיאה, תבנית שמזכירה הזרקה, תשובת שרת שחורגת מהצפוי. בפגם בלוגיקה עסקית שום דבר מהדברים האלה לא קורה. הבקשה תקינה מבחינה תחבירית, השרת מגיב בדיוק כמו שהוא אמור להגיב, ואין אף חתימה שמתאימה לשום מסד נתונים של חולשות ידועות. אין CVE לפגם הזה, כי הוא לא קיים בספרייה או בגרסת תוכנה - הוא קיים רק בהקשר הספציפי של האפליקציה הזאת.
זו הסיבה שאי אפשר "לסרוק" את זה. צריך בן אדם שיושב, מבין את הזרימה המלאה של המערכת - מה קורה בין שלב א' לשלב ב', מה השרת בעצם סומך עליו ומה הוא בכלל לא בודק - ואז מנסה בכוונה לשבור את ההנחה הזאת.
למה זה כל כך אהוב על בודקים מנוסים¶
זו בדיוק הסיבה שפגמים בלוגיקה עסקית הם חתימה של בודק מנוסה. מתחילים נוטים לרדוף אחרי חולשות עם שם מוכר, כי קל לחפש אותן לפי רשימה. בודק שכבר עבר את השלב הזה מפסיק לחפש "סוג חולשה", ומתחיל לשאול שאלה אחרת לגמרי - מה המערכת הזאת מניחה עליי כמשתמש, ומה קורה אם אני לא מתנהג בדיוק כמו שהיא ציפתה. השאלה הזאת, יותר מכל כלי, היא מה שמוביל לממצאים שאף אחד אחר לא מצא לפני.
זה בדיוק סוג החשיבה שאנחנו מתרגלים לעומק בקורס פריצת אתרים מתקדם, עם דגש על להבין את הזרימה של המערכת לפני שמחפשים איפה היא שוברת.
ואם אתם רוצים לתרגל את סוג החשיבה הזה יחד עם אנשים אחרים - זה בדיוק מה שקורה אצלנו בדיסקורד.
לסיכום¶
פגם בלוגיקה עסקית הוא תזכורת לכך שאבטחה היא לא רק שאלה של קוד נקי, אלא שאלה של הבנה מלאה של איך המערכת אמורה להתנהג. אין שם באג טכני למצוא, יש רק הנחה שקטה שאף אחד לא בדק אם היא באמת מחזיקה מים. מי שלומד לחפש את ההנחות האלה, מגלה שיש שם עולם שלם שהכלים האוטומטיים פשוט לא רואים.