session id
Pagina: « vorige 1 2 3 volgende »
De sessie, op de server, bepaalt dus wat een geldige HTTP-respons is. Geen handtekening? Of een verouderde handtekening? Dan wég met dat formulier. En wég met die sessie.
Daarvoor zijn grofweg drie redenen:
• Iemand kan een webpagina met een formulier lokaal opslaan. Of er eentje opvissen uit de browsercache. Dat willen we niet: we willen een actueel formulier voor een actieve sessie.
• Browsers springen flexibeler om met sessiecookies dan met gewone cookies. Maak het sessiebeheer van PHP daarom liever niet afhankelijk van gewone cookies.
• Je applicatie kan zich in een bepaalde toestand bevinden. Bijvoorbeeld "ik ben bezig met het openen van een account" is een andere toestand dan "ik heb een account geopend en wil nu afrekenen". Dat is bijvoorbeeld belangrijk als gebruikers op de knop Vorige gaan zitten klikken.
Maar zeg je dan eigenlijk dat het opslaan van de code in een afzonderlijke cookie geen goed idee is?
Mijn idee was:
- code opslaan in sessie en cookie
- bij iedere pagina-aanroep controleren of de code uit de cookie overeenkomt met die uit de sessie
- zo nee, sessie vernietigen
1) ik log in... sessie wordt gestart.
2) nieuwe sessie id wordt gegenereerd
3) hacker "raadt" mijn nieuwe sessie id en neemt mijn sessie over... :(
Ozzie PHP op 04/10/2013 18:05:10:
Euh, en hoe weet je dan of iemand een ongeldig sessie-id aanroept? :-s Ik heb geen idee hoe je dat zou moeten controleren. Heb jij sowieso enig idee hoe iemand eigenlijk zo'n id te pakken kan krijgen? Want ze kunnen immers niet op je server.
Ozzie, begrijp je überhaupt hoe een sessie-ID bij PHP tot stand komt en hoe die vervolgens wordt uitgewisseld tussen client en server?
Dat is toch echt wel de minimale basis die je moet kunnen dromen voordat je aan verbeteringen gaan sleutelen :(
Ozzie PHP op 04/10/2013 18:05:10:
Euh, en hoe weet je dan of iemand een ongeldig sessie-id aanroept? :-s Ik heb geen idee hoe je dat zou moeten controleren. Heb jij sowieso enig idee hoe iemand eigenlijk zo'n id te pakken kan krijgen? Want ze kunnen immers niet op je server.
http://en.wikipedia.org/wiki/Session_hijacking
Open index.php?PHPSESSID=827463473047fhON bijvoorbeeld.
Ben je 'opeens' ingelogd, heb je dus een sessie gekaapt.
Je zou kunnen kijken of iemand $_GET['PHPSESSID'] opgeeft, per IP-adres bijvoorbeeld (niet per sessie, want dat overschrijf hij).
Als dat meer dan 3 is, blokkeer het IP-adres.
Je kan ook, wellicht gaat dat nadelige consequenties hebben, voor je session_start() gewoon $_GET['PHPSESSID'] unsetten.
Ben je er ook van af, dus werkt dat PHPSESSID niet meer.
Ozzie PHP op 04/10/2013 20:15:20:
Ik vraag me dus af of iemand een soort van bruteforce-aanval kan uitvoeren (net als met wachtwoorden), dus continue een andere id uitproberen. Maar de vraag is of dit kan. Ik zou namelijk niet weten hoe.
Dat kan zeker. De sessienaam en de sessie-ID zijn te vervalsen doordat ze als een eenvoudig cookie worden uitgewisseld tussen client en server. Bij de standaardconfiguratie van PHP 5 is dat de naam PHPSESSID gevolgd door een MD5-hash voor de ID, dus als iemand je server gaat bestoken met vergelijkbare cookies, kan hij binnenkomen.
In wezen is het dus een eenvoudige variabele. Maak je de waarde langer (minimaal MD5 vervangen door SHA-1) en wijzig je de waarde voortdurend, dan neemt de beveiliging sterk toe.
Vroeger werden sessies nog wel eens onbedoeld overgenomen wanneer de sessie-ID werd doorgegeven in een URL. (Een optie in php.ini die nu standaard uitstaat.) Als iemand dan een link deelde met iemand anders, vaak via e-mail, hadden twee gebruikers dezelfde sessie.
Bij phpBB-fora bijvoorbeeld, net nadat je ingelogd ben.
@Ward: dat is inderdaad dus ook de manier die ik in gedachten had. Maar precies vandaar dus ook mijn vraag. Zoals je zelf zegt kun je de waarde langer maken en telkens wijzigen. En hoewel de kans uiteraard zeer zeer zeer klein is, zou het echter nog steeds kunnen dat iemand met zo'n valse cookie jouw sessie kaapt. Toch? En daar ging mijn vraag dus over. Hoe voorkom je dat? SHA-1 en een telkens wijzigende sessie-id zal de kans kleiner maken dat een hacker de juiste code vindt, maar het maakt het niet onmogelijk. En wat doe je dan als die hacker toch ineens jouw sessie te pakken heeft? Wat is dan het stukje extra controle, waardoor het systeem weet dat 2 gebruikers gebruik maken van dezelfde sessie?
Daarom varen goed beveiligde systemen nooit blind op sessies alleen. Er is altijd een aanvullende beveiliging. Meestal meerdere zelfs.
Zodra er twee clients zijn (waaronder bijvoorbeeld één hacker), verandert de digitale handtekening in de sessie. Degene die een formulier met een verouderde handtekening indient, vist dus achter het net.
Hetzelfde idee als jouw cookie, denk ik, maar minder gevoelig voor cookieweigeraars.
Pagina: « vorige 1 2 3 volgende »