Kicsit ásni kellett, míg megtaláltam, de megtaláltam ezt, amely úgy tűnik, hogy megválaszolja a kérdést:

https://www.djangoproject.com/weblog/2013/feb / 19 / security / # s-issue-host-header-mérgezés

Probléma: Host fejlécmérgezés

Több korábbi A Django biztonsági kiadások megpróbálták megoldani a HTTP gazdagép fejlécével kapcsolatos állandó problémákat. A Django kódot tartalmaz - és a Django által szállított egyes funkciók maguk is ezt a kódot használják - egy teljesen minősített URL összeállításához a bejövő HTTP kérés alapján. A konfigurációtól függően ez a Host fejlécet használja, és így egy olyan támadó, aki a Django alkalmazást arra késztetheti, hogy tetszőleges gazdagép fejlécekre válaszoljon, arra késztetheti a Django-t, hogy tetszőleges domaineken URL-eket generáljon és jelenítsen meg a végfelhasználók számára.

A kiadás korábbi iterációi (lásd: CVE-2011-4139 és CVE-2012-4520) arra összpontosítottak, hogy szigorítsák Django Host fejléceit, hogy kiküszöböljék a támadók különféle eszközeit - olyan technikákat használva, mint a felhasználónév / jelszó párok beküldött Host fejléc - kihasználhatja ezt.

Végül azonban Django önmagában nem tudja biztosítani, hogy a támadó ne tudjon beküldeni önkényes Host fejléceket, és Django-t elfogadja. Ennek megfelelő telepítése a telepített Django példányban emellett megköveteli a webszerver konfigurálását, és mind a konfiguráció, mind az elérhető biztonsági szint az alkalmazott szervertől függ.

Ennek fényében a get_host () metódus A django.http.HttpRequest mostantól egy új beállítással, az ALLOWED_HOSTS ellenõrzi a Host fejlécet. Ez a beállítás egy olyan karaktersorozatok listája (alapértelmezés szerint egy üres lista), amelyek megfelelnek a fejléc elfogadható értékeinek, némi támogatással a helyettesítő karakterekre.

Kód, amely nem használja a get_host () vagy a Django konfigurációkat, amelyek képesek az aktuális hosztnév meghatározása HTTP fejlécek igénybevétele nélkül (azaz amikor a Django webhelyek keretrendszere engedélyezve van), ez nem lesz hatással változás.

Mivel ez egy korábbi kiadás keményítése / szigorítása, ezért nincs új CVE száma.

James Kettle jó írást készít a gyakorlati HTTP gazdagép fejléc támadásairól. Ezeket itt foglaljuk össze a Django ALLOWED_HOSTS stratégia leírásával.

Sebezhetőségek

Jelszó-visszaállító vektor

A jelszó-visszaállító e-mail biztonsági rés, amelyre a dokumentáció utal, egy a Django és / vagy alkalmazásai eredményei, amelyek a kliens által biztosított HTTP gazdagépet használják és megbíznak benne (rossz ötletnek hangzik?). A gazdagépet közvetlenül a jelszó-visszaállító e-mailekbe másolják, ami hasznos injektálási vektort nyújt.

Gyorsítótár-mérgezés

A gyorsítótár-mérgezés változata erre a viselkedésre támaszkodik, valamint az eltérő módokon. A HOST fejlécet kiszolgálók és gyorsítótár-megoldások kezelik.

HTTP_SERVER vs HTTP ['HOST']

Amint a Kettle leírja, az RFC2616 miatt kompatibilis szerverekkel lehet eltérést használni a HTTP_SERVER és a HTTP ['HOST'] között tetszőleges gazdagép-karakterláncok előállításához.

Gépelemzés

Különböző formátumok kihasználásával és speciális karakterek használatával a támadó "engedélyezett" hosztot okozhat rosszindulatúan kell értelmezni a különböző összefüggésekben. Ez ismét hiba az alkalmazásban, amely megbízott a hoszt karakterláncában.

Django megoldás

Amint a Catskul által biztosított kiadási megjegyzések összefoglalják, a Django megoldás hogy a felhasználó az engedélyezett gazdagépeket betegye közvetlenül a projekt kódjába. Azáltal, hogy betilt minden olyan állomást, amely nem felel meg az ALLOWED_HOSTS -nak, kiküszöböli az injekciós vektort (a „fehér lista” megközelítés).

Ez valami nehézkes megoldás, mint James rámutat, de meglehetősen hatékony is.

Ne feledje

Lehetséges helyettesítő karakterek használata a projekt beállításaiban, ebben az esetben ez a funkció nem segít semmit sem biztosítani.

A biztonságos alkalmazásfejlesztő elkerüli a HTTP gazdagép értelmes használatát.

Hivatkozások

Carlos Bueno, Gyorsítótár-mérgezés (2008)