| |
יומן אבטחהבלוג אבטחת מידע. עדכונים, עניינים, חדשות ופרסומים. הכל מכל בכל בנושא אבטחת מידע. ופרטיות. |
| 8/2009
הסתרת הודעות שגיאה אפליקטיביות
אני מתנצל מראש על טקסט הכפירה. הכל מתחיל במאמר שפרסם ג'רמיה גרוסמן לפני כחצי שנה וכותרתו SQL Injection, eye of the storm. המאמר עצמו הוא מעין סקירה של ההסטוריה של מתקפות SQL מאז ועד היום וכיצד כיום הן אחת מבעיות האבטחה הבוערות ביותר. בתוך כך מתאר גרוסמן כיצד המעבר לשימוש בטכניקה של הסתרת הודעות שגיאה אפליקטיביות מקשה על בודקים לאתר פרצות אבטחה ומאידך גרם להתפתחות תחום מתקפות חדש של Blind SQL injection, כך שבסופו של תהליך האיזון הופר. במאמר מוסגר יש לציין כי בעוד שתוקף צריך לאתר רק נקודת תורפה אחת, המגן צריך להגן על כולן. וכך כותב גרוסמן (התרגום שלי):
"עודדו בעלי אתרי אינטרנט לעדכן את הקוד ולהחביא הודעות שגיאה על מנת להתגונן כנגד מתקפות הזרקת SQL. רבים הטמיעו בעיקר טכניקה זו כיוון שהיא מחייבת שינוי קונפיגורציה פשוט בלבד, המקשה על הרעים לזהות חולשות SQL. מאחר והחולשות לא קלות לאיתור, ייתכן וזה תרם להכשרה לא נכונה של מפתחים ולתחושה של טכניקה של אבטחה מתוך עמימות (security through obscurity) מספקת".
הוא מוסיף בהמשך המאמר כי הסתרת הודעות השגיאה גם מקשה על תהליכי הבדיקה ומחייבת השקעה נרחבת יותר בבדיקות אבטחה ובבדיקות קוד, כיוון שקשה יותר לעלות על בעיות אבטחה.
לקח לי קצת זמן להבין מה מציק לי במאמר שלו, אבל לבסוף זה קרה. הייתכן שהסתרת הודעות שגיאה אפליקטיביות הייתה שגיאה? הסתרת הודעות השגיאה יצרה מורכבות בעצם ביצוע בדיקות האבטחה ותרומתה לרמת האבטחה בפועל פחותה ממה שנהוג לחשוב עקב פיתוח יכולות משלימות כגון blind sql injection. הייתכן כי דווקא ההמלצה שלנו לארגונים צריכה להיות לחשוף הודעות שגיאה אפליקטיביות על מנת להקל על ביצוע בדיקות אבטחה באמצעות כלים אוטומטיים ובכך לסייע בבדיקות מקיפות יותר של האתר? אני יכול לחשוב על תרחיש אחד לפחות שבו המלצה כזו יכולה להיות יותר מסבירה - כאשר יש פיירוול אפליקטיבי (או מוצר אחר) שיודע להחליף הודעות שגיאה אפליקטיביות בהודעה סטנדרטית, כך שבבדיקות פנימיות אין בעיה לאתר היכן יש בעיות, אך בניסיונות פריצה מבחוץ המידע לא זולג.
מחשבות?
(אגב, שאלתי אותו והתשובה שקיבלתי היא שזו שאלה מורכבת).
| |
| כינוי:
גיל: 50
|
בבלוג זה
בכל הבלוגים
