Kas ir sesijas nolaupīšana un kā jūs to varat apturēt

Šis stāsts ir paredzēts iesācējiem un visiem, kam ir pamatzināšanas par sīkdatnēm (sesijas sīkdatnēm), bet kurš nav pārliecināts, kā tos pareizi nodrošināt. Lai to izdarītu, jums nav jābūt drošības ekspertam. Jums vienkārši ir jāsaprot process, un tad jūs to zināt.

Ja jums nav ne jausmas par sīkdatnēm vai to darbību, lūdzu, izlasiet šo rakstu par HTTP sīkfailiem.

Tiksim pie tā! Jums ir pārsteidzoša tīmekļa lietojumprogramma, kas klientiem piedāvā lielisku servisu. Tas nozīmē, ka jums būs autentifikācijas mehānisms, lai lietotāju novirzītu uz jūsu lietojumprogrammu. Jūs zināt, cik svarīga ir drošība. Autentifikācijas laikā esat ieviesis visdažādākos drošības pasākumus. Lieliski!

Pēc veiksmīgas autentifikācijas jums jāizveido sesija šim lietotājam. Tas nozīmē, ka jūs faktiski izveidojat sīkfailu un nosūtiet to atpakaļ pārlūkprogrammai. Piemēram, Java tīmekļa lietotnē pēc noklusējuma to sauc par JSESSIONID. Tas izskatās apmēram šādi:

Izmantojot šo sīkfailu, tikai jūsu tīmekļa serveris var noteikt, kas ir lietotājs, un tas atbilstoši nodrošinās saturu. Un šis cepums izskatās lieliski. Sīkdatnē nav konfidenciālas informācijas, tikai izlases ID (nav uzminams). Tātad lietotājs ir drošībā! …pa labi?

Nu ne gluži, apskatīsim tuvāk.

Šajā sīkfailā ir divas īpašības: HttpOnly (HTTP) un Secure. Viņu vērtības ir tukšas, tas nozīmē, ka šis sīkfails nav iespējots . Tur tas nonāk līdz vietai, ka tas vairs nav drošs.

Šeit tiek parādīta sesijas nolaupīšana.

Sesijas nolaupīšana , dažreiz dēvēta arī par sīkfailu nolaupīšanu, ir derīgas datora sesijas - dažkārt sauktas arī par sesijas atslēgu - izmantošana, lai nesankcionēti piekļūtu informācijai vai pakalpojumiem datorsistēmā. - Vikipēdija

Tātad tas ir klienta sesijas ID zagšana, ar kuru viņi var piekļūt jūsu tīmekļa lietojumprogrammai it kā viņš būtu šis klients.

Vai tas ir iespējams? Kā viņi iegūst šo sesijas ID, kas atrodas lietotāja pārlūkprogrammā?

Jā, tas ir iespējams. Divas sīkdatņu īpašības (vai karodziņi), kuras mēs redzējām iepriekš ( HttpOnly un Secure ), ir iemesls tam.

HttpTikai karogs

HttpOnlysīkdatnes nav pieejamas JavaScript Document.cookieAPI; tie tiek sūtīti tikai uz serveri. Piemēram, sīkfailiem, kas pastāv servera puses sesijās, nav jābūt pieejamiem JavaScript, un HttpOnlyir jāiestata karodziņš.

Tātad, vienkāršā izteiksmē, ja neesat iestatījis karodziņu httpOnly, jūsu sīkfails ir lasāms no priekšējā JavaScript koda.

Atveriet jebkuru tīmekļa lapu, kuras sīkfailā nav iestatīts karogs httpTikai. Pēc tam atveriet Chrome Dev Console un pēc tam pieskarieties cilnei Console (Cmd + Shift + J vai Ctrl + Shift + J). Ierakstiet document.cookieun ievadiet, un jūs redzēsiet kaut ko līdzīgu šim:

Kā redzat, jūs saņemat visu sīkfailu informāciju. JavaScript uzbrucējs to var vienkārši ievietot savā serverī vēlākai izmantošanai.

Jums varētu rasties jautājums, kā viņi var ierakstīt šo kodu jūsu lietojumprogrammā. Tas ir iespējams vairākos veidos.

Viens veids ir injicēt kādu neuzticamu trešās puses JS bibliotēku, piemēram, mežizstrādi, palīgu utilītprogrammas utt . Lūk, kā .

Vēl viens veids ir izmantot vairāku vietņu skriptu uzbrukumu . Mēs neiedziļināsimies tā detaļās, bet atcerieties, ka to var izdarīt.

Tātad, kā mēs to labojam?

Sesijas sīkfailam pat nav jābūt pieejamam JavaScript klientam. Tas ir nepieciešams tikai serverim. Mums tas jādara pieejams tikai serverim. To var izdarīt, pievienojot vienu vārdu ( tikaiTikai ) jūsu set_cookie http atbildes galvenē. Kā šis:

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

Pievienojot karodziņu httpTikai , jūs pārlūkprogrammai dodat norādījumu, ka šo sīkfailu nedrīkst lasīt ar JavaScript kodu. Pārējā daļa rūpēsies pārlūks. Šādi izskatās pēc karodziņa httpOnly pievienošanas:

Ievērojiet atzīmi HTTP rekvizītā. Tas norāda, ka ir iespējota httpOnly .

Šeit jūs varat redzēt, ka document.cookie neatgriež mūsu sesijas sīkfailu. Tas nozīmē, ka neviens JS to nevar izlasīt, ieskaitot jebkādus ārējos skriptus.

Tas tā - viens uz leju, lai iet!

Drošs karogs

Droša karogs norāda pārlūkprogrammai, ka cookie būtu atpakaļ tikai uz pieteikumu pa šifrēto savienojumu, tas ir, HTTPS savienojumu.

Tātad, kad pārlūkprogrammai tiek nosūtīts sīkfails ar karodziņu drošs un kad jūs iesniedzat pieprasījumu lietojumprogrammai, izmantojot HTTP, pārlūks nepievienos šo sīkfailu pieprasījumā. Tas to pievienos tikai HTTPS pieprasījumā. HTTPS pieprasījums tiks šifrēts, tāpēc sīkfaili visā tīklā tiks droši nosūtīti uz jūsu lietojumprogrammu.

Kā kāds var izlasīt sīkfailu HTTP pieprasījumā?

To var panākt, ja kāds (saukts par “Man in the Middle” uzbrukumu) uzrauga visu klientu tīkla trafiku. Viņi var redzēt skaidrus teksta datus, ja pieprasījums ir HTTP.

Kad tie tiek nosūtīti, izmantojot HTTPS , visi dati tiks šifrēti no pārlūkprogrammas un nosūtīti uz tīklu. Uzbrucējs nevarēs iegūt sākotnējos datus, kurus sūtījāt. Uzbrucējs arī nevarēs atšifrēt saturu. Tāpēc datu sūtīšana, izmantojot SSL, ir droša.

Tātad, kā mēs to labojam?

Tāpat kā karogs httpOnly, jums arī jāpievieno drošais karodziņš set_cookie HTTP atbildes galvenē. Kā šis:

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

Java valodā to var izdarīt vairākos veidos. Ja izmantojat Servlet 3.0 vai jaunāku versiju, vietnē Web.xml šos iestatījumus varat konfigurēt šādi :

  true true  

Ja jūsu vide to neatbalsta, varat to pievienot manuāli. Piemēram, izmantojot Servlet, varat to izdarīt:

Visbeidzot, tas izskatās, kad abi karogi ir uzstādīti,

Secinājums

Tāpēc, kad jums ir darīšana ar sesijas sīkfailiem vai citiem svarīgiem sīkfailiem, noteikti pievienojiet šos divus karodziņus.

Paldies, ka izlasījāt, Laimīgu nodrošināšanu!