פותרים אתגר CTF ראשון בווב - השיטה שעובדת, לא המזל¶
יש מיתוס נפוץ שאני שומע כל הזמן ממתחילים ב-CTF - שכדי לפתור אתגר צריך "לדעת האקינג" ברמה מיסטית, איזה קסם שרק אנשים מסוימים מחזיקים. זה שטויות. פתרון אתגר Web ראשון הוא בעיקר עניין של שיטה. אם תעברו על אותם שלבים בסדר, בעקביות, תפתרו את רוב האתגרים למתחילים בעצמכם, בלי לחפש walkthrough בגוגל אחרי חמש דקות.
לפני שמתחילים, הערה קצרה שחשוב לומר - כל התרגול הזה עושים על פלטפורמות מיועדות כמו TryHackMe או picoCTF, או על מערכות שאתם הקמתם בעצמכם. לעולם לא מנסים את הטכניקות האלה על אתר אמיתי של מישהו אחר בלי אישור מפורש. זה לא רק עניין אתי, זו גם עבירה פלילית.
שלב 1 - קוראים את התיאור פעמיים¶
זה נשמע מובן מאליו, אבל זו הטעות הכי נפוצה שאני רואה. אנשים קופצים ישר לאתגר, נתקעים אחרי עשר דקות, ואז חוזרים לקרוא את התיאור ומגלים שהיה שם רמז ברור שהם דילגו עליו. לפני שנוגעים בכלום, תקראו את שם האתגר, התיאור, והקטגוריה. הם כמעט תמיד מכוונים אתכם לכיוון הנכון.
שלב 2 - מסתכלים על קוד המקור¶
זה הצעד הראשון בכל אתגר Web בלי יוצא מן הכלל. פותחים View Source ומחפשים הערות שנשארו בטעות, קישורים לקבצים נסתרים, שדות טופס מוסתרים, או קוד JavaScript שמריץ לוגיקה בצד הלקוח. מתכנתים משאירים הרבה יותר עקבות בקוד מקור ממה שהם חושבים, ובאתגרי CTF זה כמעט תמיד מכוון.
שלב 3 - נכנסים ל-DevTools ברצינות¶
לשונית ה-Network מראה לכם כל בקשה שהדפדפן שולח - כולל בקשות שקורות ברקע בלי שראיתם אותן. תבדקו אילו פרמטרים נשלחים, אילו כותרות (headers) חוזרות, ואיזה עוגיות (cookies) נשמרות. הכרטיסייה Application או Storage מראה לכם local storage ו-cookies בצורה נוחה. הרבה אתגרים מסתתרים בדיוק שם - ערך בעוגייה שאפשר לשנות, טוקן שנראה כמו מחרוזת רנדומלית אבל בעצם הוא Base64 מקודד.
שלב 4 - מחפשים קבצים וכתובות נפוצות¶
יש רשימה קצרה של כתובות שכדאי לבדוק כמעט תמיד: robots.txt, sitemap.xml, תיקיית .git חשופה, קבצי גיבוי כמו index.php.bak, ותיקיות ניהול כמו /admin. זה לא ניחוש פרוע - אלה טעויות תצורה נפוצות מאוד גם באתרים אמיתיים, ולכן אתגרי CTF אוהבים לדמות אותן.
שלב 5 - בודקים את החולשות הקלאסיות¶
אחרי שסקרתם את השטח, מגיע הזמן לנסות חולשות נפוצות. הזרקת SQL - הכנסת גרש בודד לשדה קלט ובדיקה אם משהו נשבר. IDOR, כלומר שינוי מזהה בכתובת (למשל user_id=5 ל-user_id=6) כדי לראות אם המערכת בודקת הרשאות בכלל. עקיפת אימות פשוטה, כמו שינוי ערך role=user ל-role=admin בעוגייה. אלה לא תרגילים תיאורטיים - הם בדיוק אותן חולשות שמופיעות שוב ושוב ב-OWASP Top 10.
שלב 6 - קוראים הודעות שגיאה במקום להתעלם מהן¶
הודעת שגיאה עם stack trace שלם היא מתנה. היא חושפת שם קובץ, שאילתת SQL, או גרסת ספרייה. במקום להיבהל מטקסט אדום, תקראו אותו מילה במילה - הרבה פעמים הפתרון כתוב שם ממש.
המלכודת הכי נפוצה¶
מתחילים נוטים לחשוב שהם צריכים כלי מתקדם או סקריפט מורכב כדי לפתור אתגר. ברוב המקרים ההפך הוא הנכון - הפתרון נמצא בהתבוננות פשוטה ועקבית, לא בכלי קסם. אם אתם תקועים יותר מ-20-30 דקות, זה סימן טוב לחזור צעד אחד אחורה ולבדוק שוב את מה שכבר ראיתם, לא לקפוץ לכיוון חדש לגמרי.
מה מרוויחים מזה¶
מעבר לפתרון האתגר עצמו, מה שנבנה כאן זה הרגל חשיבה - איך לפרק בעיה לא מוכרת לשלבים ברורים, איך לחפש עקבות בשיטתיות, ואיך לא להיבהל מממשק חדש. זו בדיוק אותה מיומנות שנדרשת בבדיקות חדירה אמיתיות, ולכן אתגרי CTF הם דרך כניסה כל כך טובה לתחום.
אם אתם רוצים לבנות את הבסיס הזה בצורה מסודרת, עם הסבר על החולשות שעליהן מתבססים רוב האתגרים, מוזמנים להעיף מבט על קורס בדיקות החדירה שלנו - הוא בדיוק בנוי כדי לקחת אתכם מהבנת היסודות ועד יכולת אמיתית לפרק אתגרים כאלה לבד.
יש לכם אתגר ספציפי שאתם תקועים בו? שווה לשאול קהילה במקום להתייאש לבד.