Ik heb een site, ik heb er een brak inlog systeem achter zitten. Wat doe ik nu?
1. Ik heb een tabel met een gebruiker, wachtwoord (md5) en type (admin of gebruiker)
2. Persoon logt in met juiste wachtwoord/gebruikersnaam
3. Een sessie en of cookie wordt aangemaakt met gebruiker is admin of gebruiker is gebruiker. $_SESSION['type']
4. Nu check ik bij pagina's waar alleen gebruikers mogen komen of er een sessie of cookie is met $_SESSION['type'] en of daar instaat of hij admin of gebruiker is.
Dit is natuurlijk zeer onveilig (maakt ook niet super veel uit, want zoveel bijzonders is er niet). Alleen ik wil het toch ietsjes beter regelen.
Mijn vraag:
Ik wil het bovenstaande eens goed overdoen. Waar moet ik rekening mee houden als ik een redelijke beveiligde website wil hebben (ik zeg redelijk, het is namelijk geen bank waar men geldzaken afhandeld).
Ik heb het 1 en ander gelezen over Session hijacking en dat wil ik dus voorkomen.
Dus, welke stappen moet ik doorlopen om tot een redelijke beveiliging te komen. Dit zou ik dan graag willen horen in woorden (code mag ook als je ijverig ben), bijv.
1: tabel met gebruikersnaam en wachtwoord waar wachtwoord een md5 wachtwoord is
2. sessie aanmaken en opslaan in een database tabel
3. etc....
4. etc....
Dan kom ik bij mijn volgende vraag. Ik las ook het 1 en ander over sessies opslaan in een database tabel. hoe gaat dit in zijn werk. Hoe kan ik dit het beste aanpakken, en waar moet ik op letten. Hoe ga je overweg met sessies opslaan in een database als je ook cookies gebruik. Wat stop ik in zo'n sessie en wanneer kan ik hem weggooien en hoe weet ik dat ik de sessie kan weggooien.
Zoals je begrijp ben ik nog steeds een beginner, maar ik wil graag begrijpen hoe een redelijk beveiligde website in elkaar zit, ZONDER simpelweg een standaard scriptje te gebruiken, ik wil het graag zelf maken en leren. Ik begrijp ook dat dit een hoop vragen zijn achter elkaar, ik heb gewoon even getypt wat in mij op kwam.
Bij een account de laatst gebruikte sessie (als hij/zij maar 1 keer mag inloggen)
Het ip vanaf waar is ingelog
Hoelang er al niks gedaan is (mag iemand rustig een half uur niks doen of niet?)
Het gecodeerde wachtwoord (moet hij/zij overnieuw inloggen als het wachtwoord gewijzigd is)
Ik ben op dit moment een forum aan het schrijven, 50% van de tijd zit eigenlijk puur in het inlog/sessie gedeelte. Man wat gaat daar een berg tijd in zitten...
Ik heb dat forum geschreven in de trein, onderweg naar mijn werk de afgelopen anderhalve maand. De rede dat ik veel tijd in die sessies gestoken heb komt doordat ikzelf erg geintereseerd ben in veiligheid en omdat ik het zo vaak mis zie gaan. 'Bedrijfsnaam' slaat gebruikersnamen/wachtwoorden op in plain cookies, phpmyadmin was vrij toegankelijk voor iedereen en bij PHPHulp moet ik continu opnieuw inloggen als ik een ander IPAdres heb (en dat heb ik vaak ivm gprs/hotspots) om erachter te komen dat ik thuis dan ook uitgelogd ben. Om nog maar te zwijgen over de tijden dat je dood leuk door het spelen met cookies jezelf admin kon maken ;). Ook op school ben ik er veel mee bezig, ik heb zelfs gastcolleges gehad van mensen die bij MI5 en MI6 (!) opdrachten gedaan hebben.
Allereerst, veiligheid begint met backups. 100% veilig bestaat namelijk niet... zelfs niet als het alleen intern in een organisatie gebruikt word. In 80% van de gevallen word er namelijk 'gehacked' vanaf binnen het bedrijf. In geval van bedrijven begint de veiligheid niet op het internet maar bij de voordeur. Er zijn in Nederland 2 locaties waar je zo naar binnen kunt lopen met genoeg bandbreedte/processorkracht om zonder problemen Microsoft neer te leggen. Denk daar maar eens over na...
Vervolgens kijken we naar het systeem zelf, welke accounts hebben welke rechten? Kan mijn webhost bij mijn software om aanpassingen te doen? Waneer zie ik het als er gerotzooid is met mijn bestanden/backups?
Maar we hebben het over PHP scripts... Zoiezo dubbelcheck je alle userinput, GET's, POST's, SESSIE's etc etc. Niks is te vertrouwen. Escape alles wat de database ingaat, check alles op XSS, laat geen (java-)scripts toe in inputvelden, controleer of de requests wel van je eigen domein afkomen en controlleer iedere afbeelding die geupload word. Er zijn grote problemen met dingen als GIF en Internet Explorer en het is dus absoluut geen probleem om jou cookies naar mij te sturen.
Genoeg stof om over na te denken maar ik wou wat gaan zeggen over die sessies. Ikzelf heb de volgende constructie toegepast in mijn forum;
Allereerst ben ik begonnen met een database tabel xxx_sessies;
Vervolgens schrijf ik die code weg in een Sessie (en als de gebruiker 'remember me' aangevinkt heeft ook in een Cookie) en samen met zijn ipAddress en userAgent ook in de database. De Sessie (en/of Cookie) hebben als 'naam' het ipAddress van de gebruiker. Zodoende kan je eenvoudig meerdere sessies naast elkaar draaien, bijv. als je ook op je werk/school wilt inloggen.
Bij iedere F5 kijk ik of er een Sessie (en/of Cookie) bestaat om vervolgens in de database te kijken of er een Sessie bestaat met zo'n code en of het ipAddress en userAgent nog klopt. Tevens kijk ik of de bijbehorende userID of ipAddress toevallig niet geblokkeerd is. Als er iets niet helemaal klopt verwijder ik je Sessie (en/of Cookie) maar laat ik hem met rust in mijn database.
Zodoende kreeg je toch een redelijke (let op 'redelijke!') veiligheid terwijl het voor de eindgebruiker lekker eenvoudig is. Hij/zij kan namelijk met meerdere browsers inloggen, op meerdere ipadressen werken of een combinatie van dat.
Let op, dit is niet 'de' beveiliging... Je zou eigenlijk verder moeten gaan, ik sla namelijk ook de tijd/datum van de laatste F5 op... na 10 minuten geen activiteit zou ik de Sessie weg kunnen gooien. Maar dat is op een forum niet echt handig ;). Daarnaast, als iemand binnen een bedrijfsnetwerk (zelfde IP) je Cookie jat (een Sessie jatten is iets moeilijker) en hij/zij gebruikt eenzelfde browser (of weet jouw userAgent en spoofd deze) dan kan deze persoon inloggen op jouw account.
Wat ik geleerd heb, zoek een acceptabel beveiligingsniveau. Als de 100% beveiliging (voor zover dat bestaat) je 1 miljoen kost en het restoren van een backup + dat probleem fixen je maar 100k kost kies je voor dat laatste. Daarnaast moet je ook het gemak van de gebruiker in de gaten houden.
Ik ben geen beveiligingsexpert, er lopen hier jongens rond die dit nog veel beter kunnen dan mij. Maar in mijn hoofd zit dit wel goed in elkaar en ik hoop dit in de toekomst ook in de praktijk te kunnen testen als ik dit online zet. Of dat er tegen die tijd iemand langsfietst met betere ideeen.
wow arjan, ik had geen betere reactie kunnen krijgen. Ik zal hem morgen even goed door lezen ik zag er al een hoop bruikbare informatie. Bedankt voor je inspanningen. Ik moet nu eerst even mijn schoolslagingsfeestje voorbereiden.
Nope, want jou ipadres komt niet over met de mijne & jouw browser komt (waarschijnlijk) niet overeen. Tenzij we op eenzelfde ipadres zitten gaat jouw idee dus niet werken.
Uiteraard zal ik op publieke computers/netwerken er voor kiezen om mijn inlog niet te onthouden ;).
Mooie post Arjan!
Ik maak zelf gebruik van Active Directory login bij ons intranet :) worden hierbij ook je inloggevens opgeslagen in een cookie of een sessie?
