Hvad er kapring af sessioner, og hvordan du kan stoppe det

Denne historie er for begyndere og alle, der har en grundlæggende forståelse for cookies (session cookies), men som ikke er sikre på, hvordan de skal sikres korrekt. Du behøver ikke at være en sikkerhedsekspert for at gøre det. Du skal bare forstå processen, og så ved du det.

Hvis du ikke har nogen idé om cookies, eller hvordan de fungerer, skal du læse denne artikel om HTTP-cookies.

Lad os komme til det! Du har en fantastisk webapplikation, der tilbyder en god service til kunder. Det betyder, at du vil have en godkendelsesmekanisme til at få brugeren til din applikation. Du ved, hvor vigtig sikkerhed er. Du implementerede alle mulige sikkerhedsforanstaltninger under godkendelse. Store!

Efter vellykket godkendelse skal du oprette en session for den bruger. Dette betyder, at du faktisk opretter en cookie og sender den tilbage til browseren. For eksempel i en Java-webapp kaldes den som standard JSESSIONID. Det ser sådan ud:

Ved at bruge denne cookie er det kun din webserver, der er i stand til at identificere, hvem brugeren er, og den vil levere indhold i overensstemmelse hermed. Og denne cookie ser godt ud. Ingen følsomme oplysninger i cookien, kun tilfældigt ID (ikke gætte). Så brugeren er sikker! …ret?

Nå ikke nøjagtigt, lad os se nærmere på.

Der er to egenskaber i denne cookie: HttpOnly (HTTP) og Secure. Deres værdier er tomme, hvilket betyder, at denne cookie ikke er aktiveret . Det er her, det kommer til det punkt, at det ikke længere er sikkert.

Det er her, Session Hijacking spiller ind.

Session hijacking , undertiden også kaldet cookie kapring er udnyttelsen af et gyldigt computer session - nogle gange også kaldet en session nøgle - at få uautoriseret adgang til oplysninger eller tjenester i et computersystem. - Wikipedia

Så det er handlingen med at stjæle en kundes session-id, hvorved de kan få adgang til din webapplikation, som om de er den kunde.

Er dette muligt? Hvordan får de det session-id, som findes i brugerens browser?

Ja det er muligt. De to cookieegenskaber (eller flag), som vi så tidligere ( HttpOnly og Secure ), er årsagen til dette.

HttpKun flag

HttpOnlycookies er utilgængelige for JavaScript's Document.cookieAPI; de sendes kun til serveren. F.eks. Behøver cookies, der fortsætter sessioner på serversiden, ikke at være tilgængelige for JavaScript, og HttpOnlyflag skal indstilles.

Så i enkle vendinger, hvis du ikke indstiller httpOnly-flagget, kan din cookie læses fra JavaScript-koden på frontenden.

Åbn enhver webside, hvis cookie ikke har indstillet httpOnly-flag. Åbn derefter Chrome Dev Console, og tryk derefter på Console Tab (Cmd + Shift + J eller Ctrl + Shift + J). Skriv document.cookieog Enter, og du vil se noget som dette:

Som du kan se, får du al information om cookies. En JavaScript-angriber kan simpelthen sende dette til deres egen server til senere brug.

Du spekulerer måske på, hvordan de kan skrive denne kode i din applikation. Det er muligt på flere måder.

En måde er at indsprøjte noget ikke-betroet JS-bibliotek fra tredjepart som logning, hjælpeværktøjer osv. Læs denne artikel Jeg høster kreditkortnumre og adgangskoder fra dit websted. Sådan gør du .

En anden måde er at bruge et Cross Site Scripting Attack . Vi kommer ikke ind på detaljerne i det, men husk, det kan gøres.

Så hvordan løser vi det?

Sessionscookien behøver ikke engang at være tilgængelig for JavaScript-klienten. Det er kun nødvendigt for serveren. Vi skal gøre det kun tilgængeligt for serveren. Det kan gøres ved at tilføje et ord ( httpOnly ) i din head_sæt_cookie http-svar. Sådan her:

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

Ved at tilføje httpOnly- flag instruerer du browseren om, at denne cookie ikke skal læses af JavaScript-koden. Browseren tager sig af resten. Sådan ser det ud efter tilføjelse af httpOnly-flagget:

Bemærk kryds i HTTP-egenskaben. Det indikerer, at httpOnly er aktiveret.

Her kan du se, at document.cookie returnerer ikke vores session cookie. Det betyder, at ingen JS kan læse det, inklusive eventuelle eksterne scripts.

Det er det - en ned en til at gå!

Sikker flag

Det sikre flag instruerer browseren om, at cookien kun skal returneres til applikationen via krypterede forbindelser, det vil sige en HTTPS-forbindelse.

Så når en cookie sendes til browseren med det sikre flag , og når du fremsætter en anmodning til applikationen ved hjælp af HTTP, vedhæfter browseren ikke denne cookie i anmodningen. Det vedhæftes kun i en HTTPS-anmodning. HTTPS-anmodningen bliver krypteret, så cookies sikkert sendes over hele netværket til din applikation.

Hvordan kan nogen læse cookien i HTTP-anmodningen?

Dette kan opnås, når nogen (kaldet et "mand i midten" angreb) overvåger al trafik i netværket af kunder. De er i stand til at se klare tekstdata, hvis anmodningen er i HTTP.

Når det sendes via HTTPS , krypteres alle data fra browseren og sendes til netværket. Angriberen kan ikke få de rådata, du sendte. Angriberen vil heller ikke være i stand til at dekryptere indholdet. Derfor er det sikkert at sende data via SSL.

Så hvordan løser vi det?

Ligesom httpOnly-flagget skal du bare tilføje det sikre flag i din set_cookie HTTP- svaroverskrift . Sådan her:

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

I Java kan det gøres på flere måder. Hvis du bruger Servlet 3.0 eller nyere, kan du konfigurere disse indstillinger i web.xml sådan:

  true true  

Hvis dit miljø ikke understøtter det, kan du tilføje det manuelt. For eksempel ved hjælp af Servlets kan du gøre dette:

Endelig er det sådan, det ser ud, når begge flag er sat,

Konklusion

Så når du har at gøre med sessionscookies eller andre vigtige cookies, skal du sørge for at tilføje disse to flag.

Tak for læsningen, Happy Securing!