Deze website maakt gebruik van diensten van Google voor het tonen van advertenties en het bijhouden van bezoekersstatistieken. Google kan hiermee uw surfgedrag volgen. Zie voor meer informatie het privacybeleid van Google. Via Your Online Choices kunt u zich afmelden voor gepersonaliseerde advertenties. Deze melding verbergen.

30 Beveiliging

De beveiliging van je website is niet iets om lichtzinning over te doen. Dit hoofdstuk gaat in op de minimale technische voorzieningen die je zou moeten treffen wanneer je gebruikers laat inloggen op je website of anderzijds persoonsgegevens via je website verwerkt. Wanneer je persoonsgegevens verwerkt moet je volgens de Uitvoeringswet Algemene verordening gegevensbescherming ook nog niet-technische maatregelen treffen; daar gaat dit hoofdstuk niet over.

HTTPS

Wanneer je bezoekers via je website persoonlijke gegevens laat invullen of deze weergeeft, dan moet je er voor zorgen dat de verbinding tussen de computer van de bezoeker en de webserver versleuteld is. Persoonlijke gegevens moet je hier ruim zien. Naam, adres, woonplaats, telefoonnummer zijn logischerwijs persoonlijke gegevens. Maar ook een e-mailadres, een gebruikersnaam en een wachtwoord vallen er ook onder. Als je je bezoekers enkel met een gebruikersnaam en wachtwoord laat inloggen (en verder geen gegevens vraagt), dan nog moet je de verbinding versleutelen. Anders worden gebruikersnaam en wachtwoord namelijk als leesbare tekst over het internet gestuurd, waar deze zomaar onderschept kunnen worden.

De versleuteling regel je door middel van een SSL/TLS certificaat voor je domeinnaam. Je bezoekers kunnen je website dan via HTTPS in plaats van HTTP benaderen. De meeste webhosts bieden tegenwoording de mogelijk om (al dan niet tegen betaling) een beveiligingscertificaat voor je website aan te vragen en nemen je daarbij al het configuratiewerk uit handen.

Omleiden naar HTTPS

Waar je wel nog op moet letten is dat de bezoeker van je website zijn of haar gegevens ook alleen kan invullen wanneer de website via HTTPS bezocht wordt. Soms biedt je webhost de mogelijkheid om HTTPS af te dwingen. De website is dan sowieso niet via onversleuteld HTTP bereikbaar. Is die optie er niet, dan kun je bovenaan iedere pagina met een formulier een controle uitvoeren via PHP en indien nodig de bezoeker omleiden naar de beveiligde variant van de pagina. Hiervoor kun je gebruik maken van de server-variabelen uit hoofdstuk 16, in het bijzonder $_SERVER['HTTPS']. Deze is leeg of off wanneer geen HTTPS wordt gebruikt. Hiermee kun je de volgende controle doen:

<?php
//controleer of HTTPS niet wordt gebruikt
if (empty($_SERVER['HTTPS']) || ($_SERVER['HTTPS'] == 'off')) {
    
//geen HTTPS
}
?>

Wanneer er geen HTTPS wordt gebruikt, is het van belang om de bezoeker te verwijzen naar de versie met HTTPS. Dit kan door middel van een header-redirect in combinatie met de server-variabelen $_SERVER['SERVER_NAME'] en $_SERVER['REQUEST_URI']. Immers deze twee server-variabelen samen vormen de huidige URL (zonder protocol), dus daar hoeft alleen nog maar https:// voor. Dit geeft de volgende complete code die je bovenaan een pagina kunt plakken om HTTPS af te dwingen (bovenaan, want headers moeten worden gestuurd voordat enige pagina-inhoud naar de browser wordt gestuurd):

<?php
//controleer of HTTPS niet wordt gebruikt
if (empty($_SERVER['HTTPS']) || ($_SERVER['HTTPS'] == 'off')) {
    
//geen HTTPS
    
header('Location:https://' . $_SERVER['SERVER_NAME'] . '/' . $_SERVER['REQUEST_URI']);
    exit;
//stop het uitvoeren van de rest van het script
}
?>

(PS: er zijn nog andere manieren om HTTPS af te dwingen. Bijvoorbeeld via .htaccess. Dit boek gaat niet verder in op deze alternatieven, maar het loont zich om je er in te verdiepen wanneer je het afdwingen van HTTPS zelf moet oplossen als je webhost het niet voor je kan regelen. De hier geïllustreerde methode via PHP is eigenlijk de laatste oplossing als al het andere niet mogelijk is.)

Veilig omgaan met wachtwoorden

In dit boek zijn al enkele voorbeelden voorbij gekomen van een loginssyteem (zie hoofdstuk 11 en hoofdstuk 21). Omwille van de complexiteit is het verwerken van wachtwoorden daar bewust simpel gehouden. Te simpel. Hier gaan we dieper in op het verwerken van wachtwoorden en hoe je dit dan wel veilig kan doen.

Wat is er niet goed aan de eerdere voorbeelden?

In de voorbeelden van hoofdstuk 11 en hoofdstuk 21 is voorbij gegaan aan een paar zaken.

Allereerst moet een wachtwoord nooit in een cookie worden opgeslagen. Da's nog erger dan een wachtwoord op een Post-it® aan het beeldscherm plakken. Iedereen die toegang heeft tot de computer kan het wachtwoord lezen. Voor een Post-it® heb je op z'n minst nog fysieke toegang nodig, maar een cookie is potentieel ook via internet of een netwerk toegankelijk. Dat hoeven geen hackers te zijn, maar kan ook zomaar de werkgever van je bezoeker zijn wanneer een bedrijfscomputer wordt gebruikt.

Ook het gebruik van een eenvoudige hash is inmiddels lang en breed achterhaald. Daar waar die methode in 2001 nog veilig was, zijn tegenwoordig zo'n beetje alle gangbare hash-algoritmes gekraakt of alle combinaties uitgerekend en bestaan er "regenboogtabellen" (rainbow tables) om het oorspronkelijke wachtwoord op te zoeken als de hash bekend is. Daardoor is het opslaan van het gehashte wachtwoord in een cookie niet echt anders dan het in leesbare tekst opslaan van het wachtwoord. In plaats van het (gehashte) wachtwoord moet dus een andere sleutel worden opgeslagen in het cookie, welke ook op de server wordt bewaard. Deze sleutel moet bovendien geen relatie hebben met het wachtwoord en moeilijk te raden zijn.

Op de server moet een wachtwoord echter nog steeds "onleesbaar" worden opgeslagen. Hiervoor is een hash nog steeds de geëigende methode, maar vanwege de regenboogtabellen is het zaak om hier wat zout in te strooien. Letterlijk, want het toepassen van een salt is een bekende techniek om het gebruik van regenboogtabellen volledig onpraktische te maken. Het gebruik van een salt houdt in dat er aan ieder wachtwoord een willekeurige tekenreeks wordt toegevoegd voordat het wordt gehasht. Wanneer aan ieder wachtwoord een andere salt wordt toegevoegd, is een aanval via een regenboogtabel niet meer praktisch omdat voor iedere salt een andere regenboogtabel nodig is en het aantal mogelijke combinaties van wachtwoord, salt en hash te groot is geworden om deze allemaal vooraf te berekenen. Ter verduidelijking: we gaan wachtwoorden dus wel nog steeds hashen, maar enkel nog met een salt waardoor het weer veilig is.

Tot slot is het ook niet verstandig om de gebruikersnaam in een cookie op te slaan, want als de gebruikersnaam niet bekend is moet een kwaadwillende die eerst ook nog raden. In plaats daarvan is het beter om het unieke ID van een gebruiker in het cookie te bewaren, zoals dat in hoofdstuk 21 is gedaan. Het ID kan immers niet gebruikt worden om in te loggen.

Salt toepassen

Sinds PHP 5.5 bestaat er een speciale functie password_hash() om een wachtwoord te hashen, waarbij er automatisch een willekeurige salt wordt toegepast:

string password_hash ( string $password , int $algo [, array $options ] )

Als parameters geef je het wachtwoord op dat door de gebruiker is opgegeven en geef je aan welk algoritme gebruikt moet worden voor het berekenen van de hash. Als algoritme kan het beste PASSWORD_DEFAULT gebruikt worden. Hiermee krijg je automatisch het meest geschikte algoritme voor de gebruikte versie van PHP. Het resultaat van de functie is een combinatie van een code die het gebruikte hash-algoritme aangeeft, een willekeurige salt en de hash van het wachtwoord. Dit ziet er bijvoorbeeld als volgt uit: $2y$10$GJ.W8A08WPHdvMTn1zGYbetSakX2D/VslOtUKLiNsPvf/AUH4Q9Be. Het resultaat van de functie sla je op de server op (bijvoorbeeld in een database) in combinatie met de gebruikersnaam. Het leesbare wachtwoord zoals dat door de gebruiker is opgegeven sla je vanzelfsprekend niet op. De functie password_hash() gebruik je wanneer de gebruiker voor het eerst zijn of haar wachtwoord registreert (of een nieuwe wil instellen). In een voorbeeld ziet het gebruik van password_hash() er als volgt uit:

<?php
//registreer wachtwoord
//controleer of ingevoerde wachtwoorden gelijk zijn
if ($_POST['wachtwoord'] == $_POST['herhaal_wachtwoord']) {
    
//bereken hash
    
$hash = password_hash($_POST['wachtwoord'], PASSWORD_DEFAULT);
    
//(hier code om de hash bij de juiste gebruikersnaam op te slaan in de database o.i.d.)
}
else {
    
//(hier code om een foutmelding te geven dat de wachtwoorden niet gelijk zijn, etc.)
}
?>

Als de hash van het wachtwoord eenmaal is berekend en opgeslagen, wordt vervolgens tijdens het inloggen een tweede functie gebruikt om te controleren of het opgegeven wachtwoord overeen komt met het op de server bekende wachtwoord. Dit is de functie password_verify():

bool password_verify ( string $password , string $hash )

Als parameters worden voor deze functie het door de gebruiker bij inloggen opgegeven wachtwoord gebruikt en de hash die eerder door password_hash() is gegenereerd en op de server staat opgeslagen. Het resultaat van password_verify() is TRUE wanneer het opgegeven wachtwoord overeen komt met de opgeslagen hash, of FALSE wanneer dat niet het geval is. In een voorbeeld ziet dit er als volgt uit:

<?php
//controleer wachtwoord
$hash = '$2y$10$GJ.W8A08WPHdvMTn1zGYbetSakX2D/VslOtUKLiNsPvf/AUH4Q9Be'; //(komt normaal uit database)
if (password_verify($_POST['wachtwoord'], $hash)) {
    echo
'Wachtwoord is correct';
}
else {
    echo
'Wachtwoord is niet correct';
}
?>

Dan nog een paar slotopmerkingen bij het gebruik van password_hash(). Omdat het gebruikte algoritme in een toekomstige versie kan wijzigen, is vooraf nooit bekend uit hoeveel tekens een hash bestaat. Het is daarom verstandig om er rekening mee te houden dat een hash in de toekomst langer kan zijn. Bij opslaan in een database geeft een kolomgrootte van 255 tekens voldoende ruimte voor de toekomst.

En omdat bij gebruik van PASSWORD_DEFAULT het gebruikte hash-algoritme kan wijzigen naar een veiliger variant wanneer op enig moment een nieuwere versie van PHP wordt gebruikt, zul je op dat moment moeten controleren of de oude hashes nog voldoen of juist bijgewerkt moeten worden. Dit kan met de functie password_needs_rehash():

bool password_needs_rehash ( string $hash , int $algo [, array $options ] )

Waarbij $hash de opgeslagen hash en $algo opnieuw ingesteld als PASSWORD_DEFAULT. Wanneer het hash-algoritme niet is gewijzigd, geeft de functie FALSE (en is dus nog alles in orde). Wanneer de hash verouderd is geeft de functie TRUE. In een voorbeeld ziet dat er als volgt uit:

<?php
//controleer wachtwoord
$hash = '$2y$10$GJ.W8A08WPHdvMTn1zGYbetSakX2D/VslOtUKLiNsPvf/AUH4Q9Be'; //(komt normaal uit database)
if (password_needs_rehash($hash, PASSWORD_DEFAULT)) {
    echo
'Hash is verouderd';
}
else {
    echo
'Hash is in orde';
}
?>

Oei, nu blijkt een hash verouderd, maar wat dan? Er bestaat geen functie om de oude hash bij te werken naar de nieuwe, omdat hiervoor het oorspronkelijke wachtwoord nodig is. En het idee van een hash is dat je het wachtwoord juist niet kunt terugberekenen. Wat je zou kunnen doen is iedere keer dat een gebruiker inlogt met behulp van password_needs_rehash() controleren of de hash nog goed is. Is dat niet het geval, dan kun je (nadat je hebt vastgesteld dat het wachtwoord klopt met de oude hash) het opgegeven wachtwoord gebruiken om een nieuwe hash te maken en op te slaan. Een andere manier is het toepassen van twee-staps verificatie en de gebruiker niet te laten inloggen wanneer de hash verouderd is en op dat moment een e-mail sturen naar de gebruiker met een extra code of een verzoek om het wachtwoord opnieuw in te stellen. Wellicht is een combinatie van beiden het beste compromis tussen gebruiksgemak en beveiliging. Stel je een situatie voor dat een gebruiker al heel lang niet heeft ingelogd. Bij de eerste methode blijft de verouderde hash dan heel lang in het systeem bewaard en kan nog heel lang met die verouderde hash die intussen misschien gekraakt is worden ingelogd. Op dat moment zou je misschien wel een extra verificatie via e-mail willen doen. Maar andersom is het op dag één na het van kracht worden van een nieuw hash-algoritme wel erg overdreven om meteen een verificatie via e-mail af te dwingen. En onnodige moeite voor je reguliere bezoekers. Je zou dus beide kunnen combineren door bijvoorbeeld in de eerste twee maanden na het van kracht worden van een nieuw hash-algoritme de hash van de gebruikers die dan inloggen stilletjes op de achtergrond bij te werken. En voor gebruikers die pas na die twee maanden weer eens inloggen dan wel een verificatie via e-mail te eisen.

PS: wanneer je versie van PHP ouder is dan 5.5, maar wel nieuwer of gelijk aan 5.3.7, dan zitten de password_* functies niet in jouw versie van PHP, maar kun je deze functies alsnog toevoegen via de bibliotheek password_compat. Wanneer je versie van PHP ouder is dan 5.3.7 is het sowieso misschien wel eens tijd om te upgraden, omdat je dan al een hele tijd geen beveiligingsupdates meer hebt gehad.

Automatisch inloggen via cookie

Wat we in hoofdstuk 11 en hoofdstuk 21 ook hebben gezien is dat je een gebruiker automatisch kan inloggen door middel van een cookie. In hoofdstuk 11 hebben we gebruikersnaam en wachtwoord in het cookie gezet. In hoofdstuk 21 was dat het gebruikers-ID in plaats van de gebruikersnaam, maar nog steeds met wachtwoord. Uit het oogpunt van beveiliging wil je eigenlijk niks in een cookie zetten waaruit de inloggegevens van de gebruiker zijn af te leiden. Het gebruikers-ID in plaats van de gebruikersnaam was dus al een aardige verbetering, want met het gebruikers-ID kun je niet inloggen. Alleen het ID opslaan is weer veel te makkelijk, want dan kan een aanvaller gewoon wat willekeurige getallen proberen om binnen te komen. Daar moet dus wel nog iets bij, maar dat moet dan weer niets met het wachtwoord van de gebruiker te maken hebben.

De oplossing hiervoor is het gebruik van een token. Wanneer de bezoeker inlogt met (correcte) gebruikersnaam en wachtwoord wordt er token genegereerd. Dit token wordt gekoppeld aan de gebruiker opgeslagen op de server en wordt samen met het gebruikers-ID opgeslagen in het cookie op de computer van de gebruiker. Zodra de bezoeker de website opnieuw bezoekt en het cookie nog op zijn of haar computer heeft, worden het ID en token gebruikt om de gebruiker automatisch in te loggen wanneer dit overeen komt met het opgeslagen token op de server.

Token genereren

Hoe kom je nu aan zo'n token? We kunnen PHP gebruiken om iedere keer als er een token nodig is een nieuwe te genereren. Toch is het genereren van een cryptografisch veilige token niet heel triviaal. De meeste "random number generators" zijn namelijk helemaal niet zo random en genereren op exact hetzelfde tijdstip altijd exact dezelfde uitkomst. Als je dan weet hoe laat iemand zich heeft aangemeld, nou vul zelf maar in. Gelukkig biedt PHP 7 uitkomst met een nieuwe functie: random_int(). Hiermee kan een cryptografisch willekeurig getal worden opgevraagd, wat vervolgens weer kan worden gebruikt om een token te genereren. Voor PHP-versies ouder dan versie 7 kan de bibliotheek random_compat worden gebruikt om alsnog gebruikt te kunnen maken van deze nieuwe functie.

int random_int ( int $min , int $max )

Zoals gezegd geeft random_int() een willekeurig (geheel) getal en het enige wat je hiervoor hoeft op te geven is een onder- en bovengrens waarbinnen dit getal moet vallen. Hiermee kun je als volgt een token genereren:

<?php
//functie om token te genereren
function genereer_token() {
    
$token_length = 64; //aantal karakters in token
    
$token_chars = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'; //karakters die kunnen voorkomen in token
    
$token = '';
    
//genereer 64x ($token_length) een random_int tussen 0 en 61 (strlen($token_chars) - 1)) en haal dat karakter op uit $token_chars
    
for ($i = 0; $i < $token_length; $i++) {
        
$token .= substr($token_chars, random_int(0, strlen($token_chars) - 1), 1);
    }
}

//genereer token:
$nieuw_token = genereer_token();

?>

In dit voorbeeld hebben we een nieuwe functie genereer_token() gemaakt om een token te genereren. In dit geval is er voor gekozen om altijd tokens met een lengte van 64 karakters te genereren dat kan bestaan uit alle kleine letters en alle hoofdletters van het alfabet en alle cijfers. Dat zijn 62 verschillende karakters die samen 5*10114 combinaties kunnen vormen. Dat is meer verschillende combinaties dan het aantal deeltjes in het waarneembare heelal[bron]. Er is weinig reden om een korter token te nemen, aangezien niemand dit met de hand hoeft over te typen.

Token hashen

Over de vraag of je een token moet hashen wanneer je het op de server opslaat heb ik even nagedacht. Want eigenlijk is het token een soort vervanging voor een wachtwoord. Vooropgesteld kan het zeker nooit kwaad om het token te hashen. Gebruik hiervoor dan dezelfde methode als het hashen van een wachtwoord wat eerder in dit hoofdstuk is toegelicht. Maar of het echt, echt, nodig is? Er van uitgaande dat SSL/TLS goed werkt, kan het token niet onderschept worden. Als SSL/TLS niet goed werkt kan niet alleen het token, maar ook het wachtwoord bij inloggen onderschept worden. Hashen is daar geen beveiliging tegen, dus dat maakt niet uit. Als de gebruiker het cookie van zijn of haar computer laat stelen geldt hetzelfde. Mocht een aanvaller toegang krijgen tot de server, dan zou een hash helpen om te voorkomen dat de aanvaller toegang krijgt tot de tokens. Maar aangezien de aanvaller dan al toegang heeft tot de server, heeft deze de tokens niet meer nodig om toegang te krijgen tot de website. Daardoor lijkt het hashen van tokens niet heel veel toe te voegen.

Waarom moet je een wachtwoord dan wel hashen? Dat heeft niet zo zeer te maken met het toegang krijgen tot jouw website, want als een aanvaller toegang heeft tot de database met wachtwoorden, heeft deze toch ook al toegang tot je website. Het hashen van wachtwoorden is juist heel belangrijk voor de beveiliging van andere websites, omdat veel mensen overal dezelfde gebruikersnaam en wachtwoord gebruiken. Wanneer jij de wachtwoorden niet veilig opslaat én onverhoopt je database gestolen wordt, ligt daarmee potentieel de toegang tot gebruikersaccounts op vele andere websites die jouw bezoekers gebruiken op straat. En dat is dan jouw schuld. Als de wachtwoorden op een goede manier gehasht zijn, heeft de aanvaller er verder niks aan en hoeven je gebruikers niet opeens overal hun wachtwoord te wijzigen. Als je ze al zou kunnen bewegen om dat daadwerkelijk te doen.

Extra beveiliging

Je kunt nog wat extra beveiliging aan het token toevoegen. Bijvoorbeeld door bij het toekennen van een token ook het IP-adres van de bezoeker ($_SERVER['REMOTE_ADDR']) op te slaan bij het token (op de server). Hierdoor kun je je script zodanig aanpassen dat het token alleen geldig is bij gebruik van dat IP-adres. Wanneer het IP-adres niet overeen komt, moet de gebruiker dan gewoon met gebruikersnaam en wachtwoord inloggen. Bedenk wel dat mobiele gebruikers dan iedere keer opnieuw moeten inloggen. Eventueel zou je voor mobiele gebruikers nog iets kunnen met het toekennen van meerdere tokens, een voor elk IP-adres.

Eventueel kun je ook nog iets met de browserversie ($_SERVER['HTTP_USER_AGENT']) die aan PHP wordt doorgegeven. Browserversies zijn minder uniek dan IP-adressen, maar het geeft geen extra ongemak voor mobiele gebruikers. Nadeel hiervan is weer dat iedereen die z'n browser bijwerkt opnieuw moet inloggen.

Je kunt beide ook combineren, waarbij het token alleen geldig is als het IP-adres of de browserversie overeen komen. Dit is minder sterk dan wanneer allebei gelijk moeten zijn en zelfs minder sterk dan wanneer je één van beide kiest, maar het heft de individuele nadelen wel grotendeels op terwijl je toch een extra beveiligingslaag toevoegt.

Als het nog veiliger moet, kom je al snel terecht bij bij two-factor authentication. Het voert echter te ver voor dit boek om daar dieper op in te gaan, omdat je two-factor authentication eigenlijk niet met alleen PHP kan implementeren.

Zelftest

  1. Wanneer moet je HTTPS gebruiken?
    1. Alleen als een bezoeker zijn wachtwoord invoert.
    2. Alleen als de bezoeker zijn naam, adres of woonplaats invoert.
    3. Wanneer persoonlijke gegevens worden ingevoerd of weergegeven.
    4. Altijd.
  2. HTTPS kun je afdwingen...
    1. ...met een certificaat.
    2. ...met SSL/TLS.
    3. ...met een controle via PHP.
    4. ...met een HTML-formulier.
  3. Welke van onderstaande stellingen is/zijn waar?
    I             Door toepassing van een salt is een hash makkelijker te kraken.
    II            In een regenboogtabel kun je het wachtwoord opzoeken dat bij een hash hoort.
    1. Beide stellingen zijn onwaar.
    2. Alleen stelling I is waar.
    3. Alleen stelling II is waar.
    4. Beide stellingen zijn waar.
  4. Welke van onderstaande stellingen is/zijn waar?
    I             Voor ieder wachtwoord kun je het beste steeds dezelfde salt gebruiken.
    II            De salt wordt niet opgeslagen op de computer van de bezoeker.
    1. Beide stellingen zijn onwaar.
    2. Alleen stelling I is waar.
    3. Alleen stelling II is waar.
    4. Beide stellingen zijn waar.
  5. Wanneer een hash-algoritme verouderd is...
    1. ...kun je de oude hashes met een functie omzetten naar het nieuwe algoritme.
    2. ...moet je je gebruikers direct een e-mail sturen om ze hiervan op de hoogte te brengen.
    3. ...moet je alle oude hashes bijwerken naar het nieuwe algoritme.
    4. ...gebruik je password_needs_rehash() om een nieuwe hash in te stellen.
  6. Het wachtwoord van de gebruiker bewaar je waarin?
    1. Een cookie.
    2. Een token.
    3. Een hash.
    4. Een database.
  7. Welke van onderstaande stellingen is/zijn waar?
    I             In een cookie bewaar je de gebruikersnaam en het wachtwoord.
    II            In een cookie bewaar je een ID en een token.
    1. Beide stellingen zijn onwaar.
    2. Alleen stelling I is waar.
    3. Alleen stelling II is waar.
    4. Beide stellingen zijn waar.
  8. Voor het genereren van een random token gebruik je de volgende functie:
    1. rand()
    2. mt_rand()
    3. random_int()
    4. srand()
  9. Welke van onderstaande stellingen is/zijn waar?
    I             Een wachtwoord moet je hashen voor opslag op de server.
    II            Een token moet je hashen voor opslag op de server.
    1. Beide stellingen zijn onwaar.
    2. Alleen stelling I is waar.
    3. Alleen stelling II is waar.
    4. Beide stellingen zijn waar.

Antwoorden zelftest

Antwoorden

  1. c
  2. c
  3. c
  4. c
  5. c
  6. c
  7. c
  8. c
  9. c

Oefening: MySQL loginsysteem aanpassen

In hoofdstuk 21 is een MySQL loginsysteem gemaakt waarvan de beveiliging niet helemaal voldoet. In deze oefening ga je dit loginsysteem aanpassen aan de hand van de theorie uit dit hoofdstuk om de beveiliging op orde te brengen.

Opdracht

Ga uit van de volledige code van het praktijkvoorbeeld van hoofdstuk 21. Ga na welke bestanden aangepast moeten worden en voer deze aanpassingen door.

Bepaal daarna welke aanpassingen je nog meer zou moeten maken in de oefening van hoofdstuk 21 en de oefening van hoofdstuk 22. Geef per script/bestand aan wat deze aanpassingen zijn.

Uitwerking opdracht

Uitwerking

later.php

De uitwerking van deze oefening wordt op een later moment toegevoegd.