Veel te lang niet geblogd. Maar goed, ik leer van alles. Hoog tijd om daarvan verslag te zodat ik het nog wat beter leer en onthoud. Na avonturen met PHP heb ik in mijn opleiding inmiddels ook het MySQL-gedeelte – ofwel werken met databases – succesvol afgerond. Maar voor ik dat hier laat zien nog een stukje PHP.

Eén van de dingen die nog openstaan – zowel hier als op Web development uitdagingen – is een contactformulier. En laat je die nu vrij eenvoudig kunnen maken met PHP, zeker als je gebruikmaakt van frameworks, bibliotheken die je kunt invoegen in pagina’s die je zelf ontwikkelt. Voordeel daarvan is onder andere dat je je minder druk hoeft te maken om allerlei veiligheidsrisico’s. Natuurlijk kun je niet alles blindelings vertrouwen, zo kan het geen kwaad om htmlspecialchars() om je gebruikersinvoer te zetten.

Een bekend framework is PEAR. Het zit meegeleverd bij PHP. Niet compleet, de Mail module moet je dan zelf weer installeren. Heb je dat eenmaal voor elkaar dan is de rest betrekkelijk eenvoudig.

De 3 stappen

1. Bouw een html pagina met daarin een formulier. In de meest basale vorm ziet dat er zo uit:

   <form method="post" action="contact.php">
   	<label>Naam   <input type="text" name="naam" required></label>
   	<label>E-mailadres  <input type="email" name="email" required></label>
   	<label>Je bericht <textarea name="bericht" required></textarea></label>
   	<input type="submit" name="submit" id="submit" value="Versturen">
   </form>

   Het contact-attribuut mag in html5 overigens weggelaten worden als de huidige pagina voor de afhandeling zorgt.

2. De tweede stap is dat je bovenaan de pagina een PHP-blok plaatst dat voor de afhandeling zorgt – lees: dat bepaalt wat er gebeurt als je op ‘Versturen’ klikt. In de eerste plaats moet je require_once 'Mail.php'; invoegen. Vervolgens moet je controleren of er op ‘Versturen’ is gedrukt. Logischerwijs heb ik gekozen voor de $_POST-verzendmethode want ik wil niet dat de hele inhoud van het contactformulier in de adresbalk komt te staan. Ik wil controleren of alle velden ingevuld zijn – en niet door op de spatiebalk te drukken – en ik wil nogmaals controleren of het e-mailadres geldig is. Dat heb ik weliswaar al gedaan met html door <input type=”email” /> aan te geven maar een extra controle lijkt me niet onverstandig. De code komt er als volgt uit te zien:

   if (isset($_POST['submit']) && !empty(trim($_POST['naam'])) && !empty(trim($_POST['bericht'])) && !filter_var($_POST['email'], FILTER_VALIDATE_EMAIL) === false)

   De trim() functie zorgt ervoor dat spaties weggehaald worden. In eerste instantie had ik gekozen voor trim() in combinatie met isset() maar dat bleek niet te werken. De inhoud van deze regel: er is op de knop met de naam submit geklikt, na weghalen van de spaties zijn de velden ‘naam’ en ‘bericht’ niet leeg en het e-mailadres in $_POST[‘email’] is niet ongeldig.

3. Als aan die voorwaarden is voldaan, kan het daadwerkelijke mailscript in gang gezet worden. Dat mailscript bestaat kort gezegd weer uit drie onderdelen: a) de mailsettings (een Gmail-adres werkt niet), b) de mail zelf die is opgebouwd uit een aantal header variabelen en die gegevens uit $_POST bevatten omdat daar de inhoud van de mail in staat en tot slot c) het mechanisme dat het versturen van de mail bewerkstelligt.Tot zover mijn korte uitleg over het PEAR mailscript. Mocht je meer willen weten, laat dan vooral een reactie achter in de comments of gebruik natuurlijk het contactformulier van Web development uitdagingen.

To do

• Uitzoeken of een captcha mogelijk is.
• Contactformulier bij dit blog maken.

Gisteren en vandaag heb ik na het zien van een stukje code dat ergens anders ontbrak  gebruikt om me eens flink te verdiepen in de veiligheid van PHP. En dan vooral de veiligheid van gebruikersinvoer want dat je die niet zonder meer mag vertrouwen is me de afgelopen maanden al wel duidelijk geworden.

En het was maar goed dat ik me erin verdiepte. Er ontbrak dus ergens een stukje code. In mijn code voor het gastenboek dat binnenkort hopelijk op Web development uitdagingen verschijnt. Dat kan tot het onderstaande resultaat leiden:

Hoe heb ik deze ‘hack’ bewerkstelligd? Op de plek waar ik een bericht in kon vullen, heb ik simpelweg het volgende ingevuld:

<script>alert('Gehackt!');</script>

Dat was alles. Maar naar natuurlijk zijn er gevaarlijkere manieren om deze kwetsbaarheid te exploiteren. Je zou bijvoorbeeld een script van een andere pc kunnen laden en met met dat script die ander ongemerkt toegang geven tot jouw computer. De techniek heet Cross-site scripting (XSS).

Kwetsbaarheid oplossen

Gelukkig is de kwetsbaarheid die ik hier liet zien betrekkelijk eenvoudig op te lossen. Het gaat erom dat de PHP engine op de server te gevaarlijke code niet meer als zodanig interpreteert. Aanhalingstekens en haken moeten daartoe omgezet worden in ongevaarlijke tekens. Meerdere mogelijkheden, ik noem er drie:

1. strip_tags.() Deze functie zorgt er in bovenstaande voorbeeld voor dat de script tags verwijderd worden waardoor het voorbeeld slechts een onschuldige tekst oplevert.
2. htmlentities(). Deze functie zorgt ervoor dat alle karakters waarvoor de functie aangeroepen wordt, omgezet wordt naar HTML code.
3. htmlspecialchars() Doet hetzelfde als nummer 2, maar behoudt accenten. Die worden door htmlentities() namelijk omgezet in HTML code.

Zelf geef ik de voorkeur aan htmlspecialchars(). Hoe maak je de code nu veilig? Ik geef de code die berichten uit het gastenboek laat zien.

function show_post($result)
		{
			
			foreach ($result as $key => $value)
				{
					echo '<div class="box">';
					foreach ($value as $subkey => $subvalue)
						{
							$subkey = htmlspecialchars($subkey);
							$subvalue = htmlspecialchars($subvalue);
							echo '<div class="' . $subkey . '">' .  $subvalue . '</div>';	
							if($subkey == "id")
								{
									echo '<a href="update.php?id=' . $subvalue . '"><div class="update"></div></a>';
									echo '<a href="delete.php?id=' . $subvalue . '"><div class="delete"></div></a>';
								}
						}
					
					echo '</div>';
				}

In de oorspronkelijke code ontbraken regels 9 en 10. Deze regels zorgen er nu voor dat de gebruikersinvoer gecontroleerd wordt voordat deze op het scherm getoond wordt.

Nog een kwetsbaarheid

Bij formulieren is het gebruikelijk om aan te geven welke method (get of post) er gebruikt wordt. En welke pagina de afhandeling verzorgt (action). Het action attribuut kan sinds HTML5 weggelaten worden. In dat geval is de huidige pagina de pagina die het formulier afhandelt.

Je kunt ook kiezen voor een stukje PHP. De functie $_SERVER[‘PHP_SELF’] is huidige pagina. Die kun je als volgt opnemen in je action.

<form method="post" action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]);?>">

Met htmlspecialchars dus. Doe je dat niet dan kun je met de volgende tekst achter de url in de adresbalk hetzelfde ‘Gehackt’ scherm te zien krijgen als waar we mee begonnen.

/%22%3E%3Cscript%3Ealert('Gehackt!')%3C/script%3E

Het laatste voorbeeld is overigens afkomstig van W3Schools. Welbestede dagen, zou ik denken. Eenvoudig te testen veiligheid.

Wordt ongetwijfeld vervolgd, al is het maar met een aflevering over gebruikersinvoer en de database.

Voor ik aan mijn opleidingstraject tot web developer begon, heb ik eerst gekeken of het mij echt interesseerde en of ik er voldoende van begreep om het enigszins kansrijk te maken.

Ik ben namelijk nogal talig aangelegd, wiskunde is dan ook niet mijn sterkste kant. Die eerste kennismaking verliep aan de hand van de Udemy Course The Complete Web Developer Course van Rob Percival HTML & CSS. Design and build websites van Jon Duckett, HTML en CSS de basis van Andree Hollander, Handboek JavaScript & jQuery van Peter Kassenaar en wat CodeCademy. Toen mijn vorige baan teneinde liep was ik al begonnen, vandaar en het duurde even voor ik met mijn cursus kon beginnen.

Testen en nog eens testen

Omdat ik ervan doordrongen was dat mezelf testen voor mij een belangrijke voorwaarde is om succesvol te leren, heb ik zo veel mogelijk oefeningen gemaakt en heb daarnaast veel in Anki gezet (Anki is een programma waarmee je jezelf kunt overhoren volgens de principes van gespreid herhalen).  Veel van wat ik in Anki zette, formuleerde ik als kleine opdracht: maak een array met zeven huisdieren en geef er daarvan drie cursief weer. Doordat ik die opdrachten uitschrijf in Notepad++ en vervolgens in de browser open om te kijken of het daadwerkelijk werkt, maak ik me de eigenaardigheden van de code eerder eigen dan wanneer ik de oplossingen alleen voor me uit prevel. Dit alles wordt nog versterkt doordat ik Anki iedere avond gebruik. Ook met de opdrachten van mijn opleiding probeer ik dagelijks bezig te zijn.

Web Development uitdagingen

De afgelopen dagen ben ik bezig geweest de opdrachten die ik voor de Udemy cursus gemaakt heb, online te zetten op Web development uitdagingen, de site bij deze blogserie. Ik vond die cursus als inleiding behoorlijk interessant, zeker omdat je zowel kennismaakte met HTML/CSS als met JavaScript/jQuery en PHP/MySQL en Bootstap. Het is echter inleidend en mijn huidige opleiding graaft dieper.

Challenges

Maar omdat de Udemy cursus iedere module afsloot met een leuke programmeeropdracht, leek het mij aardig om die programmeeropdrachten op de site te zetten. Hier en daar heb ik er wat aanpassingen in aangebracht. Zo kreeg ik met mijn oorspronkelijke uitwerking van PHP opdracht een PHP foutmelding als ik mijn eigen woonplaats opzocht. Dat heb ik opgevangen door eerst te controleren of de url bestaat (i.e. geen 404 oplevert).

Voor het geheime dagboek dat de MySQL module vormde heb ik besloten om de md5 encryptie te vervangen door password_hash en password_verify. Dit omdat PHP.net het gebruik van md5 afraadt bij het opslaan van wachtwoorden.

Tot slot vond ik het spelen met JavaScript spelletje zo leuk, dat ik er zelf nog een versie voor 2 personen voor heb gemaakt.

Neem dus vooral een kijkje op Web development uitdagingen.

Volgende uitdaging:

Maak een contactformulier.

Zaterdag schreef ik dat je door de includes map buiten de www/public_html map te plaatsen, een map hoger dus, een mooie manier hebt om ervoor te zorgen dat bestanden die je opneemt als onderdeel van andere pagina’s niet als zelfstandige pagina’s te benaderen zijn. Gisteravond meende ik te ontdekken dat dat voor deze website niet lukte.

Het ging althans niet via WinSCP, maar ik ontdekte net pas dat het wel ging ik de file manager van het beheer systeem van de website gebruikte.  Ondertussen had ik al al drie andere oplossingen gevonden. Die schrijf ik maar gauw op voordat ik ze vergeet.

Methode 1: .htaccess

De eerste methode is waarschijnlijk de eenvoudigste. Stel dat je de map onzichtbaar niet benaderbaar wilt hebben. Je plaatst dan in die map het bestandje .htaccess. Dat wil zeggen: beginnen met een punt en eindigen zonder extensie. Dat bestandje heeft maar 1 regel nodig:

deny from all

De methode werkt prima, maar heeft als nadeel dat het er gebruikersonvriendelijk uit ziet. Kijk maar:

Forbidden

You don’t have permission to access /wachtwoord/ on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

Methode 2: gebruik functies

Methode 2 levert een blanco scherm op. Zie dit voorbeeld. De pagina bevat echter wel code. Maar die code maakt onderdeel uit van een functie en het resultaat van de functie is pas zichtbaar als de functie aangeroepen wordt, wat hier dus niet is gebeurd. Dit principe kun je gebruiken om de van inhoud van pagina’s in een includemap onzichtbaar te maken. Je neemt het bestand op in een pagina en roept vanaf die pagina de functie pas aan. Je kunt het ook gebruiken als je alleen HTML hebt. Je maakt dan als volgt een functie aan:

function htmlWeergeven() {
echo '
<p>Hier plaats je alle html code</p>
';
}

PHP code is nooit zichtbaar en een browser in de code de opdracht is gegeven HTML output te generen, bijvoorbeeld met het commando echo, zoals hierboven.

Methode 3: gebruik het verschil in URL

Dit vind ik zelf de leukste methode omdat je hiermee de vrijheid hebt om zelf te bepalen wat je bezoeker te zien krijgt.

Waar het bij deze methode om draait, is dat de bestanden toegankelijk moeten zijn als ze ingevoegd zijn, met ofwel include of met require. Benader je het losse bestand dan dient het bestand niet toegankelijk te zijn. Het draait om de url. Als een bestand ingevoegd is, heeft het geen zelfstandige url. Als je bestand zelf benadert, krijg je bijvoorbeeld deze url:
http://webdevelopmentuitdagingen.nl/oefenpaginas/includes/verbergen.php

Het gaat om  de map includes. Die wil ik ontoegankelijk maken. In PHP kun je met verschillende functies urls uitlezen.  De code die daarvoor zorgt in bovengenoemd bestand is:

$url = $_SERVER['REQUEST_URI'];
$url = explode('/', $url);
print_r($url);

In de eerste regel wordt de url van het bestand als tekst (string) opgeslagen opgeslagen in de variabele $url. De 2 regel maakt losse blokken van de url met de / als scheidingsteken en de derde regel toont die losse blokken; of array elementen, om ze hun juiste namen te geven. De print_r regel toont de array op het scherm en moet weg voor je het bestand daadwerkelijk uploadt.

Je kunt nu een voorwaarde maken op basis van de url. Array element nummer 2 van $url is includes. Dat kun je bevragen:

if ($url[2]=='includes') {
		echo '<h1>Excuses</h1><p>Deze pagina is helaas
 niet beschikbaar. Klik 
<a href="http://www.webdevelopmentuitdagingen.nl">hier
</a> om terug te gaan naar de site.<p>';
		exit();
	}

Binnen dat echo is natuurlijk alles mogelijk. Maar je kunt ook automatisch doorlinken door in plaats van echo header('Location:http://www.webdevelopmentuitdagingen.nl'); op te nemen. Voor die header mag echter geen enkele code ge-echo’d. worden, zelfs geen spatie of nog erger html code die niet gemaakt is door PHP.

Typ overigens niet Loation i.p.v. Location, een tikfout die mij nogal eens overkomt. De hoofdletter, de () en de aanhalingstekens zijn verplicht, net als de puntkomma aan het einde.

Het commmando exit() zorgt ervoor dat alle code die hierna komt niet meer uitgevoerd wordt, hetzij PHP, hetzij HTML/JavaScript. En exit() werkt ook voor de pagina waarin het bestand eventueel ingevoegd wordt.

Het mooie van dit script op basis van if ($url[2]=='includes') is dat je de conditie zo in kunt vullen als je zelf wilt en dat je ook helemaal zelf kunt invullen wat er gebeurt als niet aan de conditie wordt voldaan. Je kunt bij wijze van een spreken een pseudo-404-pagina ontwerpen als je daar zin in hebt. Of een mooie easter egg verstoppen.

En het allerleukste?

Je kunt dit script uiteraard met een simpele regel code ‘includen’ of ‘requiren’ in alle bestanden waarvan je inhoud wilt verbergen.

Na het stellen van mijn opdracht in de vorige aflevering van deze serie had ik ook de opdracht die ik daarna wilde uitvoeren al snel in gedachten. Ik heb nu besloten beide opdrachten om te draaien. Ik was van plan om eerst de site van inhoud te voorzien en daarna te zorgen voor een goede paginastructuur.

Bij nader inzien lijkt me dat een onlogische volgorde. Het toevoegen van pagina’s gaat namelijk een stuk efficiënter als je eerst zorgt voor een goede paginastructuur. Op die manier hoef je per pagina zo weinig mogelijk te wijzigen.

Een stukje geschiedenis

Een webpagina bestaat voor een groot deel uit onderdelen die voor elke pagina hetzelfde zijn. Denk een een header, een menu en een footer. Alleen het gedeelte met de inhoud van een pagina is steeds verschillend. Voordat dynamische websites opkwamen kon je in HTML dergelijke onderdelen in je site zetten met frames en een frameset. Belangrijk nadeel van deze techniek is dat leessoftware voor blinden een slechtzienden er niet mee overweg, wat waarschijnlijk een reden is geweest waarom de frame techniek geen onderdeel meer uitmaakt van HTML5.

Enter PHP

Tegenwoordig los je bovengenoemd scenario op met wat server side includes worden genoemd. Je maakt dan losse pagina’s voor je footer, je menu enz. en die voeg je dan op de plek waar ze in pagina moeten toe aan de code. Voor web development uitdagingen pagina betekende dat ik de werkende index.php pagina heb gepakt en daar de header, het menu, de footer en de aside van mee gemaakt heb. Voordeel van deze  aanpak is dat ik dus niet op 10 pagina’s het menu moet aanpassen, maar alleen maar menu.php.

Pagina’s in een andere pagina opnemen gaat heel makkelijk met include. Mocht een in te voegen deel van een pagina nu essentieel zijn voor de werking van de pagina dan heb je daar de functie require voor. In dat geval zal de pagina niet werken als het benodigde bestand ontbreekt. Van beide functies heb je ook een _once variant. Die is handig om te voorkomen dat je 2 keer een include opneemt waarin je een functie definieert. Een functie mag namelijk maar een keer gedefinieerd worden.

Includepad

Het is gebruikelijk de losse in te voegen bestanden in een includes map te zetten. Bijvoorbeeld www.example.com/includes/menu.php. Nadeel van deze werkwijze is dat het menu los van de site waar het bijhoort  te benaderen is. Je kunt er ook voor kiezen om je includes op te slaan in de map boven je www (root) map. Je verwijst dan als volgt vanaf de root ../includes.menu.php. Het menu wordt nu keurig opgenomen in de site maar is door bezoekers niet meer los te benaderen.

Benieuwd naar het resultaat tot nu toe? Klik op de schermafbeelding van de website. Die geeft overigens niet de actuele situatie weer.

Volgende uitdaging:

Lege pagina’s vullen.