Toen ik eind januari hoorde dat ik mijn opleiding tot web developer succesvol had afgerond, nam ik mij voor om vanaf maart alle tussentoetsen en het examen opnieuw te maken. Tegen die tijd was er behoorlijk wat tijd voorbij gegaan sinds ik ze maakte zodat  opnieuw maken een goede en leerzame herhaaloefening zou zijn van stof die misschien een beetje was weggezakt.

Een ander plan

Maar mijn oom en tante hadden een beter idee. Voor fietsers in de mooie regio Noord-Limburg verhuren zij sinds kort kamers op de bovenverdieping van hun boerderijwoning en daar wilden ze graag een site voor hebben. Of ik die wilde maken? Natuurlijk had ik daar wel oren naar want ik realiseerde me meteen dat de opdracht alles zou bevatten wat ik tijdens mijn opleiding had geleerd en nog heel wat meer. We werden het er al snel over eens dat mijn oom en tante voor de inhoudelijke invulling zouden zorgen en hun wensen kenbaar zouden maken wat betreft vormgeving zodat ik me kon richten op de technische kant.

De website van mijn oom en tante is te vinden via Slapen en Ontbijten “Op de Kogel”  of door op bovenstaande afbeelding te klikken. Bekijk de site vooral en boek een kamer want het is inderdaad een mooie omgeving.

Wat kwam er kijken bij de site?

• De site moest goed werken op alle mogelijke schermen. Websitebouwers noemen dat responsive design. Dit was een behoorlijke klus omdat het bij de extra opdrachten van mijn opleiding hoorde en dus niet werd getoetst.
• Een fotoboek en een slider.
• Een contactformulier dat automatisch een mailtje stuurt nadat het ingevuld is.
• Sommige pagina’s moeten door mijn oom en tante gewijzigd kunnen worden zonder dat ze dat steeds aan mij moeten vragen.
• Er moest dus gewerkt worden met een database en een administrator gedeelte waarin op een eenvoudige manier wijzigingen aangebracht kunnen worden aan pagina’s. Ik heb daarvoor CKEditor gekozen.
• Het administrator gedeelte dient uiteraard afgeschermd te zijn met een login en wachtwoord.
• En bijna tot slot, maar niet onbelangrijk: ik had voor het eerst echt met klanten te maken die wensen hadden voor hun website. En er veranderde tijdens het ontwerpen weleens wat of er kwam een nieuw idee.
• Dat zorgde er dus voor dat ik de site van de grond af aan op moest bouwen. Mijn oom en tante hadden ideeën, het was aan mij om die in een werkzame site om te zetten. En voor het eerst zonder stappenplan (= te maken opdrachten) van de opleiding.

Al met al was het een leuke en ook leerzame klus.  En had je nu al op Slapen en Ontbijten “Op de Kogel” gekeken?

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.