फ्रन्ट-एन्ड-ब्याक-एन्ड प्रणालीहरूमा आक्रमण जसले हामीलाई तेस्रो-पक्ष अनुरोधहरूमा जोड्न अनुमति दिन्छ

खुलासा गरियो फ्रन्ट-एन्ड-ब्याक-एन्ड मोडेल प्रयोग गर्ने साइटहरूमा नयाँ आक्रमणको विवरणहरू, जस्तै सामग्री डेलिभरी नेटवर्कहरू, लोड ब्यालेन्सरहरू वा प्रोक्सीहरू मार्फत चल्नेहरू। आक्रमणले, निश्चित अनुरोधहरू पठाएर, फ्रन्टएन्ड र ब्याकइन्ड बीचको एउटै थ्रेडमा प्रशोधन गरिएका अन्य अनुरोधहरूको सामग्रीमा वेज गर्न अनुमति दिन्छ। प्रस्तावित विधि सफलतापूर्वक एक आक्रमण संगठित गर्न को लागी प्रयोग गरीयो जसले PayPal सेवा को प्रयोगकर्ताहरु को प्रमाणिकरण मापदण्डहरु लाई रोक्न को लागी सम्भव बनायो, जसले अनुसन्धानकर्ताहरुलाई एक कार्यक्रम को भाग को रूप मा लगभग 40 हजार डलर भुक्तान गर्यो unpatched कमजोरीहरु को उपस्थिति को बारे मा सूचित गर्न को लागी। आक्रमण Akamai सामग्री वितरण नेटवर्क प्रयोग गर्ने साइटहरूमा पनि लागू हुन्छ।

समस्याको जड यो हो कि फ्रन्टएन्ड र ब्याकएन्डहरूले प्राय: HTTP प्रोटोकलको लागि विभिन्न स्तरहरूको समर्थन प्रदान गर्दछ, तर एकै समयमा विभिन्न प्रयोगकर्ताहरूबाट अनुरोधहरूलाई साझा च्यानलमा समावेश गर्दछ। फ्रन्टएन्ड प्राप्त गर्ने अनुरोधहरू र ब्याकएन्ड प्रशोधन अनुरोधहरू जडान गर्न, लामो समयसम्म चल्ने TCP जडान स्थापना गरिएको छ, जसको माध्यमबाट प्रयोगकर्ता अनुरोधहरू प्रसारण गरिन्छ, एकपछि अर्को श्रृंखलामा प्रसारण गरिन्छ, HTTP प्रोटोकलको माध्यमबाट छुट्याइन्छ। अनुरोधहरू अलग गर्न, हेडरहरू "सामग्री-लम्बाइ" (अनुरोधमा डेटाको कुल आकार निर्धारण गर्दछ) र "स्थानान्तरण-इन्कोडिङ: टुक्रा"("{size}\r\n{block}\r\n{size}\r\n{block}\r\n0" ढाँचामा बिभिन्न साइजका ब्लकहरू निर्दिष्ट गर्दै, तपाईंलाई भागहरूमा डाटा स्थानान्तरण गर्न अनुमति दिन्छ)।

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

यस अवस्थामा, एक आक्रमणकारीले अनुरोध पठाउन सक्छ जसमा "सामग्री-लम्बाइ" र "स्थानान्तरण-इन्कोडिङ: chunked" हेडरहरू समावेश छन्, तर "सामग्री-लम्बाइ" मा आकार chunked चेनको आकारसँग मेल खाँदैन, जुन। वास्तविक मूल्य भन्दा सानो छ। यदि फ्रन्टएन्डले "सामग्री-लम्बाइ" अनुसार अनुरोधलाई प्रक्रिया र फर्वार्ड गर्छ र ब्याकएन्डले "स्थानान्तरण-इन्कोडिङ: chunked" मा आधारित ब्लक पूरा हुनको लागि पर्खन्छ भने, "स्थानान्तरण-इन्कोडिङ: chunked" मा आधारित डाटाको अन्त्य हुनेछ। पहिले नै निर्धारण गर्नुहोस् र अनुरोधको बाँकी पुच्छर आक्रमणकारी अर्को अनुरोधको सुरुमा हुनेछ, अर्थात्। आक्रमणकर्ताले अर्को कसैको अनुरोधको सुरुमा मनमानी डाटा संलग्न गर्न सक्षम हुनेछ।

प्रयोग गरिएको फ्रन्टएन्ड-ब्याकेन्ड संयोजनमा समस्या निर्धारण गर्न, तपाइँ फ्रन्टएन्ड मार्फत यस प्रकारको अनुरोध पठाउन सक्नुहुन्छ:

POST/HTTP/1.1 को बारेमा
होस्ट: example.com
स्थानान्तरण-इन्कोडिङ: टुक्रा
सामग्री-लम्बाई: १4

1
Z
Q

यदि ब्याकइन्डले तुरुन्तै अनुरोधलाई प्रशोधन गर्दैन र chunked डाटाको अन्तिम शून्य बाउन्डिङ ब्लकको आगमनको लागि पर्खन्छ भने समस्या उपस्थित हुन्छ। थप पूर्ण जाँचको लागि तयार एक विशेष उपयोगिता जसले फ्रन्टएन्डबाट "स्थानान्तरण-इन्कोडिङ: 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 अनुरोधलाई paypal.com/us/gifts पृष्ठको सन्दर्भमा जाभास्क्रिप्ट कार्यान्वयन गर्न परिमार्जन गरिएको थियो। जुन CSP (सामग्री सुरक्षा नीति) लागू गरिएको थिएन)।

चाखलाग्दो कुरा, त्यहाँ 2005 मा थियो प्रस्तावित अनिवार्य रूपमा समान अनुरोध स्पूफिङ प्रविधि जसले तपाइँलाई क्यासिङ प्रोक्सीहरू (Tomcat, squid, mod_proxy) मा डाटा स्पूफ गर्न वा एक HTTP सत्र भित्र धेरै "GET" वा "POST" अनुरोधहरू निर्दिष्ट गरेर फायरवाल ब्लकिङलाई बाइपास गर्न अनुमति दिन्छ।

स्रोत: opennet.ru