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

כל אתר שאתם פותחים שולח לכם קוד. לא רק HTML ו-CSS, אלא לרוב גם עשרות או מאות קבצי JavaScript, חלקם מקוצרים (minified), חלקם ארוזים (bundled) לתוך קובץ ענק אחד. רוב האנשים רואים את זה כרעש. חוקרי אבטחה רואים בזה מכרה זהב. ניתוח סטטי של JavaScript - כלומר קריאה של הקוד בלי להריץ אותו ובלי לשלוח אף בקשה חריגה לשרת - הוא אחת השיטות היעילות ביותר לאיסוף מידע על אתר, והיא לגמרי חוקית ופסיבית כשעושים אותה על מטרה שאתם מורשים לבדוק.

למה קוד קליינט הוא מקור מידע כל כך טוב¶

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

מה בדיוק מחפשים¶

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

מפתחות API וסודות שהוטמעו בטעות. מפתחות של שירותי צד שלישי, טוקנים, ולפעמים אפילו פרטי חיבור למסדי נתונים - כל אלה מוצאים את דרכם לקוד קליינט יותר ממה שאפשר לחשוב, בדרך כלל כי מישהו העתיק קוד מהשרת בלי לחשוב פעמיים.
אנדפוינטים חבויים. קוד ה-JS מכיל כמעט תמיד את כל כתובות ה-API שהאתר משתמש בהן, כולל כאלה שלא מוצגות בממשק לכל המשתמשים - פיצ'רים בפיתוח, פאנלים לאדמינים, או גרסאות ישנות של API שנשארו פעילות.
דגלי פיצ'רים - Feature Flags. משתנים כמו isAdmin, betaFeatures או debugMode חושפים לפעמים פונקציונליות שאמורה להיות חסומה, ומרמזים על איך הרשאות נבדקות בצד הקליינט - מה שלרוב אומר שהן לא באמת נבדקות מספיק בצד השרת.
הערות של מפתחים. "TODO: לזכור להסיר את זה לפני production" זו משפט שממש שווה לחפש. מפתחים משאירים הערות שמסבירות למה קוד מסוים קיים, מה הוא אמור לעשות, ולפעמים אפילו איך לעקוף אותו.
מפות מקור - Source Maps. אם קובץ .js.map נשאר נגיש בפרודקשן, אפשר להשתמש בו כדי לשחזר את קוד המקור המקורי - כולל שמות משתנים, מבנה תיקיות, ולפעמים קבצי קונפיגורציה שלמים שלא היו אמורים להיחשף.

איך עושים את זה בפועל¶

התהליך לא דורש כלים מיוחדים - כלי הפיתוח שמובנים בכל דפדפן מספיקים לגמרי:

פותחים את לשונית ה-Network או את ה-Sources ב-DevTools, וסוקרים את כל קבצי ה-JS שהאתר טוען.
כשקובץ מקוצר וקשה לקריאה, מריצים אותו דרך כלי לניפוי קוד (beautifier/prettifier) שמחזיר אותו למבנה קריא עם ירידות שורה והזחות.
מחפשים מילות מפתח כמו api, key, token, secret, admin, endpoint בתוך הקוד המנופה.
בודקים אם קיימות מפות מקור נגישות, שיכולות לחשוף את מבנה הפרויקט המקורי כמעט במלואו.
שומרים רשימה מסודרת של כל האנדפוינטים שנמצאו, כדי להשתמש בה בשלבי הבדיקה הבאים.

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

למה זה נחשב לשלב חוקי ופסיבי, ואיפה הגבול¶

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

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

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

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

הצטרפו לקהילה בדיסקורד

לסיכום¶

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