session hijacking,, wat houdt dit in?
Pagina: « vorige 1 2 3 4 volgende »
Wat bodoel je precies met het id van je browser? Welk id heb je het dan over, je sessie-id? Voor zover ik weet geven browsers zelf geen uniek id hoor, waar jij met PHP gebruik van kunt maken
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php
// Geheime sleutel
define('SECRET_KEY', 'JHNIRxywSjFTKv5bsGjPchzxekuvdZuj2XvduLf');
/**
* [a] Asymmetrische 512-bit hash met
* [b] fingerprinting van de user agent die
* [c] alleen vandaag geldig is voor
* [d] applicaties die de geheime sleutel kennen en
* [e] de strings b, c en d in de juiste volgorde toepassen.
*/
// |--a---| |------------b------------| |----c----| |---d----|
$hashkey = hash('sha512', $_SERVER['HTTP_USER_AGENT'] . date('Ymd') . SECRET_KEY);
// |---------------------------e------------------------|
?>
// Geheime sleutel
define('SECRET_KEY', 'JHNIRxywSjFTKv5bsGjPchzxekuvdZuj2XvduLf');
/**
* [a] Asymmetrische 512-bit hash met
* [b] fingerprinting van de user agent die
* [c] alleen vandaag geldig is voor
* [d] applicaties die de geheime sleutel kennen en
* [e] de strings b, c en d in de juiste volgorde toepassen.
*/
// |--a---| |------------b------------| |----c----| |---d----|
$hashkey = hash('sha512', $_SERVER['HTTP_USER_AGENT'] . date('Ymd') . SECRET_KEY);
// |---------------------------e------------------------|
?>
De hash generen is geen probleem, de controle met de client is het euvel hier om hijacking tegen te gaan. Controle op IP werkt niet meer anno 2012.
Nee, ik dacht dat misschien de browser bepaalde unieke waardes meestuurt naar de client.
Maar helaas
Mik tH op 08/10/2012 12:47:16:
@Chris,
Nee, ik dacht dat misschien de browser bepaalde unieke waardes meestuurt naar de client.
Maar helaas
Nee, ik dacht dat misschien de browser bepaalde unieke waardes meestuurt naar de client.
Maar helaas
Nee helaas niet, dat zou het probleem gelijk oplossen :D vandaar dat er nu de functionele cookie voorgesteld wordt. Ik had het als idee, echter SanThe heeft het zelfs ooit al gemaakt en getest. Het was goed te doen, en werkte ook op mobiele apparaten.
Chris NVT op 08/10/2012 11:10:48:
Maar om even verder te gaan over het sessie hjack verhaal :D
Je kunt natuurlijk ook gewoon een 'functionele' cookie maken, waar je een random id in zet die aangemaakt wordt tijdens het inloggen. Dan kun je kijken of de sessie-id en dat random id (los van je sessie cookie) matchen.
Dit soort cookies mag je plaatsen, en kun je zien of het nog om het zelfde 'apparaat' gaat. Dan sla je beide op in je database tijdens het inloggen, en bij het uitloggen delete je de entry.
Je kunt natuurlijk ook gewoon een 'functionele' cookie maken, waar je een random id in zet die aangemaakt wordt tijdens het inloggen. Dan kun je kijken of de sessie-id en dat random id (los van je sessie cookie) matchen.
Dit soort cookies mag je plaatsen, en kun je zien of het nog om het zelfde 'apparaat' gaat. Dan sla je beide op in je database tijdens het inloggen, en bij het uitloggen delete je de entry.
Ik snap niet 100% wat je hier mee bedoeld. Dit zijn even als voorbeeld de waardes:
Je session id = 1234
random id cookie = abc123CBA
Wat bedoel je nu precies met het verhaal hierboven.
Mik tH op 08/10/2012 12:54:28:
Ik snap niet 100% wat je hier mee bedoeld. Dit zijn even als voorbeeld de waardes:
Je session id = 1234
random id cookie = abc123CBA
Wat bedoel je nu precies met het verhaal hierboven.
Chris NVT op 08/10/2012 11:10:48:
Maar om even verder te gaan over het sessie hjack verhaal :D
Je kunt natuurlijk ook gewoon een 'functionele' cookie maken, waar je een random id in zet die aangemaakt wordt tijdens het inloggen. Dan kun je kijken of de sessie-id en dat random id (los van je sessie cookie) matchen.
Dit soort cookies mag je plaatsen, en kun je zien of het nog om het zelfde 'apparaat' gaat. Dan sla je beide op in je database tijdens het inloggen, en bij het uitloggen delete je de entry.
Je kunt natuurlijk ook gewoon een 'functionele' cookie maken, waar je een random id in zet die aangemaakt wordt tijdens het inloggen. Dan kun je kijken of de sessie-id en dat random id (los van je sessie cookie) matchen.
Dit soort cookies mag je plaatsen, en kun je zien of het nog om het zelfde 'apparaat' gaat. Dan sla je beide op in je database tijdens het inloggen, en bij het uitloggen delete je de entry.
Ik snap niet 100% wat je hier mee bedoeld. Dit zijn even als voorbeeld de waardes:
Je session id = 1234
random id cookie = abc123CBA
Wat bedoel je nu precies met het verhaal hierboven.
Als je een sessie aanmaakt krijg je een sessie-id, die sla je op in een database, tevens maak je tijdens het inloggen een cookie aan met een random id.
Dus bijvoorbeeld
Sessie id = 1234567890
Random id = OSIFDjk4POJD8903-2
Deze zet je beide in een database, samen met bijvoorbeeld het unieke id van de gebruiker.
Als je nu op een ‘beveiligde’ pagina komt, kijk je of de sessie-id en het random-id nog steeds gelijk zijn, dan tijdens het eerste inlog. Zoniet is de toegang geweigerd, is het wel zo dan gaat hij verder.
Bij het uiloggen, haal je die entry weer uit je database, aangezien je tijdens het inloggen weer een nieuw (ander) sessie-id en random-id krijgt, zolang er niet uitgelogd wordt.
ini_set('session.hash_function', 'sha512');
Wat ik veel meer bedoelde, was élke HTTP-respons voorzien van een uniek token dat bij het eerstvolgende HTTP-verzoek moet worden geretourneerd. Als het geretourneerde token niet gelijk is aan het laatste in de database opgeslagen token, kun je de complete sessie ongeldig verklaren.
Als je een voortdurend veranderend token opslaat in een database, kunnen twee clients niet meer één sessie delen. Het ongeldige (verouderde) token vernietigt namelijk de gehele sessie.
Schematisch:
1. Gebruiker A start sessie x en krijgt token y.
2. Indringer B kaapt sessie x met geldige sessie-id en krijgt token z.
3. Gebruiker A doet weer iets in sessie x maar retourneert het verlopen token y.
4. Fout afgevangen: y moest z zijn, dus de gehele sessie wordt vernietigd.
- Er komt een bezoeker op de site.
- Session starten.
- Kijken of er een cookie is.
- Zo nee:
- (A) Is een nieuwe bezoeker.
- - Maak een nieuwe session (met nieuw session_id) aan.
- - Set een cookie met sha1(ip-nummer).
- - Zet session_id en sha1(ip-nummer) in de database.
- Zo ja:
- - Kijken of session_id in de database staat.
- - Zo nee:
- - - Dan is het een nieuwe bezoeker en ga naar (A).
- - Zo ja:
- - - Cookie uitlezen.
- - - Kijken of cookieinhoud bij het session_id hoort in de database.
- - - Zo nee:
- - - - Hacker.
- - - - Stuur mail naar webmaster.
- - - - Ga naar (A) als nieuwe bezoeker.
- - - Zo ja:
- - - - Geef cookie nieuwe inhoud sha1(ip-nummer).
- - - - Update het record van het session_id en set sha1(ip-nummer).
Het enige wat ik zou veranderen, is dat de sessie evenals de cookie na elke logout gedelete wordt. Zodat er geen troep op de pc achterblijft, en de hacker niet de random id uit de cookie kan halen.
Bij mij zou ik er per login/logout een nieuwe sessie-id genereren evenals een nieuwe random controle string voor de random cookie. Dit is mijn zicht erop, als ik naar mijn eigen browsergedrag kijk clear ik na elke keer internetten mijn complete borwser history.
- SanThe - op 08/10/2012 13:56:52:
@Cris: Wat jij aangeeft zit er allemaal in. Maar dat leek mij een beetje erg veel info in mijn opsomming.
Aaah ok, helder :D
Hebben we nu niet weer hetzelfde probleem dat het op mobieltjes niet werkt? Omdat je weer het ip adres gebruikt voor de hash?
Mik tH op 08/10/2012 14:12:50:
@SanThe,
Hebben we nu niet weer hetzelfde probleem dat het op mobieltjes niet werkt? Omdat je weer het ip adres gebruikt voor de hash?
Hebben we nu niet weer hetzelfde probleem dat het op mobieltjes niet werkt? Omdat je weer het ip adres gebruikt voor de hash?
Ja dat is wat SanThe ook al aangaf een post terug, dat er ter controle beter een andere manier gepakt kan worden voor het genereren van een controle hash.
Ward van der Put op 08/10/2012 13:25:03:
Chris, als de random id tijdens de huidige sessie niet verandert, gebruik je in wezen een dubbele sessie-id. Twee id's zijn veiliger dan één, maar je kunt min of meer hetzelfde bereiken met één veel sterkere sessie-id, bijvoorbeeld:
ini_set('session.hash_function', 'sha512');
Wat ik veel meer bedoelde, was élke HTTP-respons voorzien van een uniek token dat bij het eerstvolgende HTTP-verzoek moet worden geretourneerd. Als het geretourneerde token niet gelijk is aan het laatste in de database opgeslagen token, kun je de complete sessie ongeldig verklaren.
Als je een voortdurend veranderend token opslaat in een database, kunnen twee clients niet meer één sessie delen. Het ongeldige (verouderde) token vernietigt namelijk de gehele sessie.
Schematisch:
1. Gebruiker A start sessie x en krijgt token y.
2. Indringer B kaapt sessie x met geldige sessie-id en krijgt token z.
3. Gebruiker A doet weer iets in sessie x maar retourneert het verlopen token y.
4. Fout afgevangen: y moest z zijn, dus de gehele sessie wordt vernietigd.
ini_set('session.hash_function', 'sha512');
Wat ik veel meer bedoelde, was élke HTTP-respons voorzien van een uniek token dat bij het eerstvolgende HTTP-verzoek moet worden geretourneerd. Als het geretourneerde token niet gelijk is aan het laatste in de database opgeslagen token, kun je de complete sessie ongeldig verklaren.
Als je een voortdurend veranderend token opslaat in een database, kunnen twee clients niet meer één sessie delen. Het ongeldige (verouderde) token vernietigt namelijk de gehele sessie.
Schematisch:
1. Gebruiker A start sessie x en krijgt token y.
2. Indringer B kaapt sessie x met geldige sessie-id en krijgt token z.
3. Gebruiker A doet weer iets in sessie x maar retourneert het verlopen token y.
4. Fout afgevangen: y moest z zijn, dus de gehele sessie wordt vernietigd.
Misschien zie ik het fout, maar betekend dit niet dat Gebruiker A uitgelogd word en gebruiker B (hacker) niet?
En dat de sessie pas vernietigt word als Gebruiker A weer een actie onderneemt, dus dat Gebruiker B (Hacker) tussen die periode alles kan doen wat hij wil?
Gewijzigd op 08/10/2012 14:39:02 door Mik PHP
Nee want de sessie wordt beeindigd, dus is de hacker ook gelijk 'uitgelogd' aangezien de sessie niet meer actief is :D
Dat kán juist voordelen hebben. De gebruiker kan uit foutmeldingen zelf afleiden dat er iets niet in de haak is. En je moet extra oplettend zijn bij gebruikers waarvan de sessie wordt gehackt, want dat kan bijvoorbeeld betekenen dat ze een onveilig netwerk gebruiken, dat hun verouderde browser lek is of dat hun accountgegevens op straat liggen.
Het geeft je verder ook de mogelijkheid om onmiddellijk een twee-factor beveiliging te activeren. Is je sessie gestolen? Dan moet je bijvoorbeeld met een bevestiging/code via e-mail of sms een nieuw wachtwoord opgeven. Daarvoor heb je een ingreep van de echte gebruiker nodig, niet de hacker.
Uiteindelijk is beveiliging ook een keuze. En in dit geval een vraag: wil je dat een gebruiker waarvan de sessie wordt gekaapt met dezelfde rechten kan verder werken? Meestal is het antwoord daarop: nee.
Het omgekeerde is bij mijn voorbeeld overigens ook mogelijk en dan krijg je een vorm van een cross-site request forgery (CSRF). De hacker start daarbij een geldige sessie, maar leidt de echte gebruiker aansluitend naar dezelfde sessie. Uit de start van de sessie kun je dus niet afleiden wie de slechterik of goedzak is; ook daarom moeten beide worden geweigerd.
Ward van der Put op 08/10/2012 15:02:28:
Uit de start van de sessie kun je dus niet afleiden wie de slechterik of goedzak is; ook daarom moeten beide worden geweigerd.
Goed punt.
Pagina: « vorige 1 2 3 4 volgende »