Login wat bewaar je in sessies?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

.NET Developer / Innovatieve software / Virtual Re

Functieomschrijving Als .Net developer werken aan innovatieve software waar onder andere gebruik gemaakt wordt van Virtual Reality? Bijdragen aan een organisatie waar je uitgedaagd wordt om continu verbeteringen en ontwikkelpunten te ontdekken en door te voeren? Werken in de omgeving Putten? Reageer dan nu voor meer informatie! Het pro-actief aandragen van verbeteringen voor de bestaande applicatie; Ontwikkelen van nieuwe functionaliteiten; Doorvoeren van aanpassingen en wijzigingen; Verantwoordelijk voor koppelingen met andere systemen; Op de hoogte blijven van technische ontwikkelingen. Functie-eisen Hbo werk- en denkniveau; Een afgeronde IT gerelateerde opleiding; Minimaal 1 jaar professionele ervaring als developer; Aantoonbare kennis van C#; Initiatiefrijke

Bekijk vacature »

Danny von Gaal

Danny von Gaal

08/12/2015 09:25:37
Quote Anchor link
Hallo mensen,

Ik loop nu al een tijdje op internet te zoeken en kom toch zoveel verschillende tutorials tegen over een inlogsysteem. De een spreekt de ander weer tegen maar ik wil niet dat mijn website dadelijk gehackt wordt.

Nou is mijn website voor een kleine groep mensen dus niet heel aantrekkelijk om aan te vallen maar ik maak geen gebruik van https:// dus ik wil het toch goed doen.

Ik ben er wel over uit dat ik geen password in een sessie moet opslaan maar wat dan wel? Ik dacht aan userid en een hash of token. Alleen wanneer de token statisch is geeft het mij hetzelfde gevoel als het opslaan van een password.
Maar wanneer vernieuw ik die token? En hoe makkelijk kan iemand die token uitlezen?
Is dat met sniffen leesbaar of kan je dit plain text openen op een computer?

Ik wil voorkomen dat iemand een token van iemand kan uitlezen en met het userid van user kan switchen.

Thanks.
 
PHP hulp

PHP hulp

07/12/2019 17:48:19
 
Ward van der Put
Moderator

Ward van der Put

08/12/2015 10:05:09
Quote Anchor link
Danny von Gaal op 08/12/2015 09:25:37:
Nou is mijn website voor een kleine groep mensen dus niet heel aantrekkelijk om aan te vallen maar ik maak geen gebruik van https:// dus ik wil het toch goed doen.

Toch staat of valt alles met HTTP/S. Zonder encryptie van het netwerkverkeer is alles te onderscheppen, waaronder e-mailadressen, gebruikersnamen en wachtwoorden. Als een wachtwoord onversleuteld wordt verzonden, maakt het daarna nauwelijks nog uit wat je verder op je server met dat wachtwoord doet: het is mosterd na de maaltijd.

Danny von Gaal op 08/12/2015 09:25:37:
Ik ben er wel over uit dat ik geen password in een sessie moet opslaan maar wat dan wel? Ik dacht aan userid en een hash of token. Alleen wanneer de token statisch is geeft het mij hetzelfde gevoel als het opslaan van een password.
Maar wanneer vernieuw ik die token? En hoe makkelijk kan iemand die token uitlezen?
Is dat met sniffen leesbaar of kan je dit plain text openen op een computer?

Beschouw de sessie als een cache: je kunt erin cachen wat je nodig hebt gedurende de rest van de sessie. Dat kan inderdaad een user-ID zijn. Een wachtwoord sla je per definitie nooit op, omdat je dat maar één keer nodig hebt: bij de verificatie voor het starten van een sessie met bepaalde rechten.

De sessie komt vooral van pas als cache als je daarmee het aantal databaseconnecties en databasequeries kunt beperken. Dat kan bijvoorbeeld betekenen dat je in plaats van alleen de user-ID een compleet user-object opslaat in de sessiecache: je bespaart dan op het dataverkeer dat anders nodig is om iets van die gebruiker op te halen uit de database.

Een token per sessie gebruiken, heeft weinig zin: daarvoor heb je al de sessie-ID. Die kun je minder makkelijk te raden maken door bijvoorbeeld 512-bits SHA-2 te gebruiken (in plaats van MD5, de standaardinstelling van PHP). Je moet de sessie-ID daarnaast in minstens twee situaties opnieuw genereren, zodat de voorafgaande sessie verloren gaat: bij het overschakelen van HTTP naar HTTP/S en na een succesvolle login.

Wat je beter kunt doen met tokens, is een uniek token gebruiken per transactie: sla deze op in de sessie en plaats deze in een verborgen formulierveld. Bij de POST vergelijk je de geretourneerde token met die in de sessie, zodat je redelijk zeker weet dat een formulier wordt ingediend door de client die het heeft ontvangen. Vervolgens genereer je een nieuw token voor de volgende transactie in dezelfde sessie.
 
Danny von Gaal

Danny von Gaal

08/12/2015 11:34:17
Quote Anchor link
Bedankt voor je uitleg Ward.
Misschien ga ik toch nog eens kijken naar https. Het probleem is dat ik momenteel een virtual centos machine heb in de cloud en daar al een certificaat op heb staan voor een andere website. Ik zal dus een extra ip-adres nodig hebben om voor deze website ook een certificaat te kunnen gebruiken.

Maar begrijp ik nu goed dat ik geen extra controles hoef op te slaan in een sessie? Maar alleen gegevens die makkelijk zijn om te gebruiken in mijn website als cache? Ik dacht dat de sessie ook werd gebruikt om per pagina te controleren of de userid en token wel overeen kwamen om zo aanvallen tegen te gaan.

Althans zo gebruikte ik het altijd.
 
Ward van der Put
Moderator

Ward van der Put

08/12/2015 12:56:07
Quote Anchor link
>> Maar begrijp ik nu goed dat ik geen extra controles hoef op te slaan in een sessie?

Je kunt uiteraard wel extra controles toevoegen, ook voor de beveiliging.

Een voorbeeld is een controle op $_SERVER['HTTP_USER_AGENT']. Die string kan tijdens de sessie eigenlijk alleen in drie uitzonderlijke situaties wijzigen: als de bezoeker een update installeert van de browser, van het besturingssysteem of een van een plug-in. Sla je de user agent op in de sessie en vergelijk je die bij elk request met $_SERVER['HTTP_USER_AGENT'], dan mag die niet veranderen en kun je de sessie vernietigen als de string onverhoopt toch eens verandert: installeert de gebruiker een update, dan moet hij aansluitend opnieuw inloggen.

Het werkt in de praktijk alleen verre van optimaal, omdat hackers en crackers het dataverkeer aftappen en gewoon identieke HTTP-headers verzenden als een echte client om daarvan de sessie te kapen. Lang leve gratis WiFi.

Een random token dat je per response verandert en doorgeeft in een verborgen formulierveld is dan veel veiliger. Als je in een response een formulier met token x uitreikt, wil je in het volgende request van de client dat token x terugontvangen, anders is het request ongeldig binnen de huidige sessie. Ook daarmee heb je een extra controle op de geldigheid van het volgende request. Dus jawel: je kunt sessie wel degelijk gebruiken voor aanvullende beveiligingscontroles.

Neem ook eens het OWASP Session Management Cheat Sheet door.
 
Verwijderd 31683

Verwijderd 31683

08/12/2015 13:35:12
Quote Anchor link
@Ward
Het principe wat je daar omschrijft is toch met name bedoeld om CSRF tegen te gaan? Dit is dus in zijn algemeenheid bedoeld als controle of een bezoeker van de site een formulier invult. Dit kan vervolgens ook heel handig gebruikt worden voor een login-formulier (maar de toepassing gaat verder dan dat).

@Danny
Je moet een sessie-bestand zien als een "serverside cookie". Alleen jij zou hier inhoud in moeten kunnen zetten en uit moeten kunnen halen. De webserver weet welke sessie van jou is doordat je elk request een verwijzing naar je sessie middels een cookie doorstuurt. Het is dan dus belangrijk dat ofwel je sessie-cookie niet onderschept (dat zou inhouden dat je netwerk niet veilig is) of gestolen kan worden (dat zou inhouden dat je website vatbaar is voor XSS), of dat je, zoals Ward aangeeft, aanvullende maatregelen treft die de webserver in staat stelt om jou beter te identificeren (zoals bijvoorbeeld een user agent check, of, indien je vanaf een vaste locatie inlogt, een IP-controle).

Ik zou in een sessie enkel (voor het login gedeelte dan he) een user id opslaan, en in PHP dan een soort van user object creëren wat je vervolgens kunt gebruiken. Dit user object wordt dan elk request opnieuw gecreëerd maar dat is wel fijn, want op die manier worden wijzigingen in zo'n gebruiker direct zichtbaar en blijven deze niet "hangen" (zoals normaal in een sessie zou gebeuren) totdat je opnieuw inlogt of dat je code schrijft om deze handmatig on-the-fly in je sessie te verversen ofzo.
 
Danny von Gaal

Danny von Gaal

08/12/2015 14:01:19
Quote Anchor link
@Thomas: Oke dus wanneer iemand is ingelogd en ik heb al gecontroleerd of user & ww matchen dan hoef ik alleen nog maar het userid op te slaan? Het is dus niet mogelijk voor iemand anders om zomaar een ander userid in die sessie te plaatsen?

Ik heb momenteel een userid en hash in een sessie en boven elke pagina controleer ik nog eens of die twee wel overeenkomen. Maar dat is dus eigenlijk overbodig??

@Ward: Die random token gebruik ik ook maar dat is alleen maar om van mijn loginpagina naar het loginscript te gaan zodat ik zeker weet dat die gene daar komt via het formulier.
Gewijzigd op 08/12/2015 14:02:00 door Danny von Gaal
 
Ward van der Put
Moderator

Ward van der Put

08/12/2015 14:11:09
Quote Anchor link
Thomas van den Heuvel op 08/12/2015 13:35:12:
@Ward
Het principe wat je daar omschrijft is toch met name bedoeld om CSRF tegen te gaan? Dit is dus in zijn algemeenheid bedoeld als controle of een bezoeker van de site een formulier invult. Dit kan vervolgens ook heel handig gebruikt worden voor een login-formulier (maar de toepassing gaat verder dan dat).

Het principe werkt beter als je het niet beperkt tot de login, maar tot elk gevoelig of potentieel gevaarlijk request. De login genereert immers slechts een geldige sessie met een bepaalde sessie-ID, maar het gaat er vooral om wat dáárna in die sessie wordt gedaan.

Het helpt daarbij niet alleen tegen CSRF/XSRF, maar ook tegen vormen van session hijacking, zoals session fixation en XSS: je hebt namelijk niets aan een geldige gestolen of geraden sessie-ID als je niet tevens beschikt over een geldig form token.
 
Verwijderd 31683

Verwijderd 31683

08/12/2015 14:30:09
Quote Anchor link
Danny von Gaal op 08/12/2015 14:01:19:
Het is dus niet mogelijk voor iemand anders om zomaar een ander userid in die sessie te plaatsen?

Als je daar niet van uit kunt gaan of dat je in een vlaag van verstandsverbijstering code hebt geschreven die dat voor elke gebruiker vrijblijvend mogelijk maakt dan is de integriteit van je systeem niet langer te waarborgen :).

Oftewel: in principe niet :).
 
Danny von Gaal

Danny von Gaal

08/12/2015 14:35:32
Quote Anchor link
@Thomas: ik realiseer me nu pas dat sessions op de server worden opgeslagen en dat er alleen een session id op de client wordt opgeslagen die correspondeert met de sessie op de server. Ik dacht altijd dat de inhoud van de sessie gewoon op de client werd opgeslagen. Stom! Dit helpt me wel meer met het begrijpen van sessies en het maken van een veilig inlogsysteem.
 
Verwijderd 31683

Verwijderd 31683

08/12/2015 14:47:26
Quote Anchor link
Danny von Gaal op 08/12/2015 14:35:32:
Dit helpt me wel meer met het begrijpen van sessies en het maken van een veilig inlogsysteem.

Vandaar dat ik daar wat meer uitleg over gaf, ik kreeg een beetje de indruk dat sessies nog een beetje een "black box" voor jou waren :). En als je iets wilt beveiligen helpt het enigszins als je begrijpt hoe datgene wat je probeert te beveiligen in elkaar steekt.
 
Danny von Gaal

Danny von Gaal

08/12/2015 14:56:52
Quote Anchor link
Ja thanks, ik dacht altijd dat het op de client stond.
Vandaar dat ik een sessie met userid maakte en een met een hash en die continue met elkaar controleerde.

Dan wist ik zeker dat wanneer iemand handmatig de userid aanpaste het niet ging werken omdat hij/zij de hash niet wist.

Dit geeft me meer duidelijkheid en ook wel een fijn gevoel. Het is dus op zich al best veilig en de data is niet zomaar door een simpele gebruiker te veranderen.
 
Verwijderd 31683

Verwijderd 31683

08/12/2015 15:13:16
Quote Anchor link
Een licht paranoïde houding is bij security vaak handig. Zo zijn sessie-bestanden van zichzelf dan wel veilig (in principe), maar wat als de locatie waar de sessie-bestanden staan opgeslagen dit niet is?

Ik heb het serieus meegemaakt bij shared hosting dat sessie-bestanden van verschillende sites gewoon in dezelfde directory stonden opgeslagen. Ik ben toen ook even gaan kijken wat er in al die sessies stond natuurlijk :). In mijn verdediging beroep ik mij op uitlokking :).

Een grote "winstpakker" ingeval je op shared hosting zit kan dus het instellen van een custom sessie directory (BUITEN JE WEBDIRECTORY UITERAARD LOL) zijn.

Of in zijn algemeenheid: stel dit soort zaken expliciet in. Ga nergens van uit.
 
Danny von Gaal

Danny von Gaal

08/12/2015 15:27:27
Quote Anchor link
Dat is inderdaad wel handig en uiteraard buiten je webdirectory. ;-)

Gelukkig is dat in mijn geval niet zo en heb ik een dedicated webserver die beveiligd is met SELinux waardoor iemand vanuit mijn website nooit buiten de root van mijn site andere folders in kan.

Het is dus voor een buitenstaander niet mogelijk om mijn sessie directory in te kunnen zonder mijn root password te weten.
 
Ben van Velzen

Ben van Velzen

08/12/2015 21:42:07
Quote Anchor link
Apache kan er ook bij, dus dat is niet helemaal waar. Als je uitgaat van correcte labels kan SELinux krachtig zijn. Het alleen inschakelen ervan heeft niet zoveel zin.
 
Danny von Gaal

Danny von Gaal

09/12/2015 10:57:48
Quote Anchor link
Als je security context goed staat Ben dan werkt het prima. :-)
 
Ben van Velzen

Ben van Velzen

09/12/2015 11:32:38
Quote Anchor link
Er vanuit gaande dat dat zo is wel, maar standaard is dat niet zo, dus ga ik daar niet vanuit.
 
Danny von Gaal

Danny von Gaal

15/12/2015 17:59:42
Quote Anchor link
Ik heb nou toch maar een certificaat aan de website gehangen en https:// afgedwongen. Heb een goedkoop certificaat gekocht wat wel onder geotrust hangt haha.
Nou kan zeker niemand het verkeer onderscheppen.
 
- Ariën -
Beheerder

- Ariën -

15/12/2015 18:03:42
Quote Anchor link
Als je je server goed up2date hebt, en geen Heartbleed op Poodle-lek hebt, dan zit je veilig.
 
Danny von Gaal

Danny von Gaal

15/12/2015 23:16:46
Quote Anchor link
Ik zal hem regelmatig door de ssl check halen :-)
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.