Ez a cikk bemutat néhány biztonsági problémát a HTTP protokollal kapcsolatban , amelyek két dokumentumban, az RFC 7230-ban és az RFC 7231-ben merültek fel. A konkrét hibákról szóló cikkben szereplő példák az OWASP-ből származnak.
1. Köztes tényezők kockázatai
A HTTP lehetővé teszi a közvetítők használatát, hogy egy sor kapcsolaton keresztül válaszoljanak a kérésekre. Három gyakori közvetítő elem van: proxy, átjáró és alagút.
A kérésnek vagy válasznak át kell mennie az A, B és C ponton. Hozzáférhetnek a továbbított érzékeny információkhoz, például a felhasználók vagy szervezetek személyes adataihoz. Az, hogy a közvetítők nem fordítanak figyelmet a biztonságra és a magánélet védelmére, számos lehetséges támadáshoz vezethet.
A rendszerfejlesztőknek és -fejlesztőknek figyelembe kell venniük az adatvédelmi és biztonsági tényezőket a rendszer tervezése, kódolása és telepítése során.
A felhasználóknak tisztában kell lenniük a nem megbízható proxy-k vagy átjárók használatával járó veszélyekkel.
2. Válasz felosztása
A válaszfelosztás (más néven CRLF injekció) egy népszerű webes kihasználási technika. A támadó néhány kérési paraméterben kódolt adatokat küld, amelyeket aztán dekódol, és megismétel a válaszfejléc egy bizonyos mezőjében.
Ha ez az adat a válasz végét jelző szimbólum, és egy következő válasz indul, akkor az eredeti válasz két részre oszlik, és a második válasz tartalmát a támadó irányítja. A támadó ezután újabb kérést indíthat ugyanazon az állandó kapcsolaton belül, és elhiteti a címzetttel (beleértve a közvetítőket is), hogy ez a második válasz válasz a második kérésre.
3. Csempészet kérése
A kéréscsempészet olyan technika, amely kihasználja a kérések különböző típusú szerverek általi feldolgozásának különbségeit, hogy elrejtse az eredeti kéréshez csatolt, ártalmatlannak tűnő kéréseket.
Tekintsük a következő példát:
Tegyük fel, hogy egy POST kérés két „Content-length” mezőt tartalmaz a fejlécben, két különböző értékkel. Egyes szerverek (IIS és Apache) elutasítják ezt a kérést, mások azonban nem. Például a SunONE W/S 6.1 először a Tartalom hossz mezőt használja, míg a sunONE Proxy 3.6 második a Tartalom hossz mezőt.
Feltételezve, hogy a SITE egy SunONE W/S DNS-e, amely egy SunONE proxy mögött található, a SunONE W/S-en található egy poison.html fájl. A két szerver közötti feldolgozás következetlenségei alapján a következőképpen lehet kihasználni a HTTP Request Suggling funkciót:

[Ne feledje, hogy minden sor CRLF-re ("") végződik, kivéve a 10. sort]
Nézzük meg, mi történik, ha egy kérést küldenek a W/S-nek a proxyszerveren keresztül. Először a proxy elemzi a kérést az 1–7. sorok között (kék), és találkozik két Tartalomhossz mezővel. Ahogy fentebb említettük, figyelmen kívül hagyja az első mezőt, és megérti, hogy a kérés törzse 44 bájt hosszú. Ezért a 8–10. sorok adatait az első kéréstörzsként kezeli (a 8–10. sorok között az adatok pontosan 44 bájt hosszúak). A proxy ezután az ügyfél második kéréseként elemzi a 11–14. sorokat (piros színnel).
Most nézzük meg, hogyan értelmezi a W/S a fenti adatokat, mivel azokat a proxytól továbbítják. A proxykkal ellentétben a W/S az első Content-Length mezőt fogja használni, és a következőképpen értelmezi: az első kérésnek nincs törzse, a második kérés pedig a 8. sortól kezdődik (vegye figyelembe, hogy a W/S a 11. sortól kezdődően elemzi értékként a Bla mez).
Ezután nézzük meg, hogyan küldik vissza a választ az ügyfélnek. A W/S által megértett kérés a „POST /foobar.html” (az 1. sorból) és a „GET /poison.html” (a 8. sorból), tehát 2 választ küld az ügyfélnek a foobar oldal tartalmával. html és poison.html. A proxy megérti, hogy ez a 2 válasz 2 kérésnek felel meg: "POST /foobar.html" (az 1. sorból) és "GET /page_to_poison.html" (11. sor). A proxy a gyorsítótárban tárolja a „poison_to_poison.html” URL-nek megfelelő poison.html oldal tartalmát (gyorsítótár-mérgezés). Innentől kezdve, amikor a kliens a "page_to_poison.html"-t kéri, megkapja a poison.html oldal tartalmát.
4. Támadás a fájl elérési útja alapján
A webszerverek gyakran a helyi fájlrendszerüket használják az URI-k fájlneveinek a szerver tényleges erőforrásaihoz való hozzárendelésének kezelésére. A legtöbb fájlrendszert nem úgy tervezték, hogy védjen a rosszindulatú fájl útvonalak ellen. Ezért a szervernek kerülnie kell a fontos rendszerfájlok elérését.
Például a UNIX, a Microsoft Windows és számos más operációs rendszer a „..” karakterláncot használja útvonalelemként, amely egy szinttel az aktuális fájl/könyvtár feletti könyvtárat ábrázolja. Megfelelő bevitel-ellenőrzés és jogosultság nélkül a rendszer érzékeny fájljai/mappái az ezekre a fájlokra/mappákra mutató útvonalak megadásával érhetők el.
5. A támadások típusai: Command Injection, Code Injection, Query Injection
[A webszerverek gyakran használják az URI paramétereit bemenetként a rendszerparancsok és adatbázis-lekérdezések végrehajtásához. A kérelemben kapott adatokban azonban nem mindig lehet megbízni. A támadó létrehozhat és módosíthat összetevőket a kérésben (például metódusokat, mezőket a fejlécben, törzset...), rendszerparancsok végrehajtásához, adatbázis lekérdezéséhez...
Például az SQL Injection egy gyakori támadás, amelyben a webszerver az URI-ban olyan paramétereket kap, amelyek az SQL-lekérdezés részét képezik. Ezért a támadók rávehetik a webszervert, hogy illegális SQL-lekérdezéseket hajtson végre az adatbázis ellopása vagy szabotálása érdekében.
Általánosságban elmondható, hogy a felhasználók által benyújtott adatokat nem szabad közvetlenül a szerveren végrehajtani. Ezeknek az adatoknak szűrőkön kell keresztülmenniük, amelyek meghatározzák, hogy mi az érvényes és mi az érvénytelen, ezáltal kiküszöbölve a nem kívánt adatokat.
6. Személyes adatok felfedése
Az ügyfelek gyakran sok személyes információt tartalmaznak, beleértve a felhasználó által a szerverrel való interakcióhoz biztosított információkat (például felhasználónév, jelszó, hely, e-mail cím stb.), valamint a felhasználó webböngészési tevékenységeivel kapcsolatos információkat (előzmények, könyvjelzők, stb.). A megvalósítás során ügyelni kell arra, hogy elkerüljük azokat a pontokat, amelyek felfedhetik ezeket a személyes információkat.
7. Érzékeny információk felfedése az URI-ban
Az URI-k tervezésénél fogva minden felhasználóval megoszthatók, és nem garantált, hogy biztonságosak. Az URI-k gyakran megjelennek a webhely forráskódjában, és védelmi mechanizmusok nélkül a könyvjelzőkben tárolódnak. Ezért nem lesz biztonságos, ha az URI érzékeny információkat, személyes adatokat stb. tartalmaz.
Kerülje a GET metódus használatát személyes adatok kiszolgálóra küldésére, mivel azok megjelennek az URI-ban. Használja helyette a POST módszert.
8. A használt szoftverinformációk feltárása
A fejlécben található User-Agent, Via, Server mezők általában a küldő által használt szoftverről adnak információt. Elméletileg ez lehetővé teszi a támadók számára, hogy könnyebben kihasználják a szoftverek ismert sebezhetőségeit.