फ्रंट-एंड-बॅक-एंड सिस्टमवर हल्ला जो आम्हाला तृतीय-पक्षाच्या विनंत्यांना वेज करण्यास अनुमती देतो

प्रकट फ्रंट-एंड-बॅक-एंड मॉडेल वापरणाऱ्या साइटवरील नवीन हल्ल्याचे तपशील, जसे की सामग्री वितरण नेटवर्क, लोड बॅलन्सर किंवा प्रॉक्सीद्वारे चालणारे. अटॅक, काही विनंत्या पाठवून, फ्रंटएंड आणि बॅकएंड दरम्यान समान थ्रेडमध्ये प्रक्रिया केलेल्या इतर विनंत्यांच्या सामग्रीमध्ये पाचर घालण्याची परवानगी देतो. प्रस्तावित पद्धत यशस्वीरित्या आक्रमण आयोजित करण्यासाठी वापरली गेली ज्यामुळे PayPal सेवेच्या वापरकर्त्यांचे प्रमाणीकरण पॅरामीटर्स रोखणे शक्य झाले, ज्याने संशोधकांना अनपॅच नसलेल्या भेद्यतेच्या उपस्थितीबद्दल माहिती देण्यासाठी प्रोग्रामचा भाग म्हणून सुमारे 40 हजार डॉलर्स दिले. अकामाई कंटेंट डिलिव्हरी नेटवर्क वापरणाऱ्या साइटवरही हा हल्ला लागू होतो.

समस्येचा मुख्य मुद्दा असा आहे की फ्रंटएंड आणि बॅकएंड हे HTTP प्रोटोकॉलसाठी विविध स्तरांचे समर्थन प्रदान करतात, परंतु त्याच वेळी भिन्न वापरकर्त्यांच्या विनंत्या एका सामान्य चॅनेलमध्ये समाविष्ट करतात. फ्रंटएंड रिसिव्हिंग रिक्वेस्ट आणि बॅकएंड प्रोसेसिंग विनंत्यांना जोडण्यासाठी, एक दीर्घकाळ टिकणारे TCP कनेक्शन स्थापित केले जाते, ज्याद्वारे वापरकर्त्याच्या विनंत्या, एकामागून एक साखळीसह प्रसारित केल्या जातात, HTTP प्रोटोकॉलद्वारे विभक्त केल्या जातात. विनंत्या विभक्त करण्यासाठी, शीर्षलेख "सामग्री-लांबी" (विनंतीत डेटाचा एकूण आकार निर्धारित करते) आणि "हस्तांतरण-एनकोडिंग: तुकडे केलेले"(तुम्हाला "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0" फॉरमॅटमध्ये वेगवेगळ्या आकाराचे ब्लॉक्स नमूद करून, भागांमध्ये डेटा ट्रान्सफर करण्याची परवानगी देते).

जर फ्रंटएंड फक्त "सामग्री-लांबी" चे समर्थन करत असेल परंतु "हस्तांतरण-एनकोडिंग: खंडित" (उदाहरणार्थ, अकामाई सीडीएनने हे केले) किंवा त्याउलट दुर्लक्ष केले तर समस्या उद्भवते. ट्रान्सफर-एनकोडिंग: chunked दोन्ही बाजूंनी समर्थित असल्यास, HTTP हेडर पार्सर्सची अंमलबजावणी वैशिष्ट्ये आक्रमणासाठी वापरली जाऊ शकतात (उदाहरणार्थ, जेव्हा समोरचे टोक “Transfer-Encoding: xchunked”, “Transfer-Encoding: chunked” सारख्या ओळींकडे दुर्लक्ष करते ”, “हस्तांतरण-एनकोडिंग” :[टॅब]खंड केलेले", "X: X[\n]हस्तांतरण-एनकोडिंग: खंडित", "हस्तांतरण-एनकोडिंग[\n]: खंडित" किंवा "हस्तांतरण-एनकोडिंग: खंडित", आणि बॅकएंड त्यांच्यावर यशस्वीरित्या प्रक्रिया करते).

या प्रकरणात, आक्रमणकर्ता विनंती पाठवू शकतो ज्यात "सामग्री-लांबी" आणि "हस्तांतरण-एनकोडिंग: खंडित" शीर्षलेख आहेत, परंतु "सामग्री-लांबी" मधील आकार खंडित साखळीच्या आकाराशी संबंधित नाही, जे वास्तविक मूल्यापेक्षा लहान आहे. जर फ्रंटएंड "सामग्री-लांबी" नुसार विनंतीवर प्रक्रिया करत असेल आणि फॉरवर्ड करत असेल आणि बॅकएंड "हस्तांतरण-एनकोडिंग: chunked" वर आधारित ब्लॉक पूर्ण होण्याची प्रतीक्षा करत असेल, तर "हस्तांतरण-एनकोडिंग: chunked" वर आधारित डेटाचा शेवट होईल. आधी निर्धारित करा आणि विनंतीची उर्वरित शेपटी आक्रमणकर्त्याने पुढील विनंतीच्या सुरुवातीला असेल, म्हणजे हल्लेखोर पुढील प्रसारित केलेल्या दुसऱ्याच्या विनंतीच्या सुरूवातीस अनियंत्रित डेटा संलग्न करण्यास सक्षम असेल.

वापरलेल्या फ्रंटएंड-बॅकएंड संयोजनातील समस्या निश्चित करण्यासाठी, तुम्ही फ्रंटएंडद्वारे अशी विनंती पाठवू शकता:

पोस्ट / HTTP/ 1.1 बद्दल
होस्ट: example.com
हस्तांतरण-एनकोडिंग: तुकडे केलेले
सामग्री-लांबी: 4

1
Z
Q

जर बॅकएंड विनंतीवर त्वरित प्रक्रिया करत नसेल आणि खंडित डेटाच्या अंतिम शून्य बाउंडिंग ब्लॉकच्या आगमनाची वाट पाहत असेल तर समस्या उपस्थित आहे. अधिक संपूर्ण तपासणीसाठी तयार एक विशेष उपयुक्तता जी फ्रंटएंडमधून "हस्तांतरण-एनकोडिंग: चंक्ड" शीर्षलेख लपविण्याच्या संभाव्य पद्धतींची देखील चाचणी करते.

वास्तविक हल्ला करणे आक्रमण केलेल्या साइटच्या क्षमतेवर अवलंबून असते, उदाहरणार्थ, ट्रेलो वेब ऍप्लिकेशनवर हल्ला करताना, तुम्ही विनंतीची सुरूवात बदलू शकता ("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 वरील हल्ल्याची संस्था ही या पद्धतीची शिखरे होती, ज्यामुळे प्रमाणीकरणादरम्यान वापरकर्त्यांद्वारे पाठवलेले पासवर्ड रोखणे शक्य झाले (आयफ्रेम विनंती paypal.com/us/gifts पृष्ठाच्या संदर्भात JavaScript कार्यान्वित करण्यासाठी सुधारित करण्यात आली होती. जे CSP (सामग्री सुरक्षा धोरण) लागू केले नाही).

विशेष म्हणजे 2005 मध्ये होते प्रस्तावित मूलत: समान रिक्वेस्ट स्पूफिंग तंत्र जे तुम्हाला कॅशिंग प्रॉक्सी (टॉमकॅट, स्क्विड, मॉड_प्रॉक्सी) मध्ये डेटा स्पूफ करण्यास किंवा एका HTTP सत्रात अनेक “GET” किंवा “POST” विनंत्या निर्दिष्ट करून बायपास फायरवॉल ब्लॉक करण्यास अनुमती देते.

स्त्रोत: opennet.ru