בדיקת אבטחה לקוד שנכתב ב-AI

למה AI כותב קוד פגיע

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

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

ארבעה מקומות לבדוק קודם

1. סודות בקוד של הדפדפן

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

2. טבלאות בלי מדיניות גישה

ב-Supabase המפתח הציבורי (anon, היום publishable) נועד להיות גלוי בדפדפן. הוא בטוח רק אם בכל טבלה מופעל Row Level Security ונכתבה מדיניות. התיעוד של Supabase אומר את זה במפורש: טבלה בסכמה חשופה בלי RLS פתוחה לקריאה ולכתיבה לכל תפקיד שיש לו הרשאה אליה. מפתח השירות (service_role, היום secret) עוקף כל מדיניות, ואסור שיגיע לדפדפן או למאגר הקוד.

זה לא תיאורטי. במסגרת CVE-2025-48757 חוקר בדק 1645 פרויקטים שנבנו ב-Lovable, ומצא ב-170 מהם מדיניות RLS לא מספקת, שדרכה נחשפו מידע אישי, מפתחות של שירותים חיצוניים ופרטי תשלום. Lovable חולקת על ה-CVE וטוענת שהאחריות על הנתונים היא של כל בעל פרויקט. מבחינת בעל הפרויקט, המסקנה נשארת זהה בכל מקרה: את הבדיקה צריך לעשות בעצמו.

3. הרשאות שנבדקות רק בממשק

כפתור המחיקה מוסתר ממי שאסור לו למחוק, אבל השרת יבצע את בקשת המחיקה מכל אחד. או שדף ההזמנה נפתח בכתובת /orders/1043, ואם מחליפים ל-1044 נפתחת הזמנה של מישהו אחר. לזה קוראים IDOR, ו-OWASP מציב פגיעה בבקרת גישה במקום הראשון ברשימת הסיכונים שלו: באפליקציות שנבדקו היא מופיעה בצורה כלשהי כמעט תמיד.

4. חבילות שלא קיימות

מודלים לפעמים מתקינים ספרייה עם שם סביר שלא קיימת. מחקר שהוצג ב-USENIX Security ספר יותר ממאתיים אלף שמות חבילות מומצאים ייחודיים. במודלים פתוחים שיעור ההפניות האלה הגיע לחמישית. מספיק שתוקף ירשום את השם ויעלה תחתיו חבילה זדונית. לשיטה קוראים slopsquatting.

מה כוללת הבדיקה

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

מה לבדוק בעצמכם לפני הבדיקה

1. פתחו את האתר, לחצו F12 וחפשו בקוד את המילים key, secret, token. כל מה שתמצאו, חוץ מהמפתח הציבורי של Supabase, תחשיבו כמפתח שדלף.
2. בלוח הבקרה של Supabase פתחו את רשימת הטבלאות ובדקו לאילו מהן אין סימון RLS. כל טבלה כזו פתוחה.
3. היכנסו כמשתמש שני ונסו לפתוח רשומה של משתמש אחר על ידי החלפת המספר בכתובת.
4. אם אחד הסעיפים הצליח, אל תעלו פיצ'רים חדשים עד שזה נסגר: כל טבלה חדשה יורשת את אותה טעות.

שאלות נפוצות

האם המפתח הציבורי של Supabase בטוח בדפדפן?

כן, אם בכל טבלה מופעל Row Level Security והמדיניות מאפשרת למשתמש לראות רק את השורות שלו. בלי RLS אותו מפתח נותן קריאה וכתיבה לכל הטבלה. מפתח service_role אף פעם לא בטוח בדפדפן.

עוזר ה-AI לא בודק אבטחה בעצמו?

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

מה זה IDOR במילים פשוטות?

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

צריך גישה למסד הנתונים בייצור?

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

כמה זמן לוקח לתקן?

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