איפה מתחילים להסתכל על אבטחת מידע של מערכת?
רוב המערכות שיהיו מעניינות מספיק כדי שיהיה שווה לפרוץ אליהן כוללות גם מספיק קוד כדי שיהיה קל ללכת לאיבוד בקריאה שלו. כשאנחנו מחפשים בעיות אבטחת מידע במערכת ויש לנו את הקוד שלה, צריך לדעת איך להסתכל אבל גם איפה. אלה המקומות שאני מתחיל בהם, תרגישו חופשי להוסיף הצעות שלכם בתגובות:
1. מידע שנראה סודי
קבצים שהשם שלהם מכיל את המילה secret, ערכים שמכילים את המילה password או secret או token או כל מידע בסגנון הזה שנראה לכם שלא צריכה להיות גישה אליו אבל דווקא יש. בהקשר הזה "קוד" כולל גם את ה Git Repository שלכם וגם את כל הקבצים הגלויים בשרת.
כך במקרה אחד מתכנת ב Uber העלה בטעות את הסיסמא לבסיס הנתונים למאגר גיטהאב, וחוקרים אחרים מצאו מעל 1,500 פרטי גישה רק מחיפוש בגיטהאב לפי הכתבה כאן:
במקרה אחר כל פרטי הגישה של יצרנית צעצועי המין Vibratissimo הופיעו כקובץ פתוח לקהל הרחב באתר שלהם:
2. מנגנוני אבטחה מנוטרלים
הדבר השני שצריך להדליק נורות אדומות הוא מקרים שיש מנגנון אבטחה Built In בפריימוורק ומישהו בכוונה ביטל אותו. כשמישהו משתמש בפקודה dangerouslySetInnerHTML בריאקט זה מקום טוב להתחיל לחשוד (יש סיבה שהם קראו לזה Dangerously). אותו דבר כשמישהו משתמש ב @Raw ב ASP.NET או יוצר שאילתת SQL באמצעות שירשור מחרוזות למשל הקוד הבא בריילס:
User.where("name like '%#{name}%'")
תבניות שמאפשרות לנו לעקוף מנגנוני הגנה צריכות להיות עטופות במנגנוני הגנה חלופיים, וכשאתם רואים חורים כאלה בגדר זאת נקודה שכדאי לחקור אותה יותר לעומק.
3. היעדר גבולות
באחת הפעמים שהשתמשתי ב Wordpress עבור אתר קניתי עיצוב מדליק מהאינטרנט ומערכת הניהול שם כללה קוד שנראה קצת דומה לקטע הבא:
if ($_POST['url']) {
$uploaddir = $_POST['url'];
}
$first_filename = $_FILES['uploadfile']['name'];
$filename = md5($first_filename);
$ext = substr($first_filename, 1 + strrpos($first_filename, '.'));
$file = $uploaddir . basename($filename . '.' . $ext);
if (move_uploaded_file($_FILES['uploadfile']['tmp_name'], $file)) {
echo basename($filename . '.' . $ext);
} else {
echo 'error';
}
קל לראות שאין כאן שום בדיקה על סוג הקובץ שנשמר, ואכן הקוד הזה שימש נקודת כניסה לפורצים להיכנס לאתר באמצעות העלאת קובץ PHP לשרת.
במקרה אחר רן בר זיק סיפר על בעיית אבטחה באתר הבית היהודי שחשפה את מספרי הזהות והכתובות של כל המתפקדים. הסיבה היתה היעדר הגבלה על מספר השאילתות שגולש יכול לבצע, מה שאיפשר לכל אחד להריץ בוטים שישתו מהאתר את כל המידע. כשאתר אינטרנט פותח גישה למאגר מידע צריך לוודא שיש הגבלה על כמה פניות כל גולש יכול לשלוח. זה הקישור לפוסט המקורי של רן:
4. קוד שלא מגיעים אליו
ככל הנראה קוד שנמצא ממש בדלת הראשית של המערכת כבר נחקר, נוסה, נבדק ותוקן עוד לפני שהגעתם. הרבה יותר משתלם לחפש בעיות בקוד שאף אחד לא מסתכל עליו - למשל קוד שרת שבכלל לא מחובר ל GUI, או מקרי קצה שבעבודה רגילה דרך הממשק אי אפשר להגיע אליהם.
ביישום צד שרת כדאי לחפש נתיבים שאין תפריט שמגיע אליהם, וכדאי לחפש מה קורה כשמישהו פונה לנתיב יותר מדי פעמים או במקביל. במקרה מפורסם אחד איגור חמקוב הצליח לעקוף את מערכות ההגנה של Starbucks רק דרך פניה לשרת שלהם דרך סקריפט וממספר תהליכים במקביל במקום דרך הממשק, והוא מספר על זה כאן:
https://sakurity.com/blog/2015/05/21/starbucks.html
5. אינטגרציה בין מערכות
עוד מקום שמתכנתים נופלים בו הוא החיבור בין מספר מערכות. כאן הכלל היחיד הוא להיכנס לעובי הקורה כל פעם שאתם רואים מערכות שאמורות לתקשר ביניהן ולהבין איך המערכות (שרצות על מכונות נפרדות) מתקשרות? איך מערכת אחת סומכת על השניה? והאם אפשר לגרום למערכת אחת לחשוב שהיא קיבלה הודעה מהשניה למרות שלא היו דברים מעולם?
כך לדוגמא גירסאות ישנות של המודול paypal-ipn ב Node נעזרו בפרמטר שנקרא test_ipn כדי לדעת אם הודעה הגיעה לשרת מפייפאל האמיתי או מהסימולטור. פורץ מתוחכם יכל היה לזייף את הפרמטר הזה כדי לגרום לשרת לחשוב שהוא עובד מול הסימולטור, גם אם השרת נמצא כרגע במצב Production, וכך לאשר דיווחים על עיסקאות שמעולם לא התבצעו. פרטים על תקלה זו בדף האזהרה של npm כאן:
https://www.npmjs.com/advisories/26
6. היעדר מנגנוני אבטחה שהייתם מצפים למצוא
יש מספר מנגנוני אבטחה שאנחנו מצפים למצוא בכל יישום Web - למשל אנחנו מצפים שסיסמאות יוצפנו בבסיס הנתונים, אנחנו מצפים שכל הטפסים יהיו מוגנים מפני CSRF ושפרטי הגישה לבסיס הנתונים יהיו מוחבאים, אנו מצפים ש HTTP Headers מסוימים יישלחו ואחרים לא יישלחו וכן הלאה.
כל מנגנון אבטחה כזה שאנחנו מצפים למצוא מחביא מאחוריו סיפור שלם של בעיות אבטחה שהוא אמור למנוע. אם הגעתם למערכת וראיתם שהיא לא משתמשת ב CSP אפשר להתחיל לחשוד. אם הגעתם למערכת וראיתם שהשגיאות בה מופיעות על המסך או נשלחות לגולש כדאי להתחיל לחשוד.
חושבים שאתם יודעים למצוא בעיות אבטחה ביישומים, ורוצים לספר על זה ולהרשים אותי ואת החברים שלכם? הנה מערכת ווב קטנה שכתבתי לקראת הוובינר מחר - מוזמנים למצוא בה בעיות ולהצטרף לוובינר לספר עליהן ולשמוע את התקלות שאחרים מצאו: