Kas yra sesijos užgrobimas ir kaip galite tai sustabdyti

Ši istorija skirta pradedantiesiems ir visiems, kurie turi pagrindinį supratimą apie slapukus (seanso slapukus), bet kas nėra tikras, kaip juos tinkamai apsaugoti. Tam nereikia būti saugumo ekspertu. Jūs tiesiog turite suprasti procesą ir tada sužinosite.

Jei neturite jokios idėjos apie slapukus ar jų veikimą, perskaitykite šį straipsnį apie HTTP slapukus.

Priimkime tai! Jūs turite nuostabią žiniatinklio programą, siūlančią puikią paslaugą klientams. Tai reiškia, kad turėsite autentifikavimo mechanizmą, kad vartotojas patektų į jūsų programą. Jūs žinote, koks svarbus yra saugumas. Atpažindami įdiegėte įvairiausias saugos priemones. Puiku!

Sėkmingai tapatindami, turite sukurti tam vartotojui skirtą sesiją . Tai reiškia, kad jūs iš tikrųjų kuriate slapuką ir siunčiate jį atgal į naršyklę. Pavyzdžiui, „Java“ žiniatinklio programoje pagal numatytuosius nustatymus ji vadinama JSESSIONID. Tai atrodo maždaug taip:

Naudodamas šį slapuką, tik jūsų interneto serveris gali nustatyti, kas yra vartotojas, ir jis atitinkamai pateiks turinį. Ir šis slapukas atrodo puikiai. Slapuke nėra jokios neskelbtinos informacijos, tik atsitiktinis ID (neatspėjamas). Taigi vartotojas yra saugus! ... tiesa?

Na ne tiksliai, pažvelkime atidžiau.

Šiame slapuke yra dvi ypatybės: „ HttpOnly“ (HTTP) ir „ Secure“. Jų reikšmės yra tuščios, tai reiškia, kad šis slapukas neįgalintas . Štai kur pasiekiama, kad tai nebėra saugu.

Čia atsiranda žaidimas „Session Hijacking“.

Sesijos užgrobimas , kartais dar vadinamas slapukų pagrobimu, yra galiojančio kompiuterio seanso - kartais dar vadinamo seanso raktu - išnaudojimas, norint gauti neteisėtą prieigą prie informacijos ar paslaugų kompiuterinėje sistemoje. - Vikipedija

Taigi, pavagiama kliento sesijos ID, kuriuo jis gali pasiekti jūsų žiniatinklio programą taip, lyg būtų tas klientas.

ar tai įmanoma? Kaip jie gauna tą seanso ID, kuris yra vartotojo naršyklėje?

Taip, tai įmanoma. Dvi slapukų savybės (arba žymos), kurias matėme anksčiau („ HttpOnly“ ir „ Secure“ ), yra to priežastis.

Tik vėliava

HttpOnlyslapukai nėra prieinami „JavaScript“ Document.cookieAPI; jie siunčiami tik į serverį. Pvz., Slapukai, kurie išlieka serverio pusės sesijose, neturi būti prieinami „JavaScript“ ir HttpOnlyturėtų būti nustatyta žyma.

Taigi paprastai tariant, jei nenustatėte žymos „Tik“, tada jūsų slapuką galima perskaityti iš priekinio „JavaScript“ kodo.

Atidarykite bet kurį tinklalapį, kurio slapuke nenustatyta žyma „Tik“. Tada atidarykite „ Chrome Dev Console“ ir palieskite „ Console“ skirtuką („Cmd“ + „Shift“ + J arba „Ctrl“ + „Shift“ + J). Įveskite document.cookieir įveskite, ir pamatysite maždaug taip:

Kaip matote, jūs gaunate visą informaciją apie slapukus. „JavaScript“ užpuolikas gali tiesiog paskelbti tai savo serveryje, kad vėliau būtų galima naudoti.

Jums gali kilti klausimas, kaip jie gali parašyti šį kodą jūsų programoje. Tai įmanoma keliais būdais.

Vienas iš būdų yra įšvirkšti nepatikimą trečiųjų šalių JS biblioteką, pvz., Kirtimą, pagalbines paslaugas ir pan. Perskaitykite šį straipsnį. Aš renku kreditinių kortelių numerius ir slaptažodžius iš savo svetainės. Štai kaip .

Kitas būdas yra naudoti „ Cross Site Scripting Attack“ . Mes nesiruošiame gilintis į jo detales, tačiau atminkite, kad tai galima padaryti.

Taigi, kaip mes tai ištaisysime?

Sesijos slapuko nereikia net pasiekti „JavaScript“ klientui. Tai reikalinga tik serveriui. Turėtume padaryti jį prieinamą tik serveriui. Tai galima padaryti pridedant vieną žodį ( tiktai ) jūsų set_cookie http atsakymo antraštėje. Kaip šitas:

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

Pridėdami vėliavą „ Tik“, nurodote naršyklei, kad šis slapukas neturėtų būti skaitomas naudojant „JavaScript“ kodą. Naršyklė pasirūpins viskuo. Štai kaip atrodo pridėjus „httpOnly“ vėliavą:

Atkreipkite dėmesį į HTTP ypatybės varnelę. Tai rodo, kad įjungta httpOnly .

Čia galite pamatyti tą dokumentą. Slapukas negrąžina mūsų sesijos slapuko. Tai reiškia, kad JS negali jo perskaityti, įskaitant išorinius scenarijus.

Štai ir viskas - vienas žemyn!

Saugi vėliava

Saugus vėliava nurodo naršyklei, kad slapukas turėtų būti grąžintas tik paraiškos per saugiame ryšį, tai yra, HTTPS ryšį.

Taigi, kai slapukas siunčiamas į naršyklę su saugia vėliava ir kai jūs pateikiate užklausą programai naudodami HTTP, naršyklė neprijungs šio slapuko į užklausą. Jis pridės jį tik prie HTTPS užklausos. HTTPS užklausa bus užšifruota, todėl slapukai bus saugiai siunčiami per jūsų tinklą į jūsų programą.

Kaip kažkas gali perskaityti HTTP užklausos slapuką?

Tai galima pasiekti, kai kas nors (vadinamas puolimu „Žmogus viduryje“ ) stebi visą srautą klientų tinkle. Jie gali matyti aiškius teksto duomenis, jei užklausa yra HTTP.

Kai jie bus siunčiami per HTTPS , visi duomenys bus užšifruoti iš naršyklės ir išsiųsti į tinklą. Užpuolikas negalės gauti jūsų siunčiamų pirminių duomenų. Užpuolikas taip pat negalės iššifruoti turinio. Štai kodėl saugu siųsti duomenis per SSL.

Taigi, kaip mes tai ištaisysime?

Kaip ir vėliavą „Tik“ , „ set_cookie“ HTTP atsakymo antraštėje tiesiog reikia pridėti saugią vėliavą . Kaip šitas:

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

„Java“ tai galima padaryti keliais būdais. Jei naudojate „Servlet 3.0“ arba naujesnę versiją, šiuos nustatymus galite konfigūruoti „ web.xml“ :

  true true  

Jei jūsų aplinka to nepalaiko, galite pridėti rankiniu būdu. Pavyzdžiui, naudodami „Servlet“ galite tai padaryti:

Galiausiai, taip atrodo, kai nustatomos abi vėliavos,

Išvada

Taigi, kai turite reikalų su sesijos slapukais ar kitais svarbiais slapukais, būtinai pridėkite šias dvi žymes.

Dėkojame, kad perskaitėte, laimingo saugumo!