Over Wander Nauta

Wander is werkzaam op de afdeling Development. Als ontwikkelaar werkt hij voortdurende aan verbetering voor de website, Mijn Antagonist en alles daaromtrent. Tevens studeert hij Technische Informatica aan de Universiteit Twente.

Het mobiele web: responsive en mobiele websites voor tablets en smartphones

Meer en meer mensen maken gebruik van het wereldwijde web op een smartphone of tablet. Zodoende groeit het aantal mobiele websites flink. Logisch, want bezoekers willen een website, ook op hun mobiele apparaat, graag prettig ervaren. Echter, zijn het niet alleen bezoekers die eisen stellen, ook partijen als Google hechten steeds meer waarde aan een mobiel of responsive design.

Mobiele website: ontwerp voor smartphone en tablet

Verder lezen

Web fonts, voorbij Verdana: Twee decennia lettertypes op het web

Hoeveel tekst staat er op jouw website? Best veel, waarschijnlijk. Als je een blog of een informatieve site hebt, is de tekst van je site waarschijnlijk het belangrijkste onderdeel. Als je kijkt naar wat voor een centrale rol tekst heeft op de meeste websites, wordt er relatief weinig aandacht besteed aan de opmaak ervan. Heel veel sites kiezen een standaardlettertype (Trebuchet, 16px, bijvoorbeeld) en houden het daarbij.

Web fonts: Houten drukletters

Maar wat als je méér wilt? Heel lang was er sprake van technische beperkingen: tekst wás op het web nou eenmaal niet erg aantrekkelijk. Voor de nobele kunst van de typografie moest je ergens anders zijn. Tegenwoordig is dat niet meer zo. In dit artikel kun je lezen hoe je web fonts kunt gebruiken om meer controle te krijgen over de lettertypes die op je site gebruikt worden. Maar eerst: een stukje geschiedenis.

Een stukje geschiedenis

De mogelijkheid om een lettertype te kiezen voor een deel van een webpagina werd geïntroduceerd in 1995, toen Netscape Navigator de <font>-tag introduceerde. Met een font-tag kon een lettertype gekozen worden, maar alleen als dat lettertype al op de computer van de bezoeker geïnstalleerd was. Omdat je nooit zeker wist of een bezoeker een bepaald lettertype had, beperkten veel webbouwers zich tot een algemene categorie in plaats van een specifiek lettertype (sans-serif of serif, bijvoorbeeld).

Om de onzekerheid wat weg te nemen begon Microsoft in 1996 met het “Core fonts for the Web”-project. Een set lettertypes die eerder alleen bij Windows werden geleverd werd gratis en voor niets weggegeven. Het idee achter het project was dat softwaremakers, dus leveranciers van browsers en besturingssystemen, de lettertypes ook zouden gaan meeleveren, zodat ze op elke computer beschikbaar waren. Dat zou webbouwers dan weer in staat stellen om ervoor te zorgen dat hun webpagina er op, zeg, een Macintosh ongeveer hetzelfde uit zou zien als op een Windows-machine.

Dat laatste bleek lastiger dan gedacht, maar het eerste is zonder meer gelukt. De “Core fonts for the Web” werden inderdaad precies dat: lettertypes die iedereen kent en iedereen gebruikt. De meeste namen uit de collectie zullen ook niet-webbouwers bekend in de oren klinken: Arial, Courier New en Times New Roman, maar bijvoorbeeld ook Webdings. Dit blogartikel gebruikt Trebuchet MS, uit dezelfde collectie.

Web fonts: Lettertypes

Verder lezen

Monsterlijk snelle blogs met Jekyll

Op dit blog heb je al een aantal artikelen voorbij zien komen over WordPress, het content management systeem dat bijna alles kan. Mijn artikel over WordPress, van augustus vorig jaar, ging voornamelijk over hoe je een WordPress-blog zo snel mogelijk kon krijgen. Voor wie dat artikel nog niet gelezen heeft: je site snel maken komt neer op het zorgen dat er weinig gedaan hoeft te worden, zowel aan de server-kant als aan de client-kant, voornamelijk door slim gebruik te maken van caching.

Een snelle website maken met Jekyll: een supersnelle website met Jekyll

Helemaal aan het einde van stap 2 van dat artikel noemde ik kort de Super Cache-plug-in voor WordPress. SuperCache is een plug-in die – elke keer als je een wijziging maakt – je blog omzet in een mapje met statische HTML-bestanden. Op die manier hoeft WordPress niet geladen worden om de site op te dienen.

Waarom Jekyll?

Met Super Cache gebruik je WordPress eigenlijk als een programma om dat mapje te genereren. Op zich erg handig natuurlijk, met name als je veel waarde hecht aan de vele features van WordPress: de makkelijke webinterface, vele plug-ins, en meer van dat alles. Maar een WordPress-installatie moet wel ingesteld en bijgehouden worden. (Zowel het instellen als het bijhouden is bijna geen werk, met dank aan Installatron en de update-functies van WordPress, maar toch.) Als je er over nadenkt gebruik je nu relatief veel ‘bewegende’ onderdelen voor een relatief eenvoudige taak. Anders gezegd: een groot, complex CMS gebruiken om een handjevol HTML-bestandjes te genereren is een beetje als een spijkertje inslaan met een graafmachine.

Nee, wat je zou willen, als programmeur of iets technischere webbouwer, is een eenvoudig systeem. Liefst iets dat net zo’n beetje in zit tussen een ‘echt’ CMS als WordPress en ‘gewoon met de hand’ alle HTML-bestanden van je site in elkaar zetten. Dat laatste is veel werk, vooral omdat de meeste pagina’s van je site vaak op elkaar zullen lijken. Na de twintigste keer je header en footer gekopiëerd te hebben heb je daar vaak wel genoeg van.

Een snelle website maken met Jekyll: logo Jekyll

Een systeem om dit probleem aan te pakken heet een static site generator. Het zet een beschrijving van de inhoud en lay-out van een website om in volledige HTML-bestanden, klaar om geserveerd te worden. Dit artikel is een korte inleiding voor mijn favoriete generator: Jekyll.

Verder lezen

Het grote boze internet, deel 2: XSS en CSRF

XSS: Cross-Site ScriptingVorige week kon je lezen over SQL-injectie, een techniek die aanvallers kunnen gebruiken om de server waarop je website draait aan te vallen. Het artikel van deze week is opnieuw een technisch artikel en het laatste deel van de tweeluik over de beveiliging van je website. Het gaat over Cross-Site Scripting (XSS) en Cross-Site Request Forgery (CSRF): twee client-side aanvallen, waarbij dus jouw website misbruikt wordt voor de doelen van iemand anders.

XSS: Cross-Site Scripting

Cross Site Scripting is het injecteren van kwaadaardige JavaScript-code in pagina’s die een server terugstuurt. Een goed voorbeeld is een gastenboek: gebruikers schrijven berichtjes in een gastenboek, en de server reageert met de lijst van alle berichtjes. Als iemand een berichtje zou kunnen plaatsen met een uitvoerbare JavaScript-code, dan is er sprake van XSS. (Cross-Site Scripting wordt afgekort als XSS: de afkorting CSS was al bezet, en met een beetje fantasie lijkt een X op een kruisje, vandaar.)

Bij een XSS-aanval wordt er kortom een stukje uitvoerbare code in het midden van ‘normale’ tekst gestopt, in de hoop dat browsers het gaan uitvoeren.

R0b3rt zegt:
Leuke site! 
<script>document.location="https://r0b3rt.tk/";</script>

Cross Site Scripting komt, net als SQL-injectie, veel te vaak voor. En dat terwijl de oplossing relatief eenvoudig is.

String escaping

Wie vorige week meegelezen heeft moet hier al een zekere symmetrie zien. Ook voor het voorkomen van XSS is string escaping weer nuttig. In deel 1 was het de bedoeling om invoer van de gebruiker zo te bewerken dat de server het niet als uitvoerbare code zag. Nu doen we hetzelfde voor de client. Het idee is om tekst die de gebruiker invoert en de server teruggeeft, dus reacties in een gastenboek bijvoorbeeld, zo door de mangel te halen dat ze geen kwaad meer kunnen.

String escaping voor HTML is bijna nog makkelijker dan voor SQL. HTML heeft maar een klein aantal speciale tekens. Wie alle punthaken in de invoer door hun HTML-representaties vervangt is eigenlijk al klaar: alle openhaken (<) worden &lt; voor ‘less than’, en alle sluithaken (>) worden &gt;. Daarnaast is het netjes om alle ampersands (&) en aanhalingstekens (“) te vervangen, al kunnen die weinig kwaad. Klinkt redelijk eenvoudig, en dit is precies wat de PHP-functie htmlentities doet. Nu nog onthouden om consequent htmlentities te gebruiken en we zijn 100% beschermd tegen cross-site scripting. Toch?

Verder lezen

Het grote boze internet, deel 1: SQL-injectie

SQL-injecties: hoe kun je het voorkomen?Het is weer tijd voor een echt technisch artikel, dit keer bedoeld voor mensen die zelf scripts en applicaties schrijven in PHP. Vandaag ga ik het hebben over gevaren die je als PHP-programmeur kunt verwachten: veelvoorkomende fouten in PHP-code die kwaadwillenden kunnen misbruiken.

PHP staat bekend als een taal is die relatief vriendelijk is voor beginners. Helaas komt bij veilig programmeren in PHP, en het veilig schrijven van veilige webapplicaties in het algemeen, heel wat kijken. Vandaar dat dit artikel is opgedeeld in twee delen. Om maar meteen te beginnen, de SQL-injectie.

SQL-injectie

SQL-injectie is een techniek die vaak gebruikt wordt tegen kleinere sites. Zelfgebouwde reactiesystemen, gastenboeken en inlogformulieren zijn net zo vaak, of zelfs vaker, doelwit als grote banken en andere instellingen. De techniek draait om het invoegen (injecteren) van commando’s op plekken waar dit niet wordt verwacht. In velden waar je normaal je naam of bericht zou invoeren, vullen kwaadwillenden delen van SQL-queries in, in de hoop dat het systeem aan de andere kant van het formulier zo ingesteld is dat het de queries ‘blind’ gaat uitvoeren. Dat komt helaas vaker voor dan dat je zou denken.

SQL-injectie is misschien het beste te illustreren met een voorbeeld. Stel je eens voor dat een zuivelmerk een toetje op de markt zou brengen met de wat aparte, maar wel heel catchy naam “Yoghurt en een Gouden Ferrari.” Eenmaal in de supermarkt aangekomen bedenk je dat je wel zin hebt in wat nieuws na het eten, en vraagt dus:

Ik wil graag een pak Yoghurt en een Gouden Ferrari.

De meeste supermarktmedewerkers zouden een pak van die yoghurt-met-de-rare-naam van de schappen halen, of misschien een gewoon pak yoghurt. Misschien zouden ze zelfs hun hoofd schudden bij het verzoek – gouden Ferrari’s? In een buurtsuper? Gezond verstand zorgt er in ieder geval voor dat je niet per ongeluk met een sportwagen thuiskomt.

Computerprogramma’s hebben natuurlijk geen gezond verstand. Databases maken geen onderscheid tussen een heel normaal verzoek, zoals een query die het lidnummer van Fred opvraagt…

SELECT lidnr FROM leden WHERE naam='Fred'

…en deze query, die helemaal geen lidnummer maar de wachtwoorden van alle gebruikers opvraagt:

SELECT lidnr FROM leden WHERE naam='Fred' AND 1=0 UNION ALL
SELECT Password FROM mysql.user WHERE Password != ""; -- '

Kortom, SQL-injectie is dus het plaatsen van commando’s op plekken waar eigenlijk alleen data hoort. Door de invoer goed te kiezen is vaak veel schade toe te richten. Zelfs grote sites als Yahoo, The Pirate Bay en Sony hebben inbraken gehad waarbij de techniek gebruikt werd – en dat terwijl je script verdedigen tegen SQL-injectie in principe niet ingewikkeld is.

SQL-injecties: database inputs

Bron: Randall Munroe, xkcd.com

Verder lezen