session id
Een session id bestaat uit 32 karakters. Via de functie session_id kun je de id van een sessie aanpassen. En nu zat ik me ineens af te vragen... is het slim om zo'n id te SALTen? Dus dat je er een paar karakters aan vastplakt. Ik kan me voorstellen dat iemand die een sessie wil kapen dit probeert te doen door telkens met 32 karakters een id te genereren. Echter, als mijn session id geen 32 maar bijv. 35 karakters is, zal hem dat nooit lukken. Wel of geen slim idee?
Beter lijkt me om de session te controleren. Bijvoorbeeld zo:
http://www.pfz.nl/wiki/session-hijacking/
Bart V B op 04/10/2013 01:48:36:
Dat lijkt me een beetje overbodig.
Beter lijkt me om de session te controleren. Bijvoorbeeld zo:
http://www.pfz.nl/wiki/session-hijacking/
Beter lijkt me om de session te controleren. Bijvoorbeeld zo:
http://www.pfz.nl/wiki/session-hijacking/
Het voorbeeld van PFZ gaat uit van het IP-adres. Dat heeft twee grote nadelen:
• Het sluit eerlijke gebruikers met een veranderend IP-adres uit, waaronder veel mobiele gebruikers en gebruikers van bepaalde providers.
• Het verhindert session hijacking niet wanneer de hacker in hetzelfde internetcafé, hetzelfde hotel, hetzelfde bedrijfsverzamelgebouw, enzovoort zit.
Je kunt beter vier andere maatregelen nemen:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<?php
// (1) Altijd een HTTP-only sessiecookie gebruiken
ini_set('session.cookie_httponly', '1');
// (2a) Sessienaam PHPSESSID van PHP vervangen door JSESSIONID van JSP
session_name('JSESSIONID');
// (2b) Deze server gebruikt geen PHP op Apache
header('Server: Sun-Java-System-Web-Server/7.0', true);
header('X-Powered-By: JSP/2.1', true);
// Controleren of de extensie hash bestaat
if (function_exists('hash_algos')) {
// (3a) Sessie-ID versleutelen met 512-bits SHA-2 (sha512)
ini_set('session.hash_function', 'sha512');
} else {
// (3b) Sessie-ID versleutelen met 128-bits SHA-1 in plaats van MD5
ini_set('session.hash_function', '1');
}
// Sessie starten of hervatten
session_start();
// (4) Steeds een nieuwe sessie-ID genereren
session_regenerate_id(true);
?>
// (1) Altijd een HTTP-only sessiecookie gebruiken
ini_set('session.cookie_httponly', '1');
// (2a) Sessienaam PHPSESSID van PHP vervangen door JSESSIONID van JSP
session_name('JSESSIONID');
// (2b) Deze server gebruikt geen PHP op Apache
header('Server: Sun-Java-System-Web-Server/7.0', true);
header('X-Powered-By: JSP/2.1', true);
// Controleren of de extensie hash bestaat
if (function_exists('hash_algos')) {
// (3a) Sessie-ID versleutelen met 512-bits SHA-2 (sha512)
ini_set('session.hash_function', 'sha512');
} else {
// (3b) Sessie-ID versleutelen met 128-bits SHA-1 in plaats van MD5
ini_set('session.hash_function', '1');
}
// Sessie starten of hervatten
session_start();
// (4) Steeds een nieuwe sessie-ID genereren
session_regenerate_id(true);
?>
Verder nog:
(5) formulieren beveiligen met een token;
(6) inloggen altijd combineren met uitloggen;
(7) SSL gebruiken in kritieke situaties.
(Ik heb een eigen VSP en geen shared server. Maakt dat nog iets uit?)
Als je gebruikers laat inloggen, moet je ze een mogelijkheid bieden om uit te loggen. Bij het uitloggen vernietig je vervolgens de sessie. Zó kan die vervolgens niet meer worden misbruikt.
Session hijacking kan een gebruiker die online is soms zelf opmerken. En nog belangrijker: je kunt interacties met een live gebruiker benutten om de sessie beter te beveiligen. Maar als de gebruiker eenmaal vertrokken is, heb je alleen nog de hacker/cracker met de gekaapte sessie. Daarom dus: uitloggen is einde sessie.
Dat verhullen dat het PHP is, vind ik wel grappig. Maar doe jij dat dan standaard bij alle output die jij terug naar de cliënt stuurt?
Overigens, dit kun je ook op een andere manier doen! Je kunt de server signature uitschakelen, evenals de server tokens en ook php expose kun je uitzetten. Het enige wat je dan nog kunt zien is dat je op een Apache server draait. Ik weet niet of je dit wist, maar dit lijkt me eigenlijk een betere methode dan "valse" headers mee te sturen.
Alleen kun je er wel over discussiëren wat beter is: de gebruikte software verbergen of erover liegen? Als je alleen dit ziet, gaat de onverlaat op zoek naar je technologie:
Server: Apache
Maar als je bijvoorbeeld dit meldt, zet je de inbreker op het verkeerde been:
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Kan de leukerd fijn op zoek naar lekken in IIS en ASP.NET.
Wel grappig inderdaad. Maar kan dat verder geen kwaad, dat je een header meestuurt die niet klopt, of maakt dat helemaal niks uit?
Ozzie PHP op 04/10/2013 12:43:42:
Maar kan dat verder geen kwaad, dat je een header meestuurt die niet klopt, of maakt dat helemaal niks uit?
Goede vraag, ik weet het eerlijk gezegd niet, maar daarom stuur ik in dergelijke gevallen voor de zekerheid bestaande headers mee die door bekende, grote sites worden gebruikt.
Belangrijker is een lange sessie-ID die je voortdurend verandert. Je eerste ingeving om er een salt aan toe te voegen was al goed, alleen kan dat gewoon met SHA-2.
Ozzie PHP op 04/10/2013 13:05:30:
Kun je daar een voorbeeld van geven hoe ik dan de session name zou moeten maken met SHA-2. En is SHA-2 hier het beste voor? (volgens mij werkt de standaard manier met MD5?)
Niet de name maar de id bedoel je denk ik? Staat in mijn eerdere voorbeeld: 3a is 512-bits SHA-2 en 3b is het alternatief dat altijd werkt, namelijk MD5 vervangen door SHA-1.
En wat is het voordeel van sha-2 boven sha-1. En hoe voeg je dan een salt toe?
Voeg daaraan nog session_regenerate_id() toe om deze 512-bits hash voortdurend te veranderen en het is al bijna waterdicht. Je krijgt dan dit:
1. Gebruiker A krijgt sessie-ID 1.
2. Kaper B verandert die in sessie-ID 2.
3. Gebruiker A keert terug met sessie-ID 1, maar die is inmiddels ongeldig.
Hierna kan A niets meer en kun je bijvoorbeeld A dwingen opnieuw in te loggen. Probleem is dan alleen nog dat kaper B een geldige sessie heeft en dus de kaping is geslaagd. Dit kun je bijvoorbeeld voorkomen door beide sessie-ID's op te slaan in een database: bij stap 3 vernietig je vervolgens zowel sessie 1 als sessie 2.
Je ziet hier overigens ook wáárom sessies makkelijker zijn te beveiligen met een live gebruiker: dan verandert de (geldige) sessie-ID voortdurend.
Gewijzigd op 04/10/2013 13:47:19 door Ward van der Put
Stel nu dat je het anders zou doen en je zou GEEN gebruik maken van session_regenerate_id(). In plaats daarvan sla je in de database het sessie-id op + een extra code. Bij iedere pagina-aannroep controleer je de code. Een hacker heeft die code natuurlijk niet. Stel dat ie dan toch per ongeluk het juiste id "raadt" dan klopt de code niet en wordt de complete sessie vernietigd. Is dat een idee?
Dan krijg je dit:
1. Gebruiker A krijgt sessie-ID 1 en hidden-input met token x.
2. Kaper B kaapt sessie-ID 1 maar token y.
3. Gebruiker A keert terug met sessie-ID 1 en inmiddels ongeldig token x: vernietig sessie 1.
En om je eerste vraag te beantwoorden: de standaardbeveiliging van PHP is inderdaad ontoereikend, vooral bij het verwerken van persoonsgegevens en financiële transacties.
Wat versta jij precies onder "hidden input"?
Zou ik niet gewoon een cookie kunnen setten met een geheime code en die opslaan in de database, of desnoods in de sessie zelf? En dan zodra een pagina wordt geladen kijken of de geheime code uit de database of sessie overeenkomt met de code in de cookie?
Ozzie PHP op 04/10/2013 14:11:23:
Wat versta jij precies onder "hidden input"?
<input type="hidden" name="token" value="...">
Ozzie PHP op 04/10/2013 14:11:23:
Zou ik niet gewoon een cookie kunnen setten met een geheime code en die opslaan in de database, of desnoods in de sessie zelf? En dan zodra een pagina wordt geladen kijken of de geheime code uit de database of sessie overeenkomt met de code in de cookie?
Je hoeft het token niet eens op te slaan in een database: je kunt het gewoon opslaan in de sessie. Zodra je een respons krijgt met het token (in een cookie via $_COOKIE of een formulier via $_POST) kijk je of dat geretourneerde token overeenkomt met het token in de sessie. Zo nee, dan vernietig je de sessie. Zo ja, dan ga je verder, maar genereer je een nieuw token.
Client en server wisselen dus voortdurend veranderende tokens uit. Komt daar een extra client bij, via session hijacking, dan heeft één van de clients een ongeldig token en kun je de boel dus op slot gooien.
Gewijzigd op 04/10/2013 14:19:53 door Ward van der Put
Ozzie PHP op 04/10/2013 14:11:23:
Ah, oké thanks. Slecht eigenlijk dat de standaardbeveiliging ontoereikend is!
Wat versta jij precies onder "hidden input"?
Zou ik niet gewoon een cookie kunnen setten met een geheime code en die opslaan in de database, of desnoods in de sessie zelf? En dan zodra een pagina wordt geladen kijken of de geheime code uit de database of sessie overeenkomt met de code in de cookie?
Wat versta jij precies onder "hidden input"?
Zou ik niet gewoon een cookie kunnen setten met een geheime code en die opslaan in de database, of desnoods in de sessie zelf? En dan zodra een pagina wordt geladen kijken of de geheime code uit de database of sessie overeenkomt met de code in de cookie?
Je hebt helemaal niet zoiets als "standaardbeveiliging". Het gaat allemaal om de programmeur. Een slechte programmeur kan altijd beveiligingslekken veroorzaken, overal, en een goede programmeur zorgt altijd dat hij het goed dichttimmert. Helaas is php zo'n makkelijke taal dat het door veel noobies gebruikt wordt, en die hebben de ballen verstand van echt programmeren.
En dat is ook de reden waarom er altijd zo lacherig over php wordt gedaan. Met hidden input bedoelt hij csrf protectie
Gewijzigd op 04/10/2013 14:22:59 door NOLot -
Bij iedere nieuwe request / nieuwe pagina vernieuw je dus de token. Is dat wat je bedoelt? En de sessie-id blijft dan gewoon hetzelfde. Correct?
Maar ik moet dan wel een cookie op de client opslaan toch? Waarin ik telkens die nieuwe code opsla?