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

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

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

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

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

הפגיעויות הנפוצות ביותר שאני מוצא

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

מפתחות API וסודות חשופים

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

אימות והרשאות חלשים או חסרים

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

התקפות injection (SQL injection, XSS)

כשאפליקציה בוטחת בקלט מהמשתמש בלי לנקות אותו, תוקף יכול להבריח לתוכה פקודות. SQL injection מרמה את מסד הנתונים להריץ קוד של התוקף, ועלול לשפוך החוצה כל רשומה. Cross-site scripting (XSS) מזריק סקריפטים זדוניים שרצים בדפדפנים של משתמשים אחרים. שתיהן התקפות ותיקות, מוכרות היטב, ואפשר למנוע אותן לחלוטין עם טיפול נכון בקלט, שאפליקציות שנבנו ב-AI מדלגות עליו באופן שגרתי.

אפס הגבלת קצב

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

דליפת נתונים דרך תגובות מתירניות מדי

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

רשימת בדיקת אבטחה בשפה פשוטה

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

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

מה בדיקת אבטחה נכונה מכסה

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

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

השתמשו ב-AI, אבל אבטחו את מה שהוא בונה

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

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