Het www is ongelooflijk gegroeid sinds het ontstaan. Steeds meer en meer mensen beginnen uit te zoeken hoe ze webpagina’s moeten maken. De ene al wat geavanceerder (PHP, MySQL, .NET, …) dan de andere (HTML, CSS, …). (En dan heb je nog de soort die denkt dat hij een website heeft gebouwd als ie een blog of MySpace heeft opgezet…)

Anyway, dit betoog gaat over de geavanceerdere soort. Want het ultieme uitdaging waar ze ooit mee geconfronteerd worden is veiligheid. Tenminste, als ze dit ook zien als een uitdaging. Sta me toe dit even uit te leggen.

Vele scripters denken al gauw dat hun pagina veilig is als ze 2 vakjes hebben voor een username en password en een knopje om in te loggen. Zo staan er ook duizenden scripts op het internet. De uitdaging is quasi nihil (tenzij je nog niet kan werken met forms). Het enige wat ze over het hoofd hebben gezien is net waar het om gaat: veiligheid!

Nu weten we wel allemaal dat veiligheid nog weinig voorstelt dezer tijden, maar met het voorbeeld hierboven zou je dat niet mogen verbazen. Toch is dit – in mijn opinie – de verkeerde mentaliteit. Het gevoel van veiligheid is er misschien wel, maar de veiligheid is er juist helemaal niet! Nergens eigenlijk. Laatst las ik (een gerucht) dat de hele UAC van Windows Vista maar een hoop extra irritante venstertjes zou zijn. Het hele systeem is zo lek alsof je soep zou eten met een vork.

Even later dook dan nog een demo (http://youtube.com/watch?v=cOxWuKL2hWI) op van een persoon die met een Linux LiveCD het loginscherm van Vista kan omzeilen. Je krijgt gewoon de desktop op je loginscherm, en opgestart is Windows. Zielig eigenlijk. Zeker als je dan 2 posts verder leest dat de Kernel van de volgende Windows versie niet gewijzigd zal worden. Bye bye veiligheid, bye bye prestaties!

Toch zou ik graag bij het maken van mijn eigen webtoepassingen mijn gebruikers een zo hoog mogelijke veiligheid willen verlenen. Hier is een voorbeeld van hoe het NIET moet (een van die debiele scriptjes op internet dus, met allerlei tirlantijntjes, maar geen enkele vorm van veiligheid).

Stel je een pagina voor met 2 vakjes: username en password. De verwerking gaat als volgt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<?php
require_once("config.php");
 
$username = $_POST['username'];
$pass = md5($_POST['password']);
$sql = "SELECT * FROM users WHERE username = $username AND password = $password";
$query = mysql_query($sql);
 
if(mysql_num_rows($query)) == 1)
{
    header('Location: private.php');
}
else
{
    header('Location: public.php');
}
?>

Wat gebeurt er nu? Het script controleert of er in de database een unieke gebruiker zit met deze username-password combinatie en als dat zo is, wordt deze doorverwezen naar de private pagina, anders komt hij terug op het publieke gedeelte. Buiten het feit dat dit script niet SQL Injection safe is, is er nog geen sprake van veiligheid.

Stel, ik ben een hacker. Ik zie een login. Wat doe ik? Ik typ gewoon in de adresbalk “www.[het-domein].[de-extensie]/[de-folder]/private.php”. Wat gebeurt er? Ik kom in het privaat gedeelte zonder ook maar iets van een wachtwoord in te moeten geven. Met andere woorden, er is wel een deur, maar geen muur.

De bedoeling is dus een veilig script te maken. Het is noodzakelijk om op elke pagina te controleren of de gebruiker wel toegang heeft tot deze pagina (en dus niet er een pagina voor zetten, die controleert of je wel binnen mag). Dit moet lietst zo kort mogelijk.

validLogin() or die('No acces');

of

validLogin() or die(header('Location: public.php'));

Dit is hoe ik beveiliging zie. Ik weet ook wel dat er nog steeds achterdeurtjes zijn dan, maar dit garandeert wel meer veiligheid dan het vorige script.

De geïnteresseerde lezer wil uiteraard weten hoe de methode validLogin() dan moet ingevuld worden. Ik had gedacht aan het volgende.

Bij het inloggen wordt een session aangemaakt. Deze houdt de username, rechten, sessionid (standaard), IP-adres bij van de client. Bij het bekijken van een beveiligde pagina worden de rechten (voor het bekijken van de pagina) vergeleken met de rechten in de sessie en wordt het IP-adres gecontroleerd. Als het IP-adres niet hetzelfde is als het IP-adres waar mee ingelogd is (tijdens dezelfde sessie kan/mag de gebruiker niet van IP adres veranderen), wordt de gebruiker automatisch uitgelogd.

Voor het geval dat men de login wil opslaan in cookies zou ik het volgende doen. Als men een cookie opslaat, wordt een hash gemaakt van allerlei gegevens, en opgeslagen in de database in de rij van de gebruiker. Dezelfde hash wordt opgeslagen in de cookie. Met andere woorden heeft de gebruiker een passphrase en de database heeft er een om deze mee te vergelijken.

Natuurlijk ben ik geen veiligheidexpert, dus er zijn zeker verbeteringen mogelijk aan dit script. Bijvoorbeeld: de paswoorden laten hashen (MD5, Sha-1) met Javascript op de computer van de client, om zo de verbinding zo veilig mogelijk te maken, dat er geen paswoorden doorgegeven worden op een onveilige verbinding. Verbeteringen mag je dan ook steeds posten in een comment!

Ach, misschien moet ik maar ineens een RSA methode gaan uitvinden voor weblogins. Bij registreren krijg je dan enkel een deel van de sleutel, en het andere deel van de sleutel zit in de database. Daar ga ik mijn eindwerk nog eens wat research naar doen (na de examens).