[PHP] Session maar dan veiliger

[Verwijderd]

Ik ben bezig met een site dat gebruikt maakt van PHP sessions om in te loggen.
PHP session kan zelf beslissen of het gebruik maakt van cookies of van een get methode.
Dit omdat de site niet in problemen mag komen als een browser geen cookies accepteerd.

Dit werkt allemaal goed. Het enige probleem is wanneer de sessionid in de url staat het gevaarlijk kan worden. Want wanneer iemand de url kopiert en opstuurt naar iemand anders met het motto "Moet je dit eens zien". Kan de andere gebruiker met dezelfde sessionid inloggen op de server.
Dit wil ik dus voorkomen.

Je kunt de boel dan ook gaan beveiligen m.b.v. IP's en User agents op te slaan. Maar dit werkt ook niet goed. Als er bijvoorbeeld een bedrijfsnetwerk met allemaal dezelfde pc's met het zelfde ip adressen zijn, en iemand stuurt een mailtje naar een collega met een url. Dan kan die collega alsnog gebruik maken van de sessionid. Geloof mij, dit kan voorkomen!

Is er een betere manier waarmee je een sessionid kan doorgeven via de get methode zonder dat daar andere mensen gebruik van kunnen maken?

[Martin Sturm]

Volgens mij is de enige methode om dit te voorkomen het uitschakelen van het doorgeven van de session-id via de url. Volgens mij kan dat in php.

[whazza]

En als je het met session_register() doet? Dan kan je op de server bijhouden of een bepaald ID wel of niet ingelogged is en met welke gegevens. Als de gegevens van de server en de client niet overeenkomen verwijs je ze gewoon weer naar de inlogpagina (of een andere pagina)

dus bijv. na inloggen:
$check = "ok";
Session_register("check");

moet je wel op elke pagina session_start(); hebben staan natuurlijk, maar lijkt me dat je dat al deed ivm de SID in de url

suc6

[justmental]

Je kunt op de server bijhouden welke sessie aan welk IP is gekoppeld.
Zo voorkom je het voorbeeld wat jij noemde.
Dan heb je alleen geen ondersteuning voor mensen die achter een proxy zitten die met meerdere IP adressen werkt.

[mjax]

whazza schreef op 28 juli 2003 @ 16:53:
En als je het met session_register() doet? Dan kan je op de server bijhouden of een bepaald ID wel of niet ingelogged is en met welke gegevens. Als de gegevens van de server en de client niet overeenkomen verwijs je ze gewoon weer naar de inlogpagina (of een andere pagina)

dus bijv. na inloggen:
$check = "ok";
Session_register("check");

moet je wel op elke pagina session_start(); hebben staan natuurlijk, maar lijkt me dat je dat al deed ivm de SID in de url

suc6

Hier los je toch niks mee op? De variabele check wordt nu geassocieerd met de sessie en dus ook met het sessie ID. Probleem blijft.

[ Voor 70% gewijzigd door mjax op 28-07-2003 16:57 ]

[Soultaker]

Veel proxies vullen netjes de "X-Forwarded-For" HTTP header in. Als je dus controleert op zowel de inhoud van dit veld als het adres van degeen die het request doet, ben je al redelijk "veilig" bezig.

Veilig betekent hier: beveiligd tegen het per ongeluk doorgeven van URL's. Als mensen de boel met opzet willen frustreren, lukt dat ze toch wel.

Nog makkelijker is natuurlijk alleen sessie id's in cookies toestaan. Daarvoor moet je transparante sessie id's uitzetten in PHP.

[Johnny]

Een sessie blijft toch maar een uur actief ofzo, als iemand daarna de site bekijkt is de sessie verlopen en kun je er op.

Je zou ook het IP kunnen opnemen in de sessie, op die manier kan alleen iemand vanaf dezelfde verbinding, voordat de sessie is verlopen er op komen.

[ACM]

Soultaker schreef op 28 July 2003 @ 17:01:
Nog makkelijker is natuurlijk alleen sessie id's in cookies toestaan. Daarvoor moet je transparante sessie id's uitzetten in PHP.

Browsers die de cookies niet kunnen accepteren, kunnen de site toch vaak al niet laten zien. En mensen die ze expres uitzetten hebben toch al een niet al te jofele-browser-experience tegenwoordig

Afgezien van enkel wap-browsers enzo natuurlijk (hoewel de mijne zelfs cookies kan opslaan, alleen nooit gebruikt ).

Wat ik overigens ooit nog eens bedacht had was het meesturen van een unieke-id die _per_ request anders is en als de browser die de volgende request niet terugstuurt is het een andere browser, nadeel is dat je dan niet meerdere requests tegelijk kan doen, tenzij je dat weer correct afvangt.
Met cookies zal dat iets beter werken wellicht, maar die zijn toch al veiliger.

[bigtree]

Deze situatie: meerdere clients met hetzelfde ip, zelfde browser. Komt maar al te vaak voor. Als ze cookies accepteren is er niks aan de hand, behalve dat bij de eerste pageview (na het starten van de sessie) de sessieid ook in de url staat. En als ze die kopieren nemen ze dus elkaars sessie over, gegarandeerd. Dit kun je oplossen door bij (elke!) pageview te checken of er een sessieid in de url zit ($_GET) EN in een cookie ($_COOKIE). Als dat zo is, accepteert de client in ieder geval cookies en kan je hem met een header doorsturen naar dezelfde pagina, maar dan zonder de sessieid in de url.
Als de client geen cookies ondersteunt heb je een probleem uiteraard. Als je koste wat kost de sessieid niet in de url wilt hebben, kan je elke pageview vanuit een formulier met een POST method plaats laten vinden.

[Soultaker]

ACM schreef op 28 juli 2003 @ 17:09:
Browsers die de cookies niet kunnen accepteren, kunnen de site toch vaak al niet laten zien. En mensen die ze expres uitzetten hebben toch al een niet al te jofele-browser-experience tegenwoordig

Ik kan me goed voorstellen dat je persistente cookies uitschakelt, maar waarom je sessiecookies (die verdwijnen als de browser wordt afgesloten) zou willen blokkeren is me een raadsel. Dan vraag je er naar mijn mening een beetje om dat de website niet werkt.

Wat ik overigens ooit nog eens bedacht had was het meesturen van een unieke-id die _per_ request anders is en als de browser die de volgende request niet terugstuurt is het een andere browser, nadeel is dat je dan niet meerdere requests tegelijk kan doen, tenzij je dat weer correct afvangt. Met cookies zal dat iets beter werken wellicht, maar die zijn toch al veiliger.

Maar dan kan je ook niet meer de huidige pagina refreshen, ben ik bang... Ik zou er zelf gewoon voor kiezen om niet te moeilijk te doen en gewoon te zorgen dat de pagina voor iedereen blijft werken.

GrunGe: wat is eigenlijk de reden dat je een "veiligere" methode nodig hebt?

bigtree schreef op 28 July 2003 @ 17:17:
Dit kun je oplossen door bij (elke!) pageview te checken of er een sessieid in de url zit ($_GET) EN in een cookie ($_COOKIE). Als dat zo is, accepteert de client in ieder geval cookies en kan je hem met een header doorsturen naar dezelfde pagina, maar dan zonder de sessieid in de url.

Dat hoef je niet op te lossen; zo werkt PHP uit zichzelf al. Het probleem is alleen dat als je een URL kopieert naar een client die de site verder niet kent, er alleen een ID in de URL staat (en er voor deze request nog geen cookie bestaat).

Maar laten we wel zijn, we hebben het op deze manier over domme IE gebruikers die achter een proxy zitten en niets van internet snappen. Die hebben gewoon default settings en dus cookies enabled.

[ Voor 26% gewijzigd door Soultaker op 28-07-2003 18:20 ]

[bigtree]

Soultaker schreef op 28 juli 2003 @ 18:16:
[...]
Dat hoef je niet op te lossen; zo werkt PHP uit zichzelf al. Het probleem is alleen dat als je een URL kopieert naar een client die de site verder niet kent, er alleen een ID in de URL staat (en er voor deze request nog geen cookie bestaat).

Dat klopt niet helemaal. Als je een sessie voor het eerst start met session_start, schrijft php achter alle links op die pagina je sessieid. De eerste pageview daarna heeft dus de sessieid in de url. Of je nou cookies accepteert of niet. Test zelf maar.

[ACM]

bigtree schreef op 28 July 2003 @ 18:57:
Dat klopt niet helemaal. Als je een sessie voor het eerst start met session_start, schrijft php achter alle links op die pagina je sessieid. De eerste pageview daarna heeft dus de sessieid in de url. Of je nou cookies accepteert of niet. Test zelf maar.

Dat heet dus 'Transparant Sessionid' dat kan je uitzetten

[Verwijderd]

Tja, als het echt zo belangrijk is dan kun je de site wellicht pop-uppen (whaaaaaa wat een eng woord)...

Maar zoals iemand al heel scherp opmerktte, als men wil 'lichten ze de boel toch wel op'.

[bigtree]

ACM schreef op 28 July 2003 @ 19:18:
[...]

Dat heet dus 'Transparant Sessionid' dat kan je uitzetten

Dat was niet de bedoeling:

Verwijderd schreef op 28 July 2003 @ 16:47:
[...]
Dit omdat de site niet in problemen mag komen als een browser geen cookies accepteerd.

[ACM]

bigtree schreef op 28 July 2003 @ 19:43:
Dat was niet de bedoeling:

Klopt, maar een deel van de argumentatie van Soultaker was dat die cookies toch zelden uitgeschakeld zijn en dat deel van de argumentatie onderbouwde ik zelf ook.
Met als gevolg dat transparant sessions in theorie best uitgeschakeld kunnen zijn, tenzij het dus inderdaad vaak voorkomt in plaats van een theoretische mogelijkheid te zijn

[Soultaker]

Misschien kan de TS zijn doel toelichten? Het wordt zo een beetje wazige discussie moet een opsomming van mogelijke hacks met allemaal hun eigen voor- en nadelen, zonder dat duidelijk is wat nu precies de bedoeling is.

[pietje63]

eeh, ben ik nou zo dom of kun je dit gewoon beveiligen door IETS in de sessie te registreren en dan een controle in te bouwen of de geregistreerede (id ofzo) overeenkomt met de sessie_id

[MikeN]

Verwijderd schreef op 28 July 2003 @ 16:47:
Je kunt de boel dan ook gaan beveiligen m.b.v. IP's en User agents op te slaan. Maar dit werkt ook niet goed. Als er bijvoorbeeld een bedrijfsnetwerk met allemaal dezelfde pc's met het zelfde ip adressen zijn, en iemand stuurt een mailtje naar een collega met een url. Dan kan die collega alsnog gebruik maken van de sessionid. Geloof mij, dit kan voorkomen!

Zo ongeveer iedere bedrijfsproxy stuurt wel een HTTP_X_FORWARDED_FOR of een HTTP_CLIENT_IP header mee. Als je daarop checked ben je al veilig bezig, zeker als je dan ook nog de useragent checked. Stukje PHP wat ik daarvoor gebruikt heb is:

PHP:

// Sessienaam setten
session_name($sessionname);

// Sessie starten
session_start();

// IP bepalen
if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])){
    $realip = $_SERVER['HTTP_X_FORWARDED_FOR'];
} 
elseif (isset($_SERVER['HTTP_CLIENT_IP']))
{
    $realip = $_SERVER['HTTP_CLIENT_IP'];
} 
else 
{
    $realip = $_SERVER['REMOTE_ADDR'];
}

// Checken of session clientip geset is, zo niet setten, anders vergelijken
if(isset($_SESSION['clientip'])){
    if(!($_SESSION['clientip'] == $realip)){
        session_destroy();
        unset($_SESSION);
    }
}
else
{
    $_SESSION['clientip'] = $realip;
}

// Checken of session useragent geset is, zo niet setten, anders vergelijken
if(isset($_SESSION['useragent'])){
    if(!($_SESSION['useragent'] == $_SERVER['HTTP_USER_AGENT'])){
        session_destroy();
        unset($_SESSION);
    }
}
else
{
    $_SESSION['useragent'] = $_SERVER['HTTP_USER_AGENT'];
}

Veel veiliger dan dit is het volgens mij niet te maken, tenzij je OF trans-sid uitzet OF het via lastige (volgens mij moeilijk werkbaar makende) oplossingen gaat doen zoals ACM aandraagt.

[justmental]

MikeN schreef op 29 July 2003 @ 01:47:
Zo ongeveer iedere bedrijfsproxy stuurt wel een HTTP_X_FORWARDED_FOR of een HTTP_CLIENT_IP header mee. Als je daarop checked ben je al veilig bezig, zeker als je dan ook nog de useragent checked. Stukje PHP wat ik daarvoor gebruikt heb is:
*knip*
Veel veiliger dan dit is het volgens mij niet te maken, tenzij je OF trans-sid uitzet OF het via lastige (volgens mij moeilijk werkbaar makende) oplossingen gaat doen zoals ACM aandraagt.

Geen HTTP_X_FORWARDED_FOR ed. gebruiken, dat maakt je oplossing juist weer kwetsbaar.
Als je iemands sessie-id te pakken kan krijgen dan kun je in een keer ook zaken als IP en user agent mee laten komen.
Als je dat IP dan faked in HTTP_X_FORWARDED_FOR en de user agent overneemt ben je als nog binnen.
Op het moment dat je alleen REMOTE_ADDR gebruikt zou je op hetzelfde IP of achter dezelfde proxy moeten gaan zitten en dat is vaak veel moeilijker.

[Spider.007]

Zelf ben ik ook tegen dit probleem aangelopen in een webapplicatie; dus alles ging dmv formulieren. Mogelijke oplossingen:

• Alles met post ipv get doen
• Een 1-in-1 frameset gebruiken om de URL met sessie te verbergen. Eventueel kun je het hidden frame dan zelfs gebruiken om de sessie automatisch te beindigen (of eigenlijk te behouden en zodra dit niet gebeurd te beindigen

Deze laatste oplossing bleek uiteindelijk afdoende tegen mensen die de URL gaan kopieeren.

[Verwijderd]

Even wat meer info:
Het gaat hier om een webwinkel. Deze webwinkel kan 2 verschillende sessies gebruiken.

In de eerste sessie staan de gegevens van het winkelwagentje. Deze sessie moet beschikbaar zijn voor gebruikers die cookies hebben uitgeschakeld. Een session id in de url lijkt mij niet zo'n ramp, want de gebruikers kunnen hoogstens hun winkelwagentje wijzigen.
Waarom cookies uitschakelen? Wanneer gebruikers cookies weigeren en dan werken met een half werkende site, en blijven de gebruikers weg.

In de tweede sessie staan de login gegevens van een geregistreerde gebruiker. Deze session wordt gebruikt om een bestelling te maken van de artikelen uit het winkelwagentje. Bij deze session is het heel erg belangrijk dat een gebruiker gebruik kan maken van een anders session.
Misschien moet ik hiervoor toch overwegen om cookies te gaan gebruiken. De gebruiker is dan genoodzaakt om cookies aan te zetten, anders kunnen ze geen bestelling versturen.

Een andere optie is gebruik maken van POST methode. Ik heb hier al eerder aan gedacht, maar er zitten een aantal nadelen aan:
- Je moet elke keer als je op de vorige button klikt of de pagina refreshed steeds confirmen dat je alles opnieuw wilt versturen.
- Van elke link moet een submit link/button gemaakt worden.

Een site met een gebroken "terug" button mag gewoon NIET.

Het scriptje dat MikeN geeft lijkt mij niet betrouwbaar genoeg. Deze gegevens kunnen gefaked worden. En het is niet duidelijk of een proxy server wel altijd deze gegevens juist doorstuurt.

ACM heeft het over een random session id per request. Dit lijkt mij ook een optie.
Je zet bij elke link naar een nieuwe pagina een session id met md5sum o.i.d. De nieuw gegenereerde md5sum moet worden opgeslagen in een database. Wanneer iemand de pagina benaderd met deze md5sum wordt de key uit de database gehaald en een nieuwe gegenereerd.
Op elke key moet een tijdslimiet komen van 30 seconde of 2 minuten. Dit om kopieren van de url alsnog te verkomen.

Een laatste ding. De volledige url moet gewoon beschikbaar zijn. Wanneer iemand de url wil kopieren om iemand anders de pagina te laten zien, moet de persoon wel de goede pagina krijgen en niet gewoon een index pagina. De mogelijke md5sum moet dan al niet werken en geen invloed hebben op de pagina layout.

[justmental]

Waarom zou iemand een account voor je webwinkel willen hacken?
Zitten er bijzondere rechten oid. aan gekoppeld?
Als iemand toch betaalt dan maakt het toch niet uit of ie onder 'jantje' of 'pietje' koopt?

[Verwijderd]

justmental schreef op 29 July 2003 @ 09:38:
Waarom zou iemand een account voor je webwinkel willen hacken?
Zitten er bijzondere rechten oid. aan gekoppeld?
Als iemand toch betaalt dan maakt het toch niet uit of ie onder 'jantje' of 'pietje' koopt?

Dit is echt de grootste onzin. Weet je hoe slecht het is als andere mensen onder jouw naam dingen gaan kopen. Je krijgt toren hoge facturen en artikelen die je niet besteld hebt.
Dit lijkt mij geen klant vriendelijke service.

[ Voor 30% gewijzigd door Verwijderd op 29-07-2003 10:00 ]

[justmental]

Verwijderd schreef op 29 July 2003 @ 09:58:
Dit is echt de grootste onzin. Weet je hoe slecht het is als andere mensen onder jouw naam dingen gaan kopen. Je krijgt toren hoge facturen en artikelen die je niet besteld hebt.
Dit lijkt mij geen klant vriendelijke service.

Als ik zondermeer een account kan maken dan kan ik ook de gegevens van een willekeurig persoon invullen.
Het is wel degelijk nodig om dit te valideren, maar dit hoeft dus niet samen te hangen met het login-id.

[bigtree]

Voor een webwinkel is het heel gewoon dat mensen cookies moeten hebben ingeschakeld. Om die reden kan je dus wel een eigen sessie-cookie maken of een php-sessie gebruiken zonder transid.

En voor de aanhangers van HTTP_X_FORWARDED_FOR onder ons: al eens van NAT gehoord?

[ACM]

Ik zou idd nog steeds de cookies aangezet vereisen. Wel middels een nette melding, dat men iig de sessie-cookie-support van zijn browser in moet schakelen, maar daarna gewoon weigeren een bepaalde dienst te verrichten als er geen sessie-cookie gezet kon worden.

Heb je daadwerkelijk cijfers van hoevaak mensen zonder cookies langsbrowsen?

[Soultaker]

Spider.007 schreef op 29 July 2003 @ 08:34:
Een 1-in-1 frameset gebruiken om de URL met sessie te verbergen.

Als het enige doel het voorkomen van het per ongeluk copy-pasten is, dan lijkt me dit een eenvoudige en geschikte optie, die werkt zonder het gebruik van cookies te vereisen. Denk eraan dat mensen dan ook geen pagina's binnen je site meer kunnen bookmarken, maar dat wil je met een dynamische site misschien ook niet. (Desnoods gebruik je het frame alleen voor de echte dynamische pagina's, zodat je nog wel de leveringsvoorwaarden, of iets dergelijks, kunt bookmarken.)

Qua security is dit net zo sterk als het gebruik van cookies; dat wil zeggen: er is geen enkele beveiliging van je sessie id, maar wel van de inhoud van je sessie (die lokaal op de server staat). IP beperkingen kun je zelf nog server-side toevoegen, maar de vraag is of dat zinnig is. Ik zou als klant zelf (veel) blijer zijn met encryptie door middel van SSL (HTTPS) dan is het al praktisch uitgesloten dat iemand mijn sessie hijacked (of ziet dat ik allemaal porno-DVD's in m'n winkelmandje aan 't flikkeren ben .)

ACM schreef op 29 July 2003 @ 11:28:
Heb je daadwerkelijk cijfers van hoevaak mensen zonder cookies langsbrowsen?

En bij een webshop zullen die cijfers nog veel lager liggen.

[ Voor 23% gewijzigd door Soultaker op 29-07-2003 16:04 ]

[samo]

Misschien een stom idee, maar wat dacht je er van alleen geregistreerde gebruikers te laten bestellen: laat ze een wachtwoord invullen, dat ze nogmaals gebruiken als ze de bestelling doorsturen. In dit geval kan zoŽn sessie alleen expres worden doorgestuurd, namelijk als het wachtwoord ook ik de email staat

[Janoz]

Verwijderd schreef op 29 juli 2003 @ 09:58:
[...]

Dit is echt de grootste onzin. Weet je hoe slecht het is als andere mensen onder jouw naam dingen gaan kopen. Je krijgt toren hoge facturen en artikelen die je niet besteld hebt.
Dit lijkt mij geen klant vriendelijke service.

Een mail bevestiging lijkt me een betere optie. Op die manier besteed je de beveiliging uit aan de mail aanbieder . Gewoon een validatie techniek gebruiken die ook hier voor het aanmaken van een acount wordt gebruikt. Je kunt de boel wel erg goed gaan beveiligen, maar als je vervolgens ziet wat voor username/password combo mensen gebruiken snap je niet waar je het eigenlijk voor doet ..

[ Voor 14% gewijzigd door Janoz op 29-07-2003 16:11 ]

[Verwijderd]

Ik gebruik nu voor het winkelwagentje de normale PHP session functie.
Voor de sessie van een geregistreerde gebruiker gebruik ik ook de normale PHP session, maar dan met cookie_only aan. Dus de gebruiker wordt dus tijdens het registreren gewaarschuwd over het gebruik van cookies. Zonder cookies aan kan je niet worden geregistreerd of inloggen.
Misschien kan ik dit in toekomst alleen op een waarschuwing houden, zodat de gebruiker weet dat het gevaarlijk kan zijn.

Over cijfers van bezoekers die hun cookies uit hebben staan interreseerd mij niet zo.
Cijfers zijn niet betrouwbaar en mag niet bepalen of de ene gebruiker maar lekker pech heeft.
Een voorbeeld hiervan is girotel. Girotel werkt perfect onder IE en netscape. Maar onder mozilla/galeon krijgt de gebruiker last van een fout in het java systeem. Typisch een grote fout van de makers, omdat ze denken dat 90% van de gebruikers IE of netscape gebruikt en kan de rest verwaarloosd worden.