האם AI יכול לבצע בדיקות חדירה? כך Claude Code, Burp ו-Playwright משנים את עולם ה-Pentesting

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

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

שילוב בין Claude Code, Burp Suite, Playwright ו-MCP מאפשר כיום לבנות סביבת עבודה שבה AI יכול להפעיל אפליקציה דרך דפדפן, לצפות בתעבורת HTTP, לשנות בקשות, לחזור עליהן ואף לבדוק את קוד המקור שמאחורי ההתנהגות שהתגלתה.

לא מדובר בהכרח בתחליף ל-Pentester אנושי. למעשה, השימוש המעניין יותר הוא אחר: לקחת מתודולוגיית בדיקות שאיש אבטחה כבר הגדיר – ולתת ל-AI לבצע אותה באופן עקבי, מתועד וחוזר.

מתחילים מדוגמה קלאסית: IDOR

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

הכלל העסקי פשוט:

משתמש יכול לערוך או למחוק תוכן ששייך לו, אבל לא תוכן של משתמש אחר.

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

אלא שמבחינת אבטחה, זה לא מספיק.

בסופו של דבר, מה שמעניין אותנו הוא לא מה שה-Frontend מאפשר לבצע, אלא מה שהשרת מאפשר לבצע.

נניח שפעולת עריכה שולחת בקשה:

PUT /snippets/123

מה יקרה אם משתמש ישנה את 123 למזהה של רשומה ששייכת למשתמש אחר?

אם השרת אינו בודק את הבעלות על הרשומה, עלולה להיווצר חולשת:

IDOR – Insecure Direct Object Reference

כלומר, משתמש מקבל אפשרות לגשת או לבצע פעולה על אובייקט שאינו שייך לו פשוט באמצעות שינוי מזהה.

כך בודקים את זה ידנית עם Burp Suite

בבדיקת Pentest קלאסית ניתן להעביר את תעבורת הדפדפן דרך Burp Suite.

הבודק מתחבר לאפליקציה, יוצר רשומה ולאחר מכן עורך אותה.

כתוצאה מכך נשלחת בקשת HTTP, לדוגמה:

PUT /snippets/:id

Burp לוכד את הבקשה ומאפשר לשלוח אותה ל-Repeater.

בשלב הבא מאתרים מזהה של רשומה ששייכת למשתמש אחר, מחליפים את ה-ID בבקשה ושולחים אותה מחדש.

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

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

לא רק IDOR: גם Authentication ו-CSRF

אותה מתודולוגיה מאפשרת לבדוק מנגנוני אבטחה נוספים.

לדוגמה, אפשר להחליף את ה-Session Cookie בערך לא תקין ולבדוק האם השרת עדיין מאפשר לבצע פעולה.

אם השרת בנוי נכון, הוא אמור לדחות את הבקשה.

באופן דומה ניתן לבדוק הגנת CSRF.

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

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

לדוגמה, תגובות שגיאה מפורטות מדי עלולות לחשוף מידע כמו:

• שם ה-Framework שבו האפליקציה משתמשת
• שמות ספריות
• נתיבי קבצים פנימיים
• מידע על מבנה השרת
• Stack Traces

זו אינה בהכרח פרצה שמאפשרת להשתלט מיד על המערכת, אבל מדובר ב-Information Disclosure – חשיפת מידע שמספק לתוקף הקשר טכני מיותר על המערכת שעשוי לשמש אותו בעתיד.

עכשיו נותנים ל-AI לבצע את אותה הבדיקה

עד כאן מדובר ב-Pentesting רגיל, אבל…. לא לשם כך התכנסנו 🙂

החלק המעניין מתחיל כאשר מחברים את Claude Code לאותם הכלים שבהם משתמש הבודק.

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

לשם כך ניתן לחבר אליו שני רכיבים מרכזיים:

Playwright MCP ו-Burp MCP.

Playwright MCP: לתת ל-AI שליטה בדפדפן

Playwright מאפשר לאוטומציה לשלוט בדפדפן באופן מלא.

באמצעותו Claude Code יכול, למשל:

• לפתוח את האפליקציה
• לבצע Login
• לנווט בין עמודים
• למלא טפסים
• ללחוץ על כפתורים
• ליצור רשומות
• לערוך מידע

כלומר, ה-AI מסוגל לבצע את אותו User Flow שהבודק היה מבצע בעצמו באופן עצמאי – אבל יש כאן חלק חשוב במיוחד.

את Playwright ניתן להגדיר כך שכל תעבורת הדפדפן תעבור דרך Burp:

--proxy-server=http://127.0.0.1:8080

כך כל פעולה ש-Claude מבצע בדפדפן מתועדת גם ב-HTTP History של Burp.

מבחינת תהליך הבדיקה, קיבלנו עכשיו AI שמסוגל להפעיל את האפליקציה כמו משתמש אמיתי – בזמן שכל תעבורת הרשת שלו נלכדת על ידי כלי Pentesting.

Burp MCP: לתת ל-AI גישה לתעבורת HTTP

השלב הבא הוא לחבר את Claude גם ל-Burp עצמו.

באמצעות Burp MCP ניתן לאפשר ל-Claude Code לקרוא בקשות מתוך HTTP History, לנתח Responses ולשלוח בקשות HTTP חדשות.

מתקבלת ארכיטקטורה מעניינת:

Claude Code
↓
Playwright
↓
Browser
↓
Burp Proxy
↓
Web Application

ובמקביל:

Claude Code
↓
Burp MCP
↓
HTTP History / Requests / Repeater

כלומר, אותו AI גם מפעיל את האפליקציה דרך הדפדפן וגם מקבל גישה לשכבת ה-HTTP שבה Pentester בדרך כלל עובד.

ואז מוסיפים את קוד המקור

כאן היכולת הופכת חזקה עוד יותר.

אם Claude Code מופעל מתוך תיקיית הפרויקט, ניתן לתת לו גישה גם לקוד המקור של האפליקציה.

כעת יש לו שלוש נקודות מבט:

User Interface
↓
HTTP Traffic
↓
Source Code

וזה משנה משמעותית את אופי הבדיקה.

בבדיקת Black Box רגילה הבודק עשוי לראות שהשרת החזיר:

403 Forbidden

ולהסיק שמנגנון ה-Authorization פועל.

אבל כאשר ל-Claude יש גם גישה לקוד, הוא יכול לנסות לאתר את המקום שבו אותה הגנה מיושמת.

לדוגמה:

if (snippet.owner_id !== req.session.userId) {
return res.status(403).json(...);
}

במקום לקבל רק:

הבקשה נחסמה.

ניתן לקבל גם:

הבקשה נחסמה משום שבקובץ מסוים קיימת בדיקת בעלות שמשווה בין המשתמש המחובר לבעל הרשומה.

זהו יתרון משמעותי של White Box Security Testing.

הבדיקה לא מסתיימת ברמת התוצאה. ניתן לקשר את ההתנהגות בפועל אל הקוד שמיישם אותה.

הסוד הוא לא לבקש מה-AI "למצוא פרצות"

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

פרומפט כמו:

Find vulnerabilities in my application.

הוא כללי מאוד.

גישה טובה יותר היא לתת ל-AI מתודולוגיה מוגדרת.

לדוגמה:

Open the application using Playwright.

Login using the test credentials.

Create a new snippet and edit it.

Find the PUT request in Burp HTTP history.

Find a snippet belonging to another user.

Replace the ID in the original request.

Send the modified request.

Determine whether the server allows the operation.

ההבדל מהותי.

אנחנו לא מבקשים מה-AI "להיות האקר".

אנחנו נותנים לו Test Case מוגדר ומבקשים ממנו לבצע אותו.

במובן הזה, מדובר הרבה יותר ב-Security Automation חכמה מאשר בהחלפה מלאה של איש Pentesting.

להפוך מתודולוגיות אבטחה ל-Skills

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

Claude Code מאפשר לארוז תהליכים חוזרים כ-Skills.

למשל:

test-idor

יכול להכיל את כל השלבים הדרושים לבדיקת IDOR.

בעתיד ניתן להפעיל את אותו Skill על Endpoint נוסף ולספק לו רק את ההקשר החדש.

את אותו רעיון אפשר להרחיב למתודולוגיות נוספות, למשל:

test-auth
test-csrf
test-access-control
test-session

הערך האמיתי מתחיל כאשר ארגון בונה לעצמו ספרייה של תהליכי בדיקות שכבר נוסו ואומתו.

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

אחד השימושים המעניינים ביותר: Security Regression Testing

אחד היישומים החזקים ביותר לגישה הזו הוא דווקא לא Pentest חד-פעמי.

אלא Regression Testing לאבטחה.

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

חודש לאחר מכן מפתח מבית התוכנה משנה את הקוד.

שלושה חודשים לאחר מכן מתבצע Refactoring נוסף.

איך אנחנו יודעים שההגנה המקורית לא נשברה?

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

כך Security Testing יכול להתחיל להשתלב בצורה עמוקה יותר בתהליכי:

CI/CD, QA ו-DevSecOps.

המטרה היא לא לבצע בדיקת חדירה אחת לפני השקת המערכת – אלא לבדוק שוב ושוב שהגנות שכבר הוגדרו ממשיכות לעבוד לאחר שינויי קוד.

אז האם AI הולך להחליף Pentesters בקרוב?

לא בהכרח – ובוודאי לא בכל סוג של בדיקה.

חלק משמעותי מעבודתו של חוקר אבטחה אינו ביצוע סדרה קבועה של פעולות.

הערך של Pentester מנוסה מגיע פעמים רבות מהרגע שבו הוא מבחין בהתנהגות חריגה ושואל:

למה המערכת מתנהגת כך?

משם יכולה להתחיל חקירה שלא תוכננה מראש.

Exploratory Testing, בדיקות Business Logic מורכבות ו-Attack Chains שבהם כל שלב תלוי בתוצאה של הקודם דורשים עדיין מידה משמעותית של חשיבה ושיקול דעת.

AI מצטיין במיוחד כאשר כבר קיימים:

• יעד ברור
• Test Case מוגדר
• מתודולוגיה שנבדקה
• תוצאה צפויה שאפשר להשוות אליה

במילים אחרות:

האדם מגדיר ומאמת את המתודולוגיה וה-AI יכול לסייע בביצוע, בתיעוד ובסקייל.

החיבור בין Development, AI ו-Cybersecurity הולך ומתהדק

השילוב של Claude Code, Playwright, Burp Suite וגישה לקוד המקור מדגים משהו רחב הרבה יותר משימוש בכלי AI נוסף.

הוא מראה לאן סביבת הפיתוח המודרנית מתקדמת.

AI כבר אינו מוגבל לחלון Chat שבו שואלים שאלה ומקבלים קטע קוד.

כאשר נותנים לו גישה מבוקרת לכלים הנכונים, הוא יכול להשתתף ב-Workflow עצמו.

הוא יכול:

לקרוא את הקוד.

להפעיל את האפליקציה.

לבדוק את ההתנהגות שלה.

לנתח את התעבורה.

להשוות בין התוצאה הצפויה לתוצאה בפועל.

ולבסוף לחזור אל הקוד ולהסביר היכן ההתנהגות מיושמת.

וזה שינוי משמעותי.

לסיכום

החיבור בין Claude Code, Burp Suite, Playwright וקוד המקור יוצר סביבת Security Testing מעניינת מאוד.

ה-AI יכול לפעול בו-זמנית בשלוש שכבות:

כמשתמש מול הממשק, כ-Pentester מול תעבורת ה-HTTP וכמפתח מול קוד המקור.

אבל כדי להפיק מהיכולת הזאת ערך אמיתי, עדיין צריך להתחיל ממתודולוגיה טובה.

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

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

ב-AppWEB Technologies אנחנו עוקבים מקרוב אחר החיבור ההולך ומתהדק בין פיתוח תוכנה, AI, אוטומציה ואבטחת מידע.

השאלה המעניינת היום כבר אינה רק:

"האם AI יודע לכתוב קוד?"

אלא:

"כמה מתהליך הפיתוח, הבדיקות והאבטחה ניתן להפוך ל-Workflow חכם, מבוקר ואוטומטי?"