முன்-இறுதி-பின்-இறுதி அமைப்புகளின் மீதான தாக்குதல், இது மூன்றாம் தரப்பு கோரிக்கைகளில் நம்மை இணைக்க அனுமதிக்கிறது

வெளிப்படுத்தப்பட்டது உள்ளடக்க டெலிவரி நெட்வொர்க்குகள், லோட் பேலன்சர்கள் அல்லது ப்ராக்ஸிகள் மூலம் இயங்கும் தளங்களின் முன்-இறுதி-பின்-இறுதி மாதிரியைப் பயன்படுத்தும் புதிய தாக்குதலின் விவரங்கள். தாக்குதலானது, சில கோரிக்கைகளை அனுப்புவதன் மூலம், முன்பக்கம் மற்றும் பின்தளத்திற்கு இடையில் அதே தொடரிழையில் செயலாக்கப்பட்ட பிற கோரிக்கைகளின் உள்ளடக்கங்களை இணைக்க அனுமதிக்கிறது. முன்மொழியப்பட்ட முறை வெற்றிகரமாக ஒரு தாக்குதலை ஒழுங்கமைக்கப் பயன்படுத்தப்பட்டது, இது பேபால் சேவையின் பயனர்களின் அங்கீகார அளவுருக்களை இடைமறிக்க முடிந்தது, இது இணைக்கப்படாத பாதிப்புகள் இருப்பதைப் பற்றி தெரிவிக்க ஒரு திட்டத்தின் ஒரு பகுதியாக ஆராய்ச்சியாளர்களுக்கு சுமார் 40 ஆயிரம் டாலர்களை வழங்கியது. Akamai உள்ளடக்க விநியோக நெட்வொர்க்கைப் பயன்படுத்தும் தளங்களுக்கும் இந்தத் தாக்குதல் பொருந்தும்.

பிரச்சனையின் முக்கிய அம்சம் என்னவென்றால், முன்முனைகள் மற்றும் பின்தளங்கள் பெரும்பாலும் HTTP நெறிமுறைக்கு வெவ்வேறு நிலை ஆதரவை வழங்குகின்றன, ஆனால் அதே நேரத்தில் வெவ்வேறு பயனர்களிடமிருந்து கோரிக்கைகளை ஒரு பொதுவான சேனலில் இணைக்கின்றன. முன்பக்கம் பெறும் கோரிக்கைகள் மற்றும் பின்தள செயலாக்க கோரிக்கைகளை இணைக்க, நீண்ட கால TCP இணைப்பு நிறுவப்பட்டது, இதன் மூலம் பயனர் கோரிக்கைகள் அனுப்பப்பட்டு, ஒன்றன் பின் ஒன்றாக சங்கிலியில் அனுப்பப்பட்டு, HTTP நெறிமுறை மூலம் பிரிக்கப்படுகிறது. கோரிக்கைகளை பிரிக்க, தலைப்புகள் "உள்ளடக்கம்-நீளம்" (கோரிக்கையில் உள்ள தரவின் மொத்த அளவை தீர்மானிக்கிறது) மற்றும் "பரிமாற்ற-குறியீடு: துண்டானது"("{size}\r\n{block}\r\n{size}\r\n{block}\r\n0" வடிவத்தில் வெவ்வேறு அளவுகளின் தொகுதிகளைக் குறிப்பிடுவதன் மூலம், பகுதிகளாகத் தரவை மாற்ற உங்களை அனுமதிக்கிறது).

முன்பக்கம் "உள்ளடக்க நீளம்" என்பதை மட்டுமே ஆதரிக்கிறது, ஆனால் "பரிமாற்றம்-குறியீடு: துண்டானது" (உதாரணமாக, Akamai CDN இதைச் செய்தது) அல்லது நேர்மாறாகப் புறக்கணித்தால் சிக்கல் எழுகிறது. Transfer-Encoding: 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", மற்றும் பின்தளம் அவற்றை வெற்றிகரமாக செயலாக்குகிறது).

இந்த வழக்கில், தாக்குபவர் "உள்ளடக்கம்-நீளம்" மற்றும் "பரிமாற்றம்-குறியீடு: துண்டிக்கப்பட்ட" தலைப்புகள் இரண்டையும் கொண்ட கோரிக்கையை அனுப்பலாம், ஆனால் "உள்ளடக்கம்-நீளம்" இல் உள்ள அளவு துண்டிக்கப்பட்ட சங்கிலியின் அளவிற்கு ஒத்திருக்காது. உண்மையான மதிப்பை விட சிறியது. "உள்ளடக்கம்-நீளம்" படி முன்தளமானது கோரிக்கையை செயலாக்கி அனுப்பினால், பின்தளமானது "பரிமாற்றம்-குறியாக்கம்: துண்டிக்கப்பட்டது" என்பதன் அடிப்படையில் பிளாக் முடிவடையும் வரை காத்திருந்தால், பின்னர் "பரிமாற்றம்-குறியாக்கம்: துண்டானது" என்பதன் அடிப்படையில் தரவின் முடிவு முன்னதாகவே தீர்மானிக்கப்படும் மற்றும் கோரிக்கையின் மீதமுள்ள வால் அடுத்த கோரிக்கையின் தொடக்கத்தில் தாக்குபவர் இருக்கும், அதாவது. அடுத்ததாக அனுப்பப்படும் வேறொருவரின் கோரிக்கையின் தொடக்கத்தில் தாக்குபவர் தன்னிச்சையான தரவை இணைக்க முடியும்.

பயன்படுத்திய ஃபிரண்ட்எண்ட்-பேக்கெண்ட் கலவையில் உள்ள சிக்கலைத் தீர்மானிக்க, இது போன்ற கோரிக்கையை ஃபிரண்டெண்ட் வழியாக அனுப்பலாம்:

இடுகை / HTTP/1.1 பற்றி
புரவலன்: example.com
பரிமாற்ற-குறியீடு: துண்டானது
உள்ளடக்க நீளம்: 4

1
Z
Q

பின்தளமானது கோரிக்கையை உடனடியாகச் செயல்படுத்தவில்லை மற்றும் துண்டிக்கப்பட்ட தரவின் இறுதி பூஜ்ஜிய எல்லைத் தொகுதியின் வருகைக்காகக் காத்திருந்தால் சிக்கல் உள்ளது. மேலும் முழுமையான சரிபார்ப்பிற்கு தயார் "பரிமாற்றம்-குறியீடு: துண்டிக்கப்பட்ட" தலைப்பை முகப்பில் இருந்து மறைப்பதற்கான சாத்தியமான முறைகளையும் சோதிக்கும் ஒரு சிறப்பு பயன்பாடு.

உண்மையான தாக்குதலை நடத்துவது, தாக்கப்பட்ட தளத்தின் திறன்களைப் பொறுத்தது, எடுத்துக்காட்டாக, ட்ரெல்லோ வலைப் பயன்பாட்டைத் தாக்கும்போது, ​​கோரிக்கையின் தொடக்கத்தை நீங்கள் மாற்றலாம் (“PUT /1/members/1234... x=x&csrf போன்ற மாற்றுத் தரவு =1234&username=testzzz&bio=cake”) மற்றும் மூன்றாம் தரப்பு பயனரின் அசல் கோரிக்கை மற்றும் அதில் குறிப்பிடப்பட்டுள்ள அங்கீகார குக்கீ உள்ளிட்ட செய்தியை அனுப்பவும். saas-app.com மீதான தாக்குதலுக்கு, கோரிக்கை அளவுருக்கள் ஒன்றில் பதிலளிப்பதன் மூலம் ஜாவாஸ்கிரிப்ட் குறியீட்டை மாற்றியமைக்க முடியும். redhat.com மீதான தாக்குதலுக்கு, தாக்குபவரின் இணையதளத்திற்கு திருப்பிவிட ஒரு உள் கையாளுதல் பயன்படுத்தப்பட்டது (“POST /search?dest=../assets/idx?redir=// படிவத்தின் கோரிக்கை[மின்னஞ்சல் பாதுகாக்கப்பட்டது]/ HTTP/1.1").

உள்ளடக்க டெலிவரி நெட்வொர்க்குகளுக்கான முறையைப் பயன்படுத்தி, "ஹோஸ்ட்:" தலைப்பை மாற்றுவதன் மூலம் கோரப்பட்ட தளத்தை மாற்றுவது சாத்தியமாக்கியது. இந்தத் தாக்குதலை உள்ளடக்க கேச்சிங் அமைப்புகளின் உள்ளடக்கங்களை விஷமாக்குவதற்கும், தேக்ககப்படுத்தப்பட்ட ரகசியத் தரவைப் பிரித்தெடுப்பதற்கும் பயன்படுத்தலாம். இந்த முறையின் உச்சம் PayPal மீதான தாக்குதலின் அமைப்பு ஆகும், இது அங்கீகாரத்தின் போது பயனர்கள் அனுப்பிய கடவுச்சொற்களை இடைமறிப்பது சாத்தியமாக்கியது (paypal.com/us/gifts பக்கத்தின் பின்னணியில் JavaScript ஐ இயக்க iframe கோரிக்கை மாற்றப்பட்டது. எந்த CSP (உள்ளடக்க பாதுகாப்புக் கொள்கை) பயன்படுத்தப்படவில்லை).

சுவாரஸ்யமாக, 2005 இல் இருந்தது ப்ரெட்லோஜெனா ஒரு HTTP அமர்வில் பல "GET" அல்லது "POST" கோரிக்கைகளைக் குறிப்பிடுவதன் மூலம், கேச்சிங் ப்ராக்ஸிகளில் (Tomcat, squid, mod_proxy) தரவை ஏமாற்ற அல்லது பைபாஸ் ஃபயர்வால் தடுப்பை அனுமதிக்கும் அடிப்படையில் இதே போன்ற கோரிக்கை ஏமாற்றுதல் நுட்பம்.

ஆதாரம்: opennet.ru