Problemin mahiyyəti ondan ibarətdir ki, frontend və backendlər tez-tez HTTP protokolu üçün müxtəlif səviyyələrdə dəstək təmin edir, lakin eyni zamanda müxtəlif istifadəçilərdən gələn sorğuları ümumi kanalda əhatə edir. Frontend qəbul sorğularını və backend emal sorğularını birləşdirmək üçün uzunömürlü TCP bağlantısı qurulur, onun vasitəsilə istifadəçi sorğuları HTTP protokolu vasitəsilə bir-birinin ardınca zəncir boyu ötürülür. Sorğuları ayırmaq üçün "Məzmun uzunluğu" (sorğudakı məlumatların ümumi ölçüsünü müəyyən edir) və " başlıqları
Problem, əgər frontend yalnız “Məzmun uzunluğu”nu dəstəkləyirsə, lakin “Transfer-kodlaşdırma: parçalanmış” (məsələn, Akamai CDN bunu edib) və ya əksinə məhəl qoymursa yaranır. Əgər Transfer-Encoding: chunked hər iki tərəfdən dəstəklənirsə, HTTP başlıq təhlilçilərinin tətbiqi xüsusiyyətləri hücum üçün istifadə edilə bilər (məsələn, ön hissə “Transfer-Encoding: xchunked”, “Transfer-Encoding: chunked” kimi sətirlərə məhəl qoymadıqda ”, “Transfer-Encoding” :[tab]parçalanmış”, “X: X[\n]Transfer-Encoding: chunked”, “Transfer-Encoding[\n]: chunked” və ya “Transfer-Encoding: chunked” və backend onları uğurla emal edir).
Bu halda, təcavüzkar həm "Məzmun uzunluğu" və "Transfer-kodlaşdırma: parçalanmış" başlıqlarını ehtiva edən sorğu göndərə bilər, lakin "Məzmun uzunluğu"ndakı ölçü parçalanmış zəncirin ölçüsünə uyğun gəlmir. faktiki dəyərdən kiçikdir. Əgər frontend sorğunu "Məzmun uzunluğu"na uyğun olaraq emal edir və yönləndirirsə və arxa uç "Transfer-Encoding: chunked" əsasında blokun tamamlanmasını gözləyirsə, o zaman "Transfer-Encoding: chunked" əsasında verilənlərin sonu daha əvvəl müəyyən ediləcək və tələbin qalan quyruğu təcavüzkar növbəti sorğunun əvvəlində olacaq, yəni. təcavüzkar növbəti ötürülən başqasının sorğusunun başlanğıcına ixtiyari məlumatları əlavə edə biləcək.
Istifadə olunan frontend-backend birləşməsindəki problemi müəyyən etmək üçün siz frontend vasitəsilə bu kimi sorğu göndərə bilərsiniz:
POST / HTTP haqqında/1.1
Ev sahibi: example.com
Transfer-kodlaşdırma: parçalanmış
Content-Length: 4
1
Z
Q
Problem, əgər backend sorğunu dərhal emal etmirsə və parçalanmış məlumatların son sıfır məhdudlaşdırıcı blokunun gəlməsini gözləyirsə, mövcuddur. Daha tam yoxlama üçün
Həqiqi hücumun həyata keçirilməsi hücuma məruz qalan saytın imkanlarından asılıdır, məsələn, Trello veb proqramına hücum edərkən siz sorğunun başlanğıcını əvəz edə bilərsiniz (“PUT /1/members/1234... x=x&csrf” kimi məlumatları əvəz edin. =1234&username=testzzz&bio=cake”) və üçüncü tərəf istifadəçisinin orijinal sorğusu və orada göstərilən autentifikasiya kukisi daxil olmaqla mesaj göndərin. Saas-app.com saytına hücum üçün sorğu parametrlərindən birində onu əvəz etməklə cavabda JavaScript kodunu əvəz etmək mümkün olub. Redhat.com-a hücum üçün təcavüzkarın veb saytına yönləndirmək üçün daxili işləyicidən istifadə edilib (“POST /search?dest=../assets/idx?redir=// formasının sorğusu).[e-poçt qorunur]/ HTTP/1.1").
Məzmun çatdırılması şəbəkələri üçün metoddan istifadə “Host:” başlığını əvəz etməklə tələb olunan saytı sadəcə əvəz etməyə imkan verdi. Hücum həmçinin məzmun keşləmə sistemlərinin məzmununu zəhərləmək və keşlənmiş məxfi məlumatları çıxarmaq üçün də istifadə edilə bilər. Metodun zirvəsi PayPal-a hücumun təşkili idi ki, bu da autentifikasiya zamanı istifadəçilər tərəfindən göndərilən parolları ələ keçirməyə imkan verirdi (iframe sorğusu paypal.com/us/gifts səhifəsi kontekstində JavaScript-i yerinə yetirmək üçün dəyişdirilib. hansı CSP (Məzmun Təhlükəsizliyi Siyasəti) tətbiq edilməmişdir).
Maraqlıdır ki, 2005-ci ildə var idi
Mənbə: opennet.ru