Antetele Django ASGI cer o limită de încredere clară
Corecția antetelor Django ASGI arată de ce filtrarea în proxy și normalizarea în aplicație trebuie analizate împreună, în condițiile instalării reale.
De 
Paul. Arhitectură și infrastructură
Un proxy invers poate elimina un antet sensibil, iar aplicația poate accepta în continuare o formă echivalentă a numelui său. Limita de încredere cuprinde toate transformările dintre cererea publică și valoarea în care aplicația are încredere. Avertizarea Django despre antetele ASGI arată de ce regulile de filtrare și regulile de normalizare a numelor trebuie să se potrivească.
La 7 aprilie 2026, Django a publicat CVE-2026-3902 și corecțiile din versiunile 6.0.4, 5.2.13 și 4.2.30. Echipa a clasificat problema cu severitate scăzută, „low”. Acestea sunt versiunile corectate atunci, nu o listă a celor mai recente versiuni și nici o evaluare a unei anumite instalări. Anunțul oficial explică mecanismul și limitele lui.
Două nume pot ajunge la aceeași valoare
Avertizarea descrie felul în care ASGIRequest înlocuia cratimele din numele antetelor cu linii de subliniere, după convențiile WSGI. Un proxy putea elimina un antet sensibil cu cratime în nume, dar putea accepta un nume cu linii de subliniere. Dacă aplicația transforma apoi ambele variante în același nume intern, regula de eliminare nu mai stabilea limita dorită. Componentele interpretau diferit identitatea antetului.
Distincția contează când analizați un sistem. O regulă de eliminare dovedește că o anumită formă este tratată în acea componentă. Nu dovedește că sunt tratate toate intrările care ajung la aceeași valoare în aplicație. Întrebarea utilă privește intrările publice care pot ajunge la numele intern de încredere după toate transformările. Ea rămâne relevantă chiar dacă fiecare componentă respectă propriile convenții documentate.
Notele versiunii Django 6.0.4 separă convenția WSGI de situația ASGI. În WSGI, serverul sau proxy-ul are responsabilitatea de a evita corespondențele ambigue. În ASGI nu exista aceeași așteptare uniformă. Corecția face ca ASGIRequest să ignore antetele care conțin linii de subliniere, la fel ca Daphne. Trecerea între interfețele de servire justifică astfel reexaminarea presupunerilor preluate din configurația anterioară.
Urmăriți valoarea prin sistem
O analiză de proiectare utilă începe cu valoarea căreia aplicația îi acordă autoritate. Stabiliți ce componentă are voie să o furnizeze și prin ce trasee publice poate ajunge o cerere la acea componentă. Urmăriți apoi numele prin proxy și prin adaptorul aplicației. Dacă păstrați valoarea în centrul analizei, discuția despre semnele din numele antetelor rămâne legată de motivul pentru care antetul este sensibil.
Aceasta este o recomandare pentru examinarea contractului dintre componentele instalate. Nu este o dovadă că o anumită instalare este vulnerabilă. Contează interfața de servire folosită efectiv și comportamentul traseului real prin proxy. O schemă în care apare o casetă numită „proxy” nu stabilește cum tratează acea componentă liniile de subliniere. Nici versiunea cadrului software nu explică singură dacă o variantă controlată de atacator ajunge la o valoare cu autoritate.
Analiza ar trebui să arate și cine răspunde de fiecare parte. Cineva ar trebui să poată explica unde sunt respinse intrările ambigue ale clientului și unde sunt introduse informațiile de încredere. Dacă echipa de infrastructură și echipa aplicației împart aceste responsabilități, predarea dintre ele ar trebui să precizeze numele acceptate. Altfel, fiecare echipă poate indica o regulă rezonabilă local, fără ca cineva să fi verificat interpretarea completă.
Aceeași logică se aplică atunci când se schimbă instalarea. Înlocuirea unui adaptor sau schimbarea traseului prin proxy poate invalida o explicație corectă anterior. Tratați explicația ca pe o afirmație despre un traseu concret al cererii. Ar trebui să puteți identifica presupunerile care cer o nouă evaluare, fără a transforma orice schimbare de infrastructură într-o afirmație că s-a produs un incident de securitate.
Protecția implicită limitează expunerea
Cea mai puternică obiecție față de avertismentele generale apare chiar în comunicatul Django: multe componente proxy oferă deja protecție prin configurația implicită. Anunțul menționează explicit că nginx respinge implicit antetele cu linii de subliniere. O instalare care elimină această variantă înainte ca ea să ajungă la Django poate bloca deja traseul descris. Ar fi înșelător să prezentați toate instalările ASGI ca exploatabile în orice condiții.
Obiecția restrânge afirmația despre expunere. Tot ea explică de ce analiza de securitate ar trebui să folosească dovezi despre instalare. Existența unui comportament implicit de protecție este o informație utilă, dar relevanța sa depinde de aplicarea lui pe traseul cererii analizate. Echipa ar trebui să distingă între valorile implicite documentate, configurația pe care se bazează și un rezultat observat.
Severitatea scăzută trebuie păstrată în explicație. Aceasta este clasificarea oficială a problemei; formularea „falsificarea antetelor” nu justifică inventarea unei clasificări mai grave. Prioritatea locală poate ține cont de rolul antetului afectat și de condițiile instalării. O evaluare mai severă ar trebui să numească acele condiții și dovezile proprii. Sursa nu le stabilește pentru o aplicație necunoscută.
Formulați o decizie precisă
Rezultatul practic ar trebui să descrie limita de încredere: ce nume de intrare sunt acceptate, cum devin nume interne și unde sunt oprite variantele care nu sunt de încredere. Actualizarea versiunilor aflate în suport rămâne parte din mentenanța obișnuită. Totuși, versiunile din aprilie nu ar trebui copiate într-o recomandare de actualizare din noiembrie ca și cum timpul s-ar fi oprit. Suportul actual și mediul aplicației cer o verificare separată.
Dacă pregătiți un proiect de dezvoltare software la comandă, includeți acest subiect în criteriile de acceptare. Cereți o explicație despre felul în care aplicația primește informații de încredere de la proxy și despre cine răspunde de acest contract după predare. Corecția cadrului software tratează mecanismul publicat. Un contract clar între componente îl ajută pe următorul responsabil să recunoască schimbările care ating aceeași limită.