Mi a munkamenet-eltérítés és hogyan lehet megállítani

Ez a történet kezdőknek és mindenkinek szól, aki alapvető ismeretekkel rendelkezik a sütikről (session cookie-k), de aki nem biztos abban, hogyan tudja őket biztonságosan rögzíteni. Ehhez nem kell biztonsági szakértőnek lenned. Csak meg kell értenie a folyamatot, és akkor tudni fogja.

Ha nincs ötlete a sütikről vagy azok működéséről, olvassa el ezt a cikket a HTTP-sütikről.

Térjünk rá! Van egy csodálatos webalkalmazása, amely nagyszerű szolgáltatást kínál az ügyfelek számára. Ez azt jelenti, hogy hitelesítési mechanizmussal rendelkezik, hogy a felhasználót eljuttassa az alkalmazásához. Tudja, mennyire fontos a biztonság. Mindenféle biztonsági intézkedést végrehajtott a hitelesítés során. Nagy!

A sikeres hitelesítés után létre kell hoznia egy munkamenetet az adott felhasználó számára. Ez azt jelenti, hogy valóban létrehoz egy cookie-t, és visszaküldi a böngészőnek. Például egy Java webalkalmazásban alapértelmezés szerint JSESSIONID. Valahogy így néz ki:

Ennek a sütinek a használatával csak az Ön webszervere képes azonosítani a felhasználót, és ennek megfelelően nyújt tartalmat. És ez a süti nagyon jól néz ki. Nincs érzékeny információ a cookie-ban, csak a véletlenszerű azonosító (nem kitalálható). Tehát a felhasználó biztonságban van! …jobb?

Nos nem pontosan, nézzük meg közelebbről.

Két tulajdonság van ebben a cookie-ban: HttpOnly (HTTP) és Secure. Értékeik üresek, vagyis nem engedélyezettek ebben a cookie-ban . Ott jut el odáig, hogy már nem biztonságos.

Itt játszik szerepet a Session Hijacking.

Munkamenet eltérítése , néha más néven a cookie -eltérítés a kizsákmányolás egy érvényes számítógépes munkamenet - más néven a munkamenet gomb - a jogosulatlan hozzáférést az információkhoz, illetve szolgáltatások egy számítógépes rendszerben. - Wikipédia

Tehát ellopják az ügyfél munkamenet-azonosítóját, amellyel elérhetik a webalkalmazást, mintha ő lenne az ügyfél.

Lehetséges ez? Hogyan szerzik meg azt a munkamenet-azonosítót, amely a felhasználó böngészőjében található?

Igen, lehetséges. A két cookie tulajdonság (vagy zászló), amelyet korábban láttunk ( HttpOnly és Secure ), ennek oka.

Csak a zászló

HttpOnlya sütik nem érhetők el a JavaScript Document.cookieAPI - jához; csak a szerverre küldik. Például a kiszolgálóoldali munkameneteket megőrző sütiknek nem kell rendelkezésre állniuk a JavaScript számára, és HttpOnlybe kell állítani a jelzőt.

Tehát egyszerűsítve: ha nem állítja be a httpOnly jelölőt, akkor a cookie olvasható az elülső JavaScript kódból.

Nyisson meg minden olyan weboldalt, amelynek cookie-jában nincs beállítva a httpOnly jelző. Ezután nyissa meg a Chrome Dev Console elemet, majd koppintson a Console fülre (Cmd + Shift + J vagy Ctrl + Shift + J). Írja document.cookiebe és írja be, és valami ilyesmit fog látni:

Mint láthatja, minden cookie-információt megkap. A JavaScript-támadók ezt egyszerűen közzétehetik saját szerverükön későbbi felhasználás céljából.

Kíváncsi lehet, hogyan írhatják ezt a kódot az Ön alkalmazásába. Többféle módon lehetséges.

Az egyik mód az, hogy beinjektál néhány nem megbízható, harmadik féltől származó JS-könyvtárat, például naplózást, segítő segédprogramokat stb. Olvassa el ezt a cikket. Hitelkártyaszámokat és jelszavakat gyűjtök a webhelyéről. Itt van, hogyan .

Egy másik módszer a Cross Site Scripting Attack használata . Nem fogunk belemenni a részletekbe, de ne feledje, hogy meg lehet csinálni.

Tehát hogyan javítsuk ki?

A munkamenet cookie-nak nem is kell elérhetőnek lennie a JavaScript kliens számára. Csak a szerverhez szükséges. Csak a szerver számára kellene hozzáférhetővé tenni. Megtehető úgy, hogy egy szót ( csak ) hozzáad a set_cookie http válasz fejlécéhez. Mint ez:

Set-Cookie: JSESSIONID=T8zK7hcII6iNgA; Expires=Wed, 21 May 2018 07:28:00 GMT; HttpOnly

A httpOnly zászló hozzáadásával utasítja a böngészőt, hogy ezt a cookie-t ne olvassa el a JavaScript kód. A többiről a böngésző gondoskodik. Így néz ki a httpOnly zászló hozzáadása után:

Figyelje meg a pipa jelet a HTTP tulajdonságban. Ez azt jelzi, hogy a httpOnly engedélyezve van.

Itt láthatja, hogy a document.cookie nem adja vissza a munkamenet sütit. Vagyis egyetlen JS sem tudja elolvasni, beleértve a külső szkripteket is.

Ennyi - eggyel lejjebb menni!

Biztonságos zászló

A biztonságos jelző utasítja a böngészőt, hogy a cookie-t csak titkosított kapcsolatokon, azaz HTTPS-kapcsolaton keresztül szabad az alkalmazáshoz visszaküldeni.

Tehát, ha egy cookie-t biztonságos böngészővel küldenek a böngészőbe , és amikor HTTP használatával kérelmet nyújt be az alkalmazáshoz, a böngésző nem csatolja ezt a cookie-t a kérelemhez. Csak egy HTTPS kérelemben fogja csatolni. A HTTPS kérés titkosításra kerül, így a cookie-kat biztonságosan elküldik a hálózaton keresztül az alkalmazásához.

Hogyan olvassa el valaki a cookie-t a HTTP-kérésben?

Ez akkor érhető el, amikor valaki (az úgynevezett „Középső ember” támadás) figyelemmel kíséri az összes forgalmat az ügyfelek hálózatában. Láthatják a tiszta szöveges adatokat, ha a kérés HTTP-ben van.

Amikor HTTPS-en keresztül küldi , minden adatot titkosít a böngészőből és elküldi a hálózatra. A támadó nem tudja megszerezni az Ön által küldött nyers adatokat. A támadó sem lesz képes visszafejteni a tartalmat. Ezért biztonságos az adatküldés SSL-en keresztül.

Tehát hogyan javítsuk ki?

Csakúgy, mint a httpOnly jelzőt, csak hozzá kell adnia a biztonságos jelzőt a set_cookie HTTP válasz fejlécébe. Mint ez:

Set-Cookie: JSESSIONID=T8zK7hcII6iNgA; Expires=Wed, 21 May 2018 07:28:00 GMT; HttpOnly; Secure

A Java-ban többféleképpen is megtehető. Ha a Servlet 3.0 vagy újabb verziót használja, akkor a web.xml fájlban a következőképpen konfigurálhatja ezeket a beállításokat :

  true true  

Ha a környezete nem támogatja, akkor manuálisan is hozzáadhatja. Például a Servlet segítségével ezt megteheti:

Végül így néz ki, amikor mindkét zászló be van állítva,

Következtetés

Tehát amikor munkamenet-sütikkel vagy más fontos sütikkel foglalkozik, győződjön meg arról, hogy hozzáadta ezt a két jelölőt.

Köszönjük, hogy elolvastad, boldog biztonságot!