Sessies
Wat vinden jullie nou? Wat is het veiligst? Hoe los je het op? Wat is de oplossing?
Ik praat over session highjacking.
Wat sla je op in een database enzo?
Bedankt :)
.kneH
Ik raad verder altijd het gebruik van SSL aan, dat maakt het ook weer wat lastiger. Er zijn echter mensen die deze investering, 100 euro als ik het goed heb, al te veel vinden. Tja, dan moet je niet gaan zeuren wanneer het fout gaat.
Vergelijken op ip-adres kan wel problemen opleveren met AOL-klanten. Bij mijn weten zijn daar nog geen klachten over gekomen, maar dat ligt waarschijnlijk aan de doelgroepen. En een portie geluk.
Code (php)
1
2
3
2
3
<?php
session_name ( sha1 ( 'dsfw%^2f' . IP . 'f#4D\'' . $_SERVER [ 'USER_AGENT' ] . '"\\@aF' ) );
?>
session_name ( sha1 ( 'dsfw%^2f' . IP . 'f#4D\'' . $_SERVER [ 'USER_AGENT' ] . '"\\@aF' ) );
?>
Ieder systeem heeft zijn eigen database en daar zit ook een eigen sessie_handler in. Het is dus niet mogelijk om via site A sessies van site B te bemachtigen waarmee je vervolgens op site B kunt gaan lopen kloten. Daarnaast heeft iedere database zijn eigen database-user voor de sessies en is alles met GRANT goed afgeschemd. Er kan niemand anders dan sessie_handler in dit deel van de database komen, net zo min als dat de sessie_handler in de rest van de database kan komen.
Het is vooral de database die de veiligheid regelt. Ik gebruik hiervoor, bij voorkeur, PostgreSQL. Dan kun je met schema's werken en eenvoudig het veiligheidsniveau wat hoger leggen dan met MySQL mogelijk is.
Oké er zijn een aantal dingen in je bericht die ik niet snap.Hoe sla je de hash op in de database? Met welke extra gegevens? Zet je in de sessie een user_id, en sla je in de tabel users op welk sessie id hierbij hoort? Dus bijvoorbeeld: "pietje logt in, pietje heeft gebruikersid 4. Zodra pietje op de loginknop drukt, wordt de hash van ip en user-agent opgeslagen in de tabel users. Bij elke volgende page view wordt gekeken wat de hash is van de gebruiker met gebruikersid $_SESSEION [ 'user_id' ], en als die hetzelfde is als de hash van IP en $_SERVER [ 'USER_AGENT' ] dan klopt het. Als het niet klopt, dan maak je de sessie leeg, zodat de gebruiker uitgelogd is."Klopt dat? Is dat ook alles dat jij gebruikt?Wat bedoel je steeds met sessie_handler?Wat is GRANT?Bedankt in ieder geval al!
Hier vind je uitleg hoe je zelf een sessie_handler schrijft (PHP 4). De sessies worden hier niet meer als bestand op schijf weggeschreven, maar keurig in een database weggezet. Dit maakt de boel flexibeler. Het voorbeeld beschrijft MySQL, maar je kunt dit uiteraard ook in een andere database doen. Zo gebruik ik dus PostgreSQL, dat biedt nog net wat meer mogelijkheden.
Jouw verhaal van de hash klopt geloof ik wel. Ga er eens mee stoeien, daar leer je het meeste van.
Met GRANT kun je in de database instellen wat een bepaalde database-user (dat is dus niet de website bezoeker, al zou die natuurlijk ook als database-user bekend kunnen zijn) allemaal mag uitspoken. Ik gebruik in PostgreSQL in iedere database een schema genaamd 'sessions'. Er is slechts 1 user die hier in mag komen: 'session_handler'. Deze mag echter niet in de rest van de database komen, de overige schema's zijn verboden terrein.
Wanneer je de users en GRANT goed gebruikt, kun je zelfs een database opzetten die bij SQL-injection nauwelijks problemen zal krijgen. Ik hoef bv. nooit bang te zijn dat iemand een record verwijderd, alleen de DBA mag verwijderen. Dit geldt ook voor het aanmaken en verwijderen van tabellen, kolommen, indexen, etc. etc., dat kan alleen door de DBA worden gedaan. Zolang iemand niet kan inloggen als DBA, kun je dus alleen data toevoegen en updaten (wat met constraints ook weer aardig is beschermd).
De DBA mag overigens alleen via zijn eigen ip-adres en alleen via SSL de database beheren, ook dat is goed dichtgespijkerd.
GRANT is een hele belangrijke functie in een database!
Jouw verhaal van de hash klopt geloof ik wel. Ga er eens mee stoeien, daar leer je het meeste van.
Met GRANT kun je in de database instellen wat een bepaalde database-user (dat is dus niet de website bezoeker, al zou die natuurlijk ook als database-user bekend kunnen zijn) allemaal mag uitspoken. Ik gebruik in PostgreSQL in iedere database een schema genaamd 'sessions'. Er is slechts 1 user die hier in mag komen: 'session_handler'. Deze mag echter niet in de rest van de database komen, de overige schema's zijn verboden terrein.
Wanneer je de users en GRANT goed gebruikt, kun je zelfs een database opzetten die bij SQL-injection nauwelijks problemen zal krijgen. Ik hoef bv. nooit bang te zijn dat iemand een record verwijderd, alleen de DBA mag verwijderen. Dit geldt ook voor het aanmaken en verwijderen van tabellen, kolommen, indexen, etc. etc., dat kan alleen door de DBA worden gedaan. Zolang iemand niet kan inloggen als DBA, kun je dus alleen data toevoegen en updaten (wat met constraints ook weer aardig is beschermd).
De DBA mag overigens alleen via zijn eigen ip-adres en alleen via SSL de database beheren, ook dat is goed dichtgespijkerd.
GRANT is een hele belangrijke functie in een database!
Edit:
Ik snap die pagina, alleen het garbage collecten niet. In de klasse wordt dan elke sessie die ouder is dan minuten verwijderd. Waarom is dat?
Gewijzigd op 01/01/1970 01:00:00 door Henk
bump
Quote:
Omdat deze sessies zijn vervallen, ze zijn ouder dan [jouw_instelling] minuten.In de klasse wordt dan elke sessie die ouder is dan minuten verwijderd. Waarom is dat?
Je zou ze kunnen laten staan, afhankelijk van de queries die jij gebruikt, staan ze niemand in de weg. Maar, de tabel met sessies zal vrij snel vele miljoenen records bevatten. Dat is op zich niet zo'n probleem, maar om de records terug te vinden moet er ook een fraaie index worden gebruikt. Ook deze neemt natuurlijk ruimte in beslag. Uiteindelijk zal de boel toch steeds langzamer worden en dat wil je zeker met een sessie niet hebben. Je gebruikt deze te veel om daar onnodig veel tijd aan te besteden.
Vandaar dat opschonen wenselijk is.
Oké, maar als je het instelt op 5 minuten betekent het dus dat je na 5 minuten een topic te hebben gelezen je uitgelogd bent?
5 minuten is voor de meeste toepassing dan ook te weinig. Een half uur is vrij normaal, maar 15 minuten heb ik ook wel voorbij zien komen. Het is afhankelijk van de benodigde beveiliging hoelang jij de sessies in leven wilt houden. Hoog niveau beveiliging, dan een korte levensduur. Laag niveau, dan mag een sessie langer blijven leven.
Edit: Ben een lijstje met eisen aan het opstellen voor de instellingen van een nieuwe webserver en kom in de PHP manual dit tegen: link. Echt iets voor mij! Heb het dan ook al doorgegeven aan de technische jongens dat ik dit er op wil hebben. ;)
Gewijzigd op 01/01/1970 01:00:00 door Frank -
Wat ik nu trouwens bovenaan elke pagina doe:
Code (php)
Code (php)
Klopt dat idee? :)
bump
bump
http://phphulp.nl/forum/showtopic.php?cat=1&id=37926&page=
Vorige week geschreven, staat hoe ik het opgelost heb.
Vorige week geschreven, staat hoe ik het opgelost heb.
Danks. Eens lezen.
Niet geheel anders dan pgFrank Arjannetje.
Ik heb wel wat beters te doen dan al die tekst te lezen.
Toch vind ik de samenvatting van Arjan en zijn verhaal erboven wel fijn om te lezen en gelezen te hebben Kalletje.
Zo Arjan kost je nieuwe programmeertaal zoveel tijd dan?
Ik vind dat je flauw doet.