mi az a CRLF?

amikor egy böngésző kérést küld egy webszervernek, a webszerver válaszol egy válaszra, amely tartalmazza mind a HTTP válaszfejléceket, mind a webhely tényleges tartalmát, azaz a választestet. A HTTP fejléceket és a HTML-választ (a weboldal tartalmát) speciális karakterekből álló speciális kombináció választja el egymástól, nevezetesen egy kocsi-visszatérést és egy sorjelzést. Röviden ők is ismert CRLF.

a webszerver a CRLF-et használja annak megértéséhez, hogy mikor kezdődik az új HTTP fejléc, a másik pedig véget ér. A CRLF azt is elmondhatja egy webes alkalmazásnak vagy felhasználónak, hogy egy új sor kezdődik egy fájlban vagy egy szövegblokkban. A CRLF karakterek egy szabványos HTTP/1.1 üzenet, így használják bármilyen típusú webszerver, beleértve az Apache, Microsoft IIS, és az összes többi.

mi a CRLF Injection sebezhetőség?

egy CRLF injekció biztonsági rés támadás a támadó lapkák mind a kocsi visszát sornövelés karakter felhasználói input, hogy trükk, a szerver, a webes alkalmazás vagy a felhasználó azt gondolni, hogy egy objektum megszűnik, a másik kezdte. Mint ilyen, a CRLF szekvenciák nem rosszindulatú karakterek, azonban fel lehet használni a rosszindulatú szándék, HTTP válasz felosztása stb.

CRLF injection in web applications

In web applications a CRLF injekciónak súlyos hatásai lehetnek, attól függően, hogy az alkalmazás mit tesz az egyes tételekkel. A hatások az információk közzétételétől a kód végrehajtásáig terjedhetnek, amely közvetlen hatással van a webes alkalmazás biztonsági sebezhetőségére. Valójában egy CRLF injekciós támadás nagyon súlyos következményekkel járhat egy webes alkalmazásra, annak ellenére, hogy soha nem szerepelt az OWASP Top 10 listáján. Például lehetőség van a naplófájlok manipulálására egy admin panelen, az alábbi példában leírtak szerint.

példa a CRLF injekcióra egy naplófájlban

Képzeljen el egy naplófájlt egy admin panelen az IP – idő által látogatott elérési út kimeneti adatfolyammintájával, például az alábbiakkal:

123.123.123.123 - 08:15 - /index.php?page=home

Ha a támadó be tudja fecskendezni a CRLF karaktereket a HTTP kérésbe, képes megváltoztatni a kimeneti adatfolyamot és hamisítani a naplóbejegyzéseket. Meg tudja változtatni a választ a webs alkalmazásról az alábbiakra:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

a %0d és %0a a CR és LF url kódolt formái. Ezért a naplóbejegyzések így néznének ki, miután a támadó beillesztette ezeket a karaktereket, majd az alkalmazás megjeleníti azt:

IP – idő által meglátogatott útvonal

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

ezért a CRLF injekció sebezhetőségének kihasználásával a támadó hamis bejegyzéseket készíthet a naplófájlban, hogy elfojtsa saját rosszindulatú műveleteit. A támadó szó szerint oldal eltérítést végez, és módosítja a választ. Képzeljünk el például egy olyan esetet, amikor a támadó rendelkezik rendszergazdai jelszóval, és végrehajtja a restrictedaction paramétert, amelyet csak egy rendszergazda használhat.

a probléma az, hogy ha a rendszergazda észreveszi, hogy egy ismeretlen IP használta a restrictedaction paramétert, észreveszi, hogy valami nincs rendben. Mivel azonban most úgy tűnik, hogy a parancsot a localhost adta ki (ezért valószínűleg valaki, aki hozzáfér a szerverhez, mint egy admin), nem tűnik gyanúsnak.

a %0d%0a-val kezdődő lekérdezés teljes részét a kiszolgáló egy paraméterként kezeli. Ezután van egy másik & a restrictedaction paraméterrel, amelyet a kiszolgáló egy másik paraméterként értelmez. Hatékonyan ez ugyanaz lenne a lekérdezés, mint:

/index.php?page=home&restrictedaction=edit

HTTP Válaszmegosztás

leírás

mivel a HTTP válasz fejlécét és testét CRLF karakterek választják el egymástól, a támadó megpróbálhatja ezeket beadni. A CRLFCRLF kombinációja megmondja a böngészőnek, hogy a fejléc véget ér, a test pedig megkezdődik. Ez azt jelenti, hogy most képes adatokat írni a választestbe, ahol a html kódot tárolja. Ez ahhoz vezethet, hogy egy cross-site Scripting biztonsági rés.

egy példa a HTTP válasz felosztása vezető XSS

Képzeljünk el egy alkalmazást, amely beállítja az egyéni fejléc, például:

X-Your-Name: Bob

a fejléc értéke a”név” nevű get paraméter segítségével állítható be. Ha nincs URL-kódolás a helyén, és az érték közvetlenül tükröződik a fejlécben, lehetséges, hogy a támadó beilleszti a CRLFCRLF fent említett kombinációját, hogy elmondja a böngészőnek, hogy a kérési testület megkezdődik. Így képes olyan adatokat beilleszteni, mint például az XSS hasznos teher, például:

?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>

a fentiek figyelmeztető ablakot jelenítenek meg a megtámadott domain összefüggésében.

HTTP Header Injection

leírás

CRLF injection kihasználásával a támadó HTTP fejléceket is beilleszthet, amelyek felhasználhatók olyan biztonsági mechanizmusok legyőzésére, mint például a böngésző XSS szűrője vagy az azonos eredetű politika. Ez lehetővé teszi a támadó számára, hogy érzékeny információkat szerezzen, például CSRF tokeneket. Olyan cookie-kat is beállíthat, amelyek kihasználhatók azáltal, hogy bejelentkezik az áldozatra a támadó Fiókjában, vagy kihasználja az egyébként kihasználatlan webhelyközi szkriptek (XSS) sebezhetőségeit.

Egy példa a HTTP Fejléc Injekció kivonat érzékeny adatok

Ha a támadó képes beadni a HTTP fejlécek, hogy aktiválja RB (Kereszt Origin Erőforrás-Megosztás), hogy tudja használni a javascript erőforrások elérését, amelyek egyébként által védett SOP (Azonos Eredetű Politika), amely megakadályozza, hogy a webhelyek a különböző eredetű eléréséhez egymást.

A CRLF injection sebezhetőségének hatásai

a CRLF injekciók hatása változó, és magában foglalja az információk nyilvánosságra hozatalára vonatkozó, a webhelyeken keresztüli szkriptek összes hatását is. Deaktiválhat bizonyos biztonsági korlátozásokat is, például az XSS szűrőket és az áldozat böngészőiben ugyanazt a származási politikát, így azok érzékenyek a rosszindulatú támadásokra.

hogyan lehet megakadályozni a CRLF / HTTP fejléc injekciókat a webes alkalmazásokban

a legjobb megelőzési módszer az, ha nem használjuk a felhasználók bemenetét közvetlenül a válaszfejlécekben. Ha ez nem lehetséges, mindig használjon egy funkciót a CRLF speciális karakterek kódolásához. Egy másik jó webes alkalmazás biztonsági legjobb gyakorlat az, hogy frissítse a programozási nyelv egy olyan verzió, amely nem teszi lehetővé a CR és LF kell beadni belső funkciók, amelyek meghatározzák a HTTP fejlécek.

sebezhetőségi osztályozási és súlyossági táblázat