Inloggen
Ik heb altijd gebruik gemaakt van sessions als ik een inlogsysteem maakte, maar aangezien ik php.ini niet kan aanpassen, kan ik de lengte van de sessions niet beïnvloeden.
Ik heb rondgezocht op internet en daar staat dat je in plaats van sessions ook gegevens in de database kon zetten, en dat kopellen aan een cookie, dus heb ik het volgende gemaakt:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<?php
$length = 100;
$characters = '0123456789abcdefghijklmnopqrstuvwxyz';
for ($i = 0; $i < $length; $i++)
{
$hash .= $characters[mt_rand(0, strlen($characters))];
}
$select = 'SELECT ID FROM users WHERE email = "' . $mysqli->real_escape_string($_POST['email']) . '" AND password = "' . $mysqli->real_escape_string($password) . '" ';
$query = $mysqli->query($select);
$qUser = $query->fetch_object();
$insert = 'INSERT INTO user_sessions (ID, userID, IP) VALUES ("' . $hash . '", ' . $qUser->ID . ', "' . $_SERVER['REMOTE_ADDR'] . '")';
$mysqli->query($insert);
setcookie('hash', $hash, time() + 3600, '/');
?>
$length = 100;
$characters = '0123456789abcdefghijklmnopqrstuvwxyz';
for ($i = 0; $i < $length; $i++)
{
$hash .= $characters[mt_rand(0, strlen($characters))];
}
$select = 'SELECT ID FROM users WHERE email = "' . $mysqli->real_escape_string($_POST['email']) . '" AND password = "' . $mysqli->real_escape_string($password) . '" ';
$query = $mysqli->query($select);
$qUser = $query->fetch_object();
$insert = 'INSERT INTO user_sessions (ID, userID, IP) VALUES ("' . $hash . '", ' . $qUser->ID . ', "' . $_SERVER['REMOTE_ADDR'] . '")';
$mysqli->query($insert);
setcookie('hash', $hash, time() + 3600, '/');
?>
En dan op elke pagina controleren of de cookie 'hash' in de database voorkomt en het IP dat daar staat opgeslagen hetzelfde is als het jouwe.
Maar ik heb nu geen enkel idee of dit wel veilig genoeg is.
Zijn er nog dingen die ik moet verbeteren, of zijn er nog andere manieren waarop je een goed, veilig inlogsysteem kunt maken (het liefst zonder sessions).
Alvast bedankt!
Gewijzigd op 10/07/2012 17:01:40 door Lord Gaga
Punt 2 is dat je even moet kijken naar hoe je het IP ophaalt. Als gebruikers achter een proxy zitten dan zal $_SERVER['REMOTE_ADDR'] niet het juiste IP adres geven. Check altijd of er een waarde in $_SERVER['HTTP_X_FORWARDED_FOR'] zit. Zo ja, dan is de kans groot dat dat het juiste IP adres is (hoewel je dat niet kan garanderen).
Klopt dit? (zie http://php.net/manual/en/reserved.variables.server.php )
Quote:
If you are serving from behind a proxy server, you will almost certainly save time by looking at what these $_SERVER variables do on your machine behind the proxy.
$_SERVER['HTTP_X_FORWARDED_FOR'] in place of $_SERVER['REMOTE_ADDR']
$_SERVER['HTTP_X_FORWARDED_HOST'] and
$_SERVER['HTTP_X_FORWARDED_SERVER'] in place of (at least in our case,) $_SERVER['SERVER_NAME']
$_SERVER['HTTP_X_FORWARDED_FOR'] in place of $_SERVER['REMOTE_ADDR']
$_SERVER['HTTP_X_FORWARDED_HOST'] and
$_SERVER['HTTP_X_FORWARDED_SERVER'] in place of (at least in our case,) $_SERVER['SERVER_NAME']
Op php.net zie ik die index niet in de lijst staan; juist 1 keer, bij dit comment dat ik hier quote
Erwin H op 10/07/2012 17:17:32:
Punt 1 wat je zou moeten aanpassen is het feit dat je het password niet encrypted in je database hebt staan. Dat is altijd een slecht idee.
Punt 2 is dat je even moet kijken naar hoe je het IP ophaalt. Als gebruikers achter een proxy zitten dan zal $_SERVER['REMOTE_ADDR'] niet het juiste IP adres geven. Check altijd of er een waarde in $_SERVER['HTTP_X_FORWARDED_FOR'] zit. Zo ja, dan is de kans groot dat dat het juiste IP adres is (hoewel je dat niet kan garanderen).
Punt 2 is dat je even moet kijken naar hoe je het IP ophaalt. Als gebruikers achter een proxy zitten dan zal $_SERVER['REMOTE_ADDR'] niet het juiste IP adres geven. Check altijd of er een waarde in $_SERVER['HTTP_X_FORWARDED_FOR'] zit. Zo ja, dan is de kans groot dat dat het juiste IP adres is (hoewel je dat niet kan garanderen).
Het wachtwoord wordt encrypted opgeslagen in de variabel $password.
En is deze check goed genoeg voor het IP Adres?:
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
if(isset($_SERVER['HTTP_X_FORWARDED_FOR']))
{
$IP = $_SERVER['HTTP_X_FORWARDED_FOR'];
}
else
{
$IP = $_SERVER['REMOTE_ADDR'];
}
{
$IP = $_SERVER['HTTP_X_FORWARDED_FOR'];
}
else
{
$IP = $_SERVER['REMOTE_ADDR'];
}
Gewijzigd op 10/07/2012 18:07:46 door Lord Gaga
Avicka Avickum op 10/07/2012 18:05:26:
Het wachtwoord wordt encrypted opgeslagen in de variabel $password.
En is deze check goed genoeg voor het IP Adres?:
En is deze check goed genoeg voor het IP Adres?:
Dan is punt 1 inderdaad niet meer van toepassing.
Voor punt 2 is dat inderdaad de betere manier.
Verder zou je nog kunnen denken aan een extra cookie met een oplopend nummer die je ook nog in je db zet (wellicht het auto increment id van je sessie record). Alleen of dat echt helpt is de vraag. Als een hacker het ene cookie kan vinden, dan kan hij vast de ander ook vinden. Het helpt alleen als een hacker op de gok een hash in zijn cookie zet en toevallig een goede hash kiest.
Erwin H op 10/07/2012 18:45:51:
Wat ik er nog aan toe zou voegen (hoewel je dat misschien al hebt, is niet te zien), is een kolom in de database met wanneer de laatste actie van de gebruiker was. Op die manier kan je een timeout erin bouwen zodat als de gebruiker niet uitlogt, de sessie toch op zeker moment wordt afgebroken. Niet alleen is dit handig voor gewone echte users, maar ook voor sessie hijacking.
Verder zou je nog kunnen denken aan een extra cookie met een oplopend nummer die je ook nog in je db zet (wellicht het auto increment id van je sessie record). Alleen of dat echt helpt is de vraag. Als een hacker het ene cookie kan vinden, dan kan hij vast de ander ook vinden. Het helpt alleen als een hacker op de gok een hash in zijn cookie zet en toevallig een goede hash kiest.
Verder zou je nog kunnen denken aan een extra cookie met een oplopend nummer die je ook nog in je db zet (wellicht het auto increment id van je sessie record). Alleen of dat echt helpt is de vraag. Als een hacker het ene cookie kan vinden, dan kan hij vast de ander ook vinden. Het helpt alleen als een hacker op de gok een hash in zijn cookie zet en toevallig een goede hash kiest.
De laatste actie ga ik er zo inzetten.
En sessie hijcking is toch dat je iemand anders 'session_id' overneemt in je cookie, zodat je op diegene zijn account bent ingelogd? (Want daarvoor sla ik ook het IP op, en controleer die)
Wat betreft het IP adres, ook dat is te 'vervalsen'. Als iemand dus een IP adres faked, maar niet binnen de time out periode probeert het sessie id te gebruiken, dan kan je met behulp van die time out de gebruiker uitloggen. Gebruikt de hacker het allemaal wel binnen de time out dan heb je er alsnog niets aan natuurlijk.