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

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

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

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

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

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

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

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

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

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

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

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

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

ללא הגבלת קצב

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

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

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

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

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

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

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

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

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

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

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

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