Tijden veranderen
Session Fixation
Session-fixation kan volgens mij bij mij niet eens, maar ik had toch voor de zekerheid session_regenerate_id() gebruikt.
Dus van beide garen heb ik geen last.
Om, allereerst die cookie/sessie te hijacken moet je d.m.v. een lek de cookie/sessie hijacken. Vervolgens moet je achter het IP, de host en de user-agent komen van de ingelogde persoon. Dan moet je het IP adres spoofen, host vervalsen en de useragent namaken.
Dan moet je zo ver komen, en dan nog, hoe zou je dat hele plan kunnen tegengaan...
WireShark -> HTTP headers aftappen -> cookie met session-id binnen, user-agent binnen.
Verbinden met netwerk -> vanaf router ip-adres van de ISP, zelfde dus als dat van het slachtoffer -> IP adres 'gespoofd'
IP adres wordt via de dns-servers van de isp omgezet in een hostname, dus wanneer je hetzelfde ip-adres hebt, heb je automatisch ook dezelfde hostname. Ik denk niet dat het nut heeft om apart op de hostname te controleren.
Wat ik me wel afvraag: hoe spoof je dan het ip-adres wanneer je niet op hetzelfde netwerk zit? IP-adres zit niet in een van de headers, maar is een eigenschap van het onderliggende TCP/IP protocol. Hoe ga je ervoor zorgen dat wanneer jij iets via TCP/IP verstuurt met een 'foutief' IP-adres, het ook weer bij jouw aankomt? Het lijkt mij dat je dan tussen slachtoffer en server moet zitten om het verkeer op te vangen. Als je al zover bent, is het dan niet veel makkelijker om gewoon de login-request, het formuliertje waar je je gebruikersnaam & wachtwoord intikt af te vangen, of desnoods te vervalsen? Phishing? Dan heb je het wachtwoord, en kan je ongestoord doen wat je wilt. "Je beveiliging is zo sterk als de zwakste schakel" of zoiets..
Gewijzigd op 01/01/1970 01:00:00 door Jelmer -
Maar mijn vraag is ook, hoe kunnen mensen IP-adressen spoofen, want als dat zo is dan is het feitelijk onmogelijk om session/cookie-hijacking goed tegen te gaan omdat je dan eigenlijk alles wel kan faken. Maar alsnog wordt het moeilijk want je moet het IP, de host en de useragent(in mijn geval dan) weten om die dingen te kunnnen spoofen en daar kom je ook niet altijd zomaar achter. Dan zou je ook nog een de sessie moeten kunnen hijacken.
Maar ik hoor niemand "garbag collector" zeggen.
Als een sessie bijvoorbeeld een uur niet actief is dan wordt deze of door de "garbag collector" verwijderd of door een hit op die sessie. Ook kun je cookies aan maken die na het sluiten van de browser ongeldig worden. In de cookie staat alleen het sessie id (MD5 of SHA1 hash), meer niet.
Neem daarbij IP, browsernaam en eventueel x-forwarder controle en je hebt een redelijke veilig sessie systeem.
Met IP controle moet je oppassen dat je alleen de eerste 3 delen van het IPv4 controleert. Voor mensen met een dynamisch IP. Uiteraard geld dit ook voor IPv6.
Gewijzigd op 01/01/1970 01:00:00 door Martijn B
Maar ik weet niet of dit dan ook weer is te omzeilen.
Of bedoel je niet de cookie?
Als je naar een andere pagina gaan of je ververst de pagina na een x aantal seconden dan worden de sessie in de database veranderd, hierbij wordt de tijd ook opgeslagen. Als die tijd bijvoorbeeld een uur niet veranderd dan kun je de sessie niet meer gebruiken.
Gewijzigd op 01/01/1970 01:00:00 door Martijn B
Uiteraard loont het om een sessie te laten verlopen (tijd tussen de requests meten, groter dan een uur? Weg sessie) maar dat komt met een grote valkuil: Stel dat ik een post van 10 pagina's aan het typen ben, en ondertussen koffie haal. Het zou zomaar kunnen dat ik langer dan een uur nodig heb om die post te typen. Hoe frustrerend is het dan wanneer blijkt dat ik eerst opnieuw mag inloggen en dan weer opnieuw mijn post mag typen. (dit is een ervaring, helaas :/ ) Dus wanneer je sessie-verloop implementeert, of wat voor beveiliging dan ook waarbij een sessie kan verlopen en de gebruiker opnieuw in moet loggen, zorg er alsjeblieft voor dat daarna de gestarte actie gewoon compleet hervat wordt, en mijn post dus alsnog hier te lezen is. ... niet dat ik nu koffie heb gehaald
Martijn! schreef op 10.03.2008 18:35:
Ik heb even vlug door alle post heen gelezen.
Maar ik hoor niemand "garbag collector" zeggen.
Als een sessie bijvoorbeeld een uur niet actief is dan wordt deze of door de "garbag collector" verwijderd of door een hit op die sessie. Ook kun je cookies aan maken die na het sluiten van de browser ongeldig worden. In de cookie staat alleen het sessie id (MD5 of SHA1 hash), meer niet.
Neem daarbij IP, browsernaam en eventueel x-forwarder controle en je hebt een redelijke veilig sessie systeem.
Met IP controle moet je oppassen dat je alleen de eerste 3 delen van het IPv4 controleert. Voor mensen met een dynamisch IP. Uiteraard geld dit ook voor IPv6.
Maar ik hoor niemand "garbag collector" zeggen.
Als een sessie bijvoorbeeld een uur niet actief is dan wordt deze of door de "garbag collector" verwijderd of door een hit op die sessie. Ook kun je cookies aan maken die na het sluiten van de browser ongeldig worden. In de cookie staat alleen het sessie id (MD5 of SHA1 hash), meer niet.
Neem daarbij IP, browsernaam en eventueel x-forwarder controle en je hebt een redelijke veilig sessie systeem.
Met IP controle moet je oppassen dat je alleen de eerste 3 delen van het IPv4 controleert. Voor mensen met een dynamisch IP. Uiteraard geld dit ook voor IPv6.
Dit lijkt me dan weer minder veilig omdat je dan maar een deel van het IP hebt...
Het laten verlopen van sessie's is een mogelijkheid maar ik zou dat alleen doen bij website's waar dat echt nodig is of waar de bezoeker er weinig last van heeft. Ik neem even als voorbeeld een bank, daar is het i.m.o. heel goed dat sessie's verlopen. Bij communities e.d. lijkt het me dan weer minder geschikt.
Gewijzigd op 01/01/1970 01:00:00 door Gebruiker PHP
thx voor de info het zit nu in mijn nieuwste project ingebouwd.
en dan een SSL certificaat erop. en dan is het erg veilig.
Ivo van B. schreef op 10.03.2008 19:14:
Dit lijkt me dan weer minder veilig omdat je dan maar een deel van het IP hebt...
Het laten verlopen van sessie's is een mogelijkheid maar ik zou dat alleen doen bij website's waar dat echt nodig is of waar de bezoeker er weinig last van heeft. Ik neem even als voorbeeld een bank, daar is het i.m.o. heel goed dat sessie's verlopen. Bij communities e.d. lijkt het me dan weer minder geschikt.
Martijn! schreef op 10.03.2008 18:35:
Ik heb even vlug door alle post heen gelezen.
Maar ik hoor niemand "garbag collector" zeggen.
Als een sessie bijvoorbeeld een uur niet actief is dan wordt deze of door de "garbag collector" verwijderd of door een hit op die sessie. Ook kun je cookies aan maken die na het sluiten van de browser ongeldig worden. In de cookie staat alleen het sessie id (MD5 of SHA1 hash), meer niet.
Neem daarbij IP, browsernaam en eventueel x-forwarder controle en je hebt een redelijke veilig sessie systeem.
Met IP controle moet je oppassen dat je alleen de eerste 3 delen van het IPv4 controleert. Voor mensen met een dynamisch IP. Uiteraard geld dit ook voor IPv6.
Maar ik hoor niemand "garbag collector" zeggen.
Als een sessie bijvoorbeeld een uur niet actief is dan wordt deze of door de "garbag collector" verwijderd of door een hit op die sessie. Ook kun je cookies aan maken die na het sluiten van de browser ongeldig worden. In de cookie staat alleen het sessie id (MD5 of SHA1 hash), meer niet.
Neem daarbij IP, browsernaam en eventueel x-forwarder controle en je hebt een redelijke veilig sessie systeem.
Met IP controle moet je oppassen dat je alleen de eerste 3 delen van het IPv4 controleert. Voor mensen met een dynamisch IP. Uiteraard geld dit ook voor IPv6.
Dit lijkt me dan weer minder veilig omdat je dan maar een deel van het IP hebt...
Het laten verlopen van sessie's is een mogelijkheid maar ik zou dat alleen doen bij website's waar dat echt nodig is of waar de bezoeker er weinig last van heeft. Ik neem even als voorbeeld een bank, daar is het i.m.o. heel goed dat sessie's verlopen. Bij communities e.d. lijkt het me dan weer minder geschikt.
idd, dan zou theoretisch gezien iedereen die bij je provider op hetzelfde subnet zit jou sessie kunnen overnemen als ze door de rest van de controles heen komen. Als je op publiek IP checkt is dit alleen nog maar in je eigen netwerk, wat de kans op hacken toch al weer verkleint.
dennis schreef op 30.05.2008 14:30:
ik zie mensen hier wel de hele tijd over het vervalsen van deze data en aftappen met wireshark maar die "Fingerprint" is bijna onmogelijk te kraken als de hacker op een totaal andere kant van het internet zit. en dan nog je moet je mensen van je kantoor/bedrijf/collega's toch wel vertrouwen. dat die niet wiresharken????
Ik denk dat het juist je collega's zullen zijn die iets simpels als Session Fixation zullen proberen. Het is vrij simpel, ze weten genoeg info van je (websites, gebruikersnamen, wanneer je bent ingelogd) die je nodig hebt, en het is een hele gemakkelijke manier van een flauw geintje uithalen. Aanvallen van de andere kant van de wereld zijn veel anoniemer, en lijken mij meer gericht op veel gebruikers tegelijkertijd. Ik denk dat je vanaf veraf veel eerder een aanval als Cross Site Scripting of Phishing kan verwachten. Daar heb je hele groepen gebruikers tegelijkertijd mee.