כשהאבטחה והמערכת מפרשות אחרת: שני כשלי תכנון מחומות אש ועד לסוכני AI

תקציר הניתוח

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

לא בגלל פריצה קריפטוגרפית.

לא בגלל חולשת זיכרון.

לא בגלל שמישהו שינה את המידע בדרך.

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

התופעה הזאת הופיעה שוב ושוב במוצרים חיים:

• Flowise כשלה בנרמול כתובות IPv4 שהוצגו בתוך IPv6.
• מסנן הרשת של סוכני AI ב־Visual Studio Code אפשר גישה ליעדים שנועדו להיות חסומים.
• stunnel אפשר עקיפה של מסנן localhost בתצורות SOCKS.
• ב־VS Code נחשפו הבדלים נוספים בין הדרך שבה מנגנון המדיניות פירש כתובות URL לבין הדרך שבה Chromium וכלי הרשת ביצעו אותן.

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

אלה שתי משפחות שונות של חולשות, החולקות דפוס ארכיטקטוני:

1. כשל הזהות ב־Dual-Stack, IPv4-mapped IPv6: אותו יעד IPv4 מוצג לשכבת המדיניות כאובייקט IPv6, אך מתבצע בפועל כחיבור IPv4.
2. עמימות בהרכבת פרגמנטים, Overlapping Fragmentation: רכיב האבטחה וה־Endpoint יכולים להפיק שתי חבילות שונות מאותו רצף פרגמנטים.

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

חוק השבר הסמנטי

Security breaks when validation and execution do not consume the same canonical semantic object.

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

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

1. הפיתוי לקבוע ש״הכל פרוץ״

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

לכותרת IPv4 הבסיסית אין מנגנון קריפטוגרפי מובנה שמאמת את מקור החבילה או את זהותו של השולח. יש לו Header Checksum, אך מטרתו לזהות שגיאות בכותרת במהלך ההעברה בלבד. הוא אינו חתימה, אינו מוכיח אותנטיות, אינו מכסה את ה־Payload ואינו מונע מתוקף לבנות חבילה תקינה תחבירית. RFC 791 אף מבהיר כי IP מספק Header Checksum בלבד, ללא מנגנון אמינות מלא, אישורים או בקרת שגיאות על המידע עצמו.

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

• TLS יכול להצפין חיבור שנפתח ליעד הלא נכון.
• חתימה דיגיטלית יכולה להוכיח שרצף הבתים לא השתנה, ובכל זאת שני רכיבים שונים יכולים להעניק לאותם בתים משמעות שונה.
• חומת אש יכולה לבדוק חבילה אחת, בעוד הקרנל מרכיב ומעביר ל־TCP חבילה אחרת.

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

• Byte Integrity: שלמות רצף הבתים, הנבדקת באמצעות מנגנון מתאים.
• Semantic Integrity: עקביות במשמעות האבטחתית שהרכיבים מייחסים למידע. במאמר זה המונח משמש למסגרת הניתוח, ואינו כשלעצמו מנגנון הוכחה.

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

• המסנן רואה יעד IPv6 שאינו חסום ← ה־Socket מגיע ל־IPv4 loopback.
• רשימת החסימה רואה מחרוזת אחת ← ספריית התקשורת מפעילה זהות אחרת.
• מסנן URL רואה authority ריק ← הדפדפן מנרמל אותו ל־host ממשי.
• חומת האש רואה חיבור מותר ← ה־Endpoint מרכיב חיבור שהיה אמור להיחסם.

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

2. השבר האמיתי אינו בקלט אלא בזהות שלו

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

כל שלב בשרשרת יכול לבצע שינוי:

• להסיר סוגריים מרובעים.
• לפענח Percent Encoding.
• להחליף backslash ב־slash.
• לפתור hostname לכתובת IP.
• לבחור בין רשומת A לרשומת AAAA.
• להמיר IPv4 ל־IPv4-mapped IPv6.
• לעקוב אחר Redirect.
• לבחור Proxy.
• להחליף יעד לוגי ביעד תחבורתי.

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

הבעיה מתחילה כאשר החלטת האבטחה מתקבלת באמצע השרשרת, אך פעולת הרשת מתרחשת בסופה. נניח שמנוע המדיניות בדק מחרוזת מסוימת וקבע ALLOW. לאחר מכן, ספרייה אחרת מבצעת עליה נרמול נוסף, DNS resolution או המרה בין משפחות כתובות. ברגע שזה קרה, החלטת ה־ALLOW המקורית כבר אינה קשורה בהכרח לאובייקט שמתבצע בפועל.

זהו דפוס מסוכן:

כאשר המדיניות כלל לא בדקה את B.

הבעיה אינה בהכרח שה־Parser הראשון שגוי או שה־Parser השני שגוי. ייתכן ששניהם פועלים באופן עקבי לחלוטין עם הכללים שלהם. החולשה נמצאת בגבול ביניהם: Differential Interpretation Boundary (גבול פירוש דיפרנציאלי). זהו מקום שבו אובייקט עובר בין שני רכיבים המאמינים שהם מדברים על אותה ישות, אף שכל אחד מהם מפעיל פונקציית זהות אחרת.

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

3. הסדק הראשון: IPv4 שמופיע כזהות IPv6

מנגנון IPv4-mapped IPv6 נועד להקל על המעבר בין IPv4 ל־IPv6.

RFC 4291 מגדיר כתובת שבה 80 הביטים הראשונים הם אפס, 16 הביטים הבאים הם FFFF, ו־32 הביטים האחרונים מכילים כתובת IPv4. כך, כתובת IPv4 יכולה להיות מיוצגת בתוך מבנה בן 128 ביט בלי להפוך ליעד רשת אחר.

לדוגמה, כתובת התיעוד 192.0.2.1 יכולה להיכתב בייצוג ממופה כ־::ffff:192.0.2.1. זו דוגמה למבנה הכתובת, לא יעד לבדיקת רשת.

RFC 3493 שילב את הייצוג הזה בתוך ה־Socket API. במימוש dual-stack מתאים, אפליקציה המשתמשת ב־AF_INET6 יכולה להעביר כתובת ממופה לממשק התקשורת, והמערכת יכולה לפעול מול יעד IPv4. ההתנהגות תלויה במימוש ובהגדרות: למשל, האפשרות IPV6_V6ONLY מגבילה את ה־socket לתקשורת IPv6.

המנגנון עצמו אינו חולשה. הוא מנגנון תאימות מתוכנן. הכשל מתחיל כאשר שכבת האבטחה אינה מחילה על הכתובת את אותה משמעות שבה משתמשת שכבת הביצוע.

הפער בין סיווג הייצוג לסיווג היעד

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

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

RFC 4942 תיאר כבר ב־2007 את המנגנון כ־overloaded functionality היוצרת עמימות. המסמך הזהיר מהמורכבות שנוספת לבקרות הרשאה מבוססות כתובת, בין היתר כאשר socket של IPv6 מקבל תעבורת IPv4. RFC 5156 מבהיר שהטווח הממופה אינו מיועד להופיע ככתובות בתעבורת IPv6 רגילה באינטרנט הציבורי. הדגש כאן הוא על הייצוג שעובר בין רכיבי התוכנה.

הבעיה אינה שלכתובת יש ״שני שמות״. הבעיה היא ששני רכיבים עלולים להסיק מהייצוגים השקולים שתי החלטות אבטחתיות שונות.

4. הכשל העתיק מפיל מוצרים מודרניים

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

Flowise: כללי IPv4 שלא הופעלו על יעד IPv4

בחולשה CVE-2026-69257, רכיב האבטחה של Flowise לא נרמל כתובות IPv4-mapped IPv6 לפני בדיקת רשימת החסימה. כתוצאה מכך, סיווג הכתובת בספריית ipaddr.js לא התאים לסיווג כללי ה־IPv4, והגנת ה־SSRF לא נאכפה כמתוכנן על היעדים הרלוונטיים.

החולשה פורסמה ב־4 באוגוסט 2026 ודורגה High, בציון 7.6 לפי CVSS 4.0. שדות הגרסאות בייעוץ מציינים השפעה על גרסאות עד 3.1.2 ותיקון ראשון ב־3.1.3. וקטור החומרה כולל הרשאות נמוכות ותנאי תקיפה נוספים; אין להסיק מכאן שכל מבקר אנונימי יכול לגשת לכל שירות פנימי.

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

VS Code: Fail-open בגבול של סוכן AI

CVE-2026-69306 עוסקת בכשל נרמול במסנן הרשת של סוכני VS Code. בתצורות המתוארות בייעוץ, כשהמסנן היה פעיל, טיפול לא תקין בכתובות IPv6 וכשלי נרמול שנפתחו במקום להיחסם יכלו לאפשר לכלי רשת גישה לשירותים מקומיים בניגוד למדיניות.

החולשה דורגה High, בציון 8.2 לפי CVSS 3.1. רשומת Microsoft פורסמה ב־11 באוגוסט 2026, וייעוץ המאגר ב־GitHub פורסם ב־12 באוגוסט. יש הבדל בין הרשומות: ייעוץ GitHub מציין תיקון ב־1.132.1, ואילו MSRC המעודכן מציין FixedBuild 1.135; גם רשומת ה־CVE העדכנית מציינת גרסאות שלפני 1.135. MSRC עדכן את מידע החבילה ב־2 בספטמבר, בלי לפרט את סיבת ההבדל. לכן אין להציג את המספר הישן כגרסת התיקון העדכנית היחידה.

התיקון המתואר מבוסס על נרמול מודע־URL והתנהגות fail-closed כאשר היעד אינו ניתן לנרמול. הסוכן לא נדרש לשבור את מערכת ההפעלה: הפער נמצא בגבול שבין החלטת המסנן לפעולת הכלי.

stunnel: אותה משפחת כשל, חומרה אחרת

CVE-2026-70367 השפיעה על stunnel מגרסה 5.25 ועד לפני 5.80, במצב SOCKS ובתנאים המפורטים בייעוץ. מסנן היעד לא כיסה את כל ייצוגי הכתובות המקומיות הרלוונטיים. ההשפעה תלויה בגישה לשירות SOCKS ובשירותים המקומיים שמאחוריו; אין מדובר בכל התקנת stunnel.

Red Hat דירגה את החולשה כ־Moderate, עם CVSS 3.1 של 5.4, בדרגת Medium. יומן השינויים של stunnel מאשר תיקון ב־5.80, שפורסמה ב־4 באוגוסט 2026. בחבילות של הפצות יש לבדוק גם תיקונים שהוחלו על גרסה ותיקה, ולא רק את מספר גרסת המקור.

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

VS Code: שלושה מסלולים נוספים באותה משפחת בעיות

ב־8 בספטמבר 2026 פורסמו שלושה ייעוצים נוספים, כולם High, בציון 8.2 לפי CVSS 3.1, עם תיקון ב־1.136.2:

• CVE-2026-81357: חוסר עקביות בהשוואת ייצוגים שקולים של כתובות, בתצורת מסנן הנשענת על רשימת חסימה ללא רשימת הרשאה.
• CVE-2026-81378: הבדלי פירוש בין מנגנון המדיניות ל־Chromium בדפדפן המשולב. התיקון כולל נרמול ובדיקה חוזרת לפני פעולת הרשת.
• CVE-2026-81379: פערים בפירוש רכיב ה־authority ב־URL, ובמקרים מסוימים התעלמות מתבניות מדיניות תקינות שהגדיר מנהל המערכת.

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

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

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

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

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

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

מה באמת קבע RFC 791?

באלגוריתם ההרכבה המתואר ב־RFC 791, מידע שהגיע מאוחר יותר יכול להחליף מידע שכבר נשמר באזור חופף. אין להסיק מכך שכל מערכת הפעלה או חומת אש מודרנית משתמשת בכלל הזה.

RFC 1858 משנת 1995 מתאר את הסיכון שבפער בין המידע שמסנן בדק לבין המידע שהיעד מרכיב. הדוגמה שלו עוסקת בדגלי TCP. היא אינה מבססת טענה כללית שלפיה המקרה המתואר מחליף גם את פורט היעד.

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

RFC 1858 ציין ש־RFC 815 לא הכריע בסוגיית החפיפות, והשווה בין כללי הרכבה שונים, ובהם כלל של 4.3 BSD שהעדיף מידע ממקטע בעל offset נמוך יותר. את אמירתו על היעדר דרישה לאלגוריתם overlap-safe יש לקרוא בהקשר התקופתי של המסמך.

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

6. התקנים המודרניים והפתרון של IPv6

RFC 8900 משנת 2020, המוגדר BCP 230, מתאר IP fragmentation כמקור לשבריריות בתקשורת. הוא מסביר כיצד פער בהרכבת מקטעים עלול להביא לתוצאה שאינה תואמת את מדיניות המסנן.

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

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

IPv6 בחר כלל קשיח: Drop on Ambiguity

ב־IPv6 התקבלה החלטה ארכיטקטונית ברורה (RFC 8200): אם שני פרגמנטים של אותה חבילה חופפים, יש לנטוש את תהליך ההרכבה ולהשליך את כל הפרגמנטים שהתקבלו עבור אותה חבילה. אין בחירה בין תוכן סותר שהגיע ראשון לתוכן סותר שהגיע אחריו. לצד זאת, סעיף 4.5 מאפשר לזהות עותקים זהים לחלוטין של פרגמנט, להשליך את העותק הכפול ולהמשיך בהרכבה עם יתר המקטעים.

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

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

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

7. כמה מערכות באמת נמצאות בשדה החשיפה?

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

1. מספר המערכות שהוכח שהן פגיעות.
2. מספר המערכות שמכילות דפוס ארכיטקטוני שעשוי להיות פגיע.
3. גודל האוכלוסייה הטכנולוגית שבתוכה כדאי לבחון את הדפוס.

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

גודל האינטרנט אינו מספר האפליקציות הפגיעות

סקר Netcraft ליולי 2026, שפורסם ב־27 ביולי, קיבל תשובות מ־1,494,915,628 אתרים, על פני 305,348,459 דומיינים ו־14,772,048 מחשבים הפונים לרשת.

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

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

גודל עולם ה־IoT אינו מדידת חולשות בפרגמנטציה

IoT Analytics פרסמה באוקטובר 2025 תחזית של 21.1 מיליארד התקנים מחוברים בסוף אותה שנה. בפרסום מ־4 בפברואר 2026, שעודכן במאי, הציגה החברה אומדן בדיעבד של 21.1 מיליארד התקנים בסוף 2025. זהו תאריך הייחוס של המספר, לא ספירה חיה לספטמבר 2026.

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

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

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

8. חוק השבר הסמנטי: ניסוח פורמלי

אני מציע את ״חוק השבר הסמנטי״ כמסגרת לניתוח משפחת הכשל, לא כחוק חדש שמחליף תקנים או כהוכחת חסינות כללית. עקרונות דומים מתועדים גם ב־CWE-180 וב־CWE-436. כדי לנסח את המסגרת באופן מדויק, נגדיר:

• x: הקלט הגולמי.
• Iₚ(x): האובייקט שמנוע המדיניות מפיק מתוך x.
• Iₑ(x): האובייקט שמנוע הביצוע מפיק מתוך x.
• P(y): החלטת המדיניות לגבי האובייקט y.

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

Iₚ(x) ≡ Iₑ(x)

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

פער הרשאה מתקיים כאשר יש קלט x שמוביל להחלטות שונות, והמערכת מאפשרת את פעולת הביצוע בלי אכיפה נוספת שסוגרת את הפער:

P(Iₚ(x)) = ALLOW ∧ P(Iₑ(x)) = DENY

• במקרה של IPv4-mapped IPv6: Iₚ(x) הוא כתובת IPv6 שאינה מתאימה לכלל IPv4 חסום; Iₑ(x) הוא כתובת IPv4 פנימית, link-local או loopback.
• במקרה של Overlapping Fragments: Iₚ(x) הוא החבילה שחומת האש מסיקה; Iₑ(x) הוא החבילה שהקרנל מרכיב בפועל.
• במקרה של VS Code ו־Chromium: Iₚ(x) הוא URL בעל authority ריק; Iₑ(x) הוא host ממשי לאחר נרמול.

מכאן נובע עיקרון נוסף: אין משמעות ל־ALLOW שאינו קשור לאובייקט הביצוע הסופי.

Canonical Security Object

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

{
  "scheme": "https",
  "canonical_hostname": "example.com",
  "resolved_address_set": ["192.0.2.10"],
  "selected_ip": "192.0.2.10",
  "address_family": "AF_INET",
  "address_scope": "documentation",
  "port": 443,
  "proxy_destination": null,
  "redirect_lineage": []
}

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

ארבעת האינווריאנטים

1. אינווריאנט הזהות:
   Canonicalize(127.0.0.1) ≡ Canonicalize(::ffff:127.0.0.1)
2. אינווריאנט קשירת ההחלטה לביצוע:
   Approved Binary Destination ≡ Executed Binary Destination
3. אינווריאנט דחיית העמימות:
   Iₚ(x) ≠ Iₑ(x) ⇒ DENY
4. אינווריאנט האימות מחדש: שינוי בזהות האבטחתית, כגון יעד חדש בעקבות Redirect או DNS, מחייב אימות מחדש לפני הפעולה הבאה.

9. סוכני AI הופכים פער Parser לגבול הרשאה

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

סוכן מקבל יעד מהוראת משתמש, מסמך, אתר, תוצאת חיפוש, מייל, API, שרת MCP או prompt injection עקיף, ומעביר אותו ל־Fetch Tool, Browser Tool, HTTP Client, Terminal או Webhook:

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

לכן מומלץ לשלב שתי שכבות הגנה משלימות עבור סוכן בעל גישה לרשת:

1. שכבת מדיניות אפליקטיבית: מבינה כוונה, URL, hostname, scheme, port, Redirect וזהות השירות.
2. שכבת אכיפה ברמת ה־Egress: קרובה ל־Socket, ל־Proxy או ל־Network Namespace ומגבילה כתובות IP בפועל, טווחים פרטיים, loopback, ports ויעדי יציאה.

המסנן הראשון מבין כוונה. המסנן השני מגביל מציאות.

בדיקות עקביות ברכיבים האמיתיים

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

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

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

10. הארכיטקטורה ששורדת

המערכות שנשברות חולקות בדפוסים מוכרים: Validate-before-Canonicalize, Deny-lists מבוססות מחרוזות, Parsing כפול בספריות שונות, בדיקה לפני DNS וחיבור לאחר DNS, Redirect ללא Revalidation, Fail-open במקרה של כשל Parsing, וסינון פרגמנטים ללא Reassembly עקבי.

המערכות ששורדות בנויות על כלל ברזל: האובייקט שעליו התקבלה החלטת האבטחה חייב להיות האובייקט שמתבצע.

עשרת כללי ההגנה

1. פירוש מבוקר ועקבי: העדפת אובייקט מובנה וקנוני; כשנדרשים כמה Parsers, יש לוודא שקילות במשמעות הרלוונטית למדיניות ולא לאפשר פירוש חוזר בלתי מבוקר.
2. נרמול מוקדם: קביעת זהות היעד לפני החלטת המדיניות, לרבות כתובות ממופות, פורטים ו־Zone IDs; אין להסיר מידע בעל משמעות אבטחתית בשם הנרמול.
3. סיווג בינארי: קביעת Loopback, Private, Link-local ו־Scope לפי הביטים, לא באמצעות Regex או השוואת מחרוזות.
4. אימות DNS מלא: בדיקת כל הכתובות המוחזרות מ־DNS, או בחירת כתובת מאושרת אחת וקשירת ה־Socket אליה.
5. קשירת החיבור לכתובת המאושרת: מניעת resolution נוסף שאינו כפוף למדיניות, תוך שמירת זהות השירות, SNI ואימות תעודת TLS כנדרש.
6. Revalidation לאחר Redirect: בדיקת היעד הבא לפני החיבור אליו, לפי המדיניות החלה עליו.
7. Fail-Closed: כשל Parsing פירושו DENY.
8. טיפול עקבי במקטעים: דחיית חפיפות סותרות לפי התקן והמדיניות, תוך הבחנה בעותקים זהים כשמותר; רכיב ביניים הבודק תוכן מפוצל זקוק למדיניות עקבית ומוגבלת משאבים.
9. אכיפת Egress: שילוב שכבת אכיפה ברמת ה־Socket / Proxy / Network Namespace בנוסף למדיניות האפליקטיבית.
10. בדיקת רכיבי Production אמיתיים: אימוץ סביבות בדיקה המפעילות את ה־Parser, Browser, Resolver, Socket stack וה־Kernel הממשיים.

סיכום

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

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

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

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

• Byte Integrity עוסקת בשלמות רצף הבתים.
• Semantic Integrity עוסקת בעקביות המשמעות האבטחתית לאורך המעברים.

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