התקפה על מערכות חזית-אנד-גב המאפשרת לנו להשתלב בבקשות של צד שלישי

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

עיקר הבעיה הוא ש-frontends ו-backends מספקים לרוב רמות שונות של תמיכה בפרוטוקול HTTP, אך בו-זמנית עוטפים בקשות ממשתמשים שונים לערוץ משותף. כדי לחבר את הבקשות המקבלות בקצה הקצה ובקשות העיבוד האחורי, נוצר חיבור TCP ארוך טווח, דרכו מועברות בקשות משתמשים, המשודרות לאורך השרשרת בזו אחר זו, מופרדות באמצעות פרוטוקול HTTP. כדי להפריד בקשות, הכותרות "תוכן-אורך" (קובע את הגודל הכולל של הנתונים בבקשה) ו- "העברת קידוד: chunked"(מאפשר לך להעביר נתונים בחלקים, תוך ציון בלוקים בגדלים שונים בפורמט "{גודל}\r\n{גוש}\r\n{גודל}\r\n{בלוק}\r\n0").

הבעיה מתעוררת אם ה-frontend תומך רק ב-"Content-Length" אבל מתעלם מ-"Transfer-Encoding: chunked" (לדוגמה, Akamai CDN עשה זאת) או להיפך. אם העברה-קידוד: chunked נתמך משני הצדדים, ניתן להשתמש בתכונות היישום של מנתחי כותרות HTTP עבור התקפה (לדוגמה, כאשר הקצה הקדמי מתעלם משורות כמו "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked" ", "Transfer-Encoding" :[tab]chunked", "X: X[\n]Transfer-Encoding: chunked", "Transfer-Encoding[\n]: chunked" או "Transfer-Encoding: chunked", וכן הקצה האחורי מעבד אותם בהצלחה).

במקרה זה, תוקף יכול לשלוח בקשה המכילה גם את הכותרות "Content-Length" ו-"Transfer-Encoding: chunked", אך הגודל ב-"Content-Length" אינו תואם לגודל השרשרת החתוכה, אשר קטן מהערך האמיתי. אם ה-frontend מעבד ומעביר את הבקשה לפי "Content-Length" וה-backend ממתין להשלמת הבלוק על סמך "Transfer-Encoding: chunked", אז סוף הנתונים המבוססים על "Transfer-Encoding: chunked" ייקבע מוקדם יותר ואת הזנב הנותר של הבקשה התוקף יהיה בתחילת הבקשה הבאה, כלומר. התוקף יוכל לצרף נתונים שרירותיים לתחילת הבקשה של מישהו אחר ששודרה לאחר מכן.

כדי לקבוע את הבעיה בשילוב ה-frontend-backend בשימוש, תוכל לשלוח בקשה כזו דרך ה-frontend:

POST /אודות HTTP/1.1
מארח: example.com
העברת קידוד: chunked
תוכן-זמן: 4

1
Z
Q

הבעיה קיימת אם הקצה האחורי לא מעבד מיד את הבקשה ומחכה להגעתו של בלוק האפס התוחם הסופי של נתוני נתח. לבדיקה מלאה יותר מוּכָן כלי עזר מיוחד שבודק גם שיטות אפשריות להסתרת הכותרת "Transfer-Encoding: chunked" מהחזית.

ביצוע התקפה אמיתית תלוי ביכולות האתר המותקף, למשל, בעת תקיפת אפליקציית האינטרנט של Trello, ניתן להחליף את תחילת הבקשה (תחליף נתונים כמו "PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake") ולשלוח הודעה הכוללת את הבקשה המקורית של משתמש צד שלישי ואת עוגיית האימות שצוינה בה. עבור התקפה על saas-app.com, התברר שניתן להחליף את קוד JavaScript בתגובה על ידי החלפתו באחד מפרמטרי הבקשה. עבור המתקפה על redhat.com, נעשה שימוש במטפל פנימי כדי להפנות לאתר של התוקף (בקשה בטופס "POST /search?dest=../assets/idx?redir=//[מוגן בדוא"ל]/ HTTP/1.1").

השימוש בשיטה לרשתות אספקת תוכן אפשר פשוט להחליף את האתר המבוקש על ידי החלפת הכותרת "מארח:". המתקפה יכולה לשמש גם כדי להרעיל את התוכן של מערכות אחסון תוכן במטמון ולחלץ נתונים סודיים במטמון. פסגת השיטה הייתה ארגון מתקפה על PayPal, שאפשרה ליירט סיסמאות שנשלחו על ידי משתמשים במהלך האימות (בקשת ה-iframe שונתה לביצוע JavaScript בהקשר של עמוד paypal.com/us/gifts, עבור אשר CSP (מדיניות אבטחת תוכן) לא הוחל).

מעניין שב-2005 היה מוּצָע טכניקת זיוף בקשות דומה במהותה המאפשרת לך לזייף נתונים ב-Caching proxy (Tomcat, squid, mod_proxy) או לעקוף חסימת חומת אש על ידי ציון מספר בקשות "GET" או "POST" בתוך הפעלת HTTP אחת.

מקור: OpenNet.ru