Web formulieren beveiligen
Je vindt ze overal terug, web formulieren. Of het nu in de vorm van een contactformulier, bestelformulier of enquête is, “in the end they are all webforms”. Formulieren bevatten altijd data die van punt A naar punt B verzonden wordt. Deze data kan gevoelig van aard zijn of relatief onschuldig zoals een tevredenheid enquête. Feit blijft dat de persoon die het formulier invult wilt dat zijn gegevens alleen gezien worden door de rechtmatige ontvanger. Vergelijk het net als bij telefonie. Je hebt vermakelijk, gevoelige en zeer geheime gesprekken. Hoewel de ernst per type wat verscheelt wil je nooit dat andere personen meeluisteren met je gesprek.
Het belang van formulier beveiliging wordt dan ook te vaak onderschat. In deze post leggen we uit hoe je web formulier kunt beveiligen. We duiken hiermee niet de diepte in maar willen een goed gevoel geven van de mogelijkheden (sommige zijn zelfs zeer gemakkelijk en snel te realiseren) zodat je zelf aan de slag kunt om je formulieren beter te beveiligen.
SSL:
Juist SSL, Secure Socket Layer beveiliging. SSL is een protocol dat we vaak tegenkomen bij winkelwagen checkout systemen en andere pagina’s waar gevoelige informatie gedeeld wordt. Goede SSL beveiliging zorgt ervoor dat u de pagina veilig kunt oproepen via https. Dus bijvoorbeeld: //www.jarnobaselier.nl/ in plaats van //www.jarnobaselier.nl/ Afhankelijk van het type certificaat verschijnt bovenin de adresbalk een slotje of groene balk om aan te geven dat de huidige webpagina veilig is en dat u erop mag vertrouwen dat u communiceert zonder dat u afgeluisterd wordt met de personen achter de website die in de adresbalk staat (trust). Als u meer wilt lezen over SSL bekijk dan deze post.
We willen dus met SSL zeker de web formulieren beveiligen waarin om belangrijke data gevraagd wordt. Het is belangrijk om het formulier zelf te beveiligen met SSL en het verwerkingsscript moet beveiligd zijn. Het verwerkingsscript is het script die de data verwerkt, opslaat en verstuurt naar de juiste personen of database nadat er op “Verzenden” is geklikt. Als beide niet beveiligd zijn dan:
- is een MitM attack (Man in the Middle Attack) zeer gemakkelijk te realiseren. Dit betekend dat alle data die verzonden wordt bekeken kan worden.
- zullen veel gebruikers de webpagina verlaten omdat deze geen actieve beveiliging (de groene balk) zien en dus geen gegevens achter durven laten.
Maar let op: vaak als uw hosting provider SSL op uw website actief gemaakt heeft dan kan de website nog steeds onveilig (over http) bekeken worden. Kortom, http en https werken beide. U moet ervoor zorgen dat alle links naar uw formulier absolute links zijn met https ervoor en geen relatieve links. Dit omdat relatieve links altijd naar de onveilige (http) versie van de bestemmingspagina gaan. Als alle links op je website op de juiste manier naar het beveiligde formulier linken is de volgende stap het onmogelijk te maken om deze beveiligde pagina nog via http (onveilig) te bezoeken. Dit kunt u doen op diverse manieren. Bijvoorbeeld via een .htaccess redirect, javascript, php etc. Ook zijn er hosting providers die een https only directory hebben. Files die hierin staan zijn niet via http te benaderen. Dit werkt alleen wat lastiger omdat CMS systemen geen losse html of php bestanden hebben voor iedere individuele pagina. Bij CMS systemen is het makkelijker om met een script te werken.
SSL beveiligde formulieren zijn vooral belangrijk voor de veiligheid en betrouwbaarheid van de gegevens. Door uw formulieren met SSL te beveiligen zorgt u ervoor dat u vertrouwen uitstraalt.
Probeer er ook voor te zorgen dat u de “secure” cookie flag aanzet als u cookies gebruikt zodat ook deze veilig verzonden worden en niet “opnieuw afgespeeld” kunnen worden. Probeer ook een sterke mate van encryptie te forceren. Als u dit niet doet zullen sommige browsers een lagere encryptie standaard pakken omdat deze sneller zijn (snelheid boven veiligheid).
Wat vaak vergeten wordt is wat er met de data gebeurt nadat deze veilig verzonden is. Hoe wordt de data opgeslagen (beveiligd of niet) en hoe komt de data daar. Dit gedeelte wordt niet gezien door degene die het formulier ingevuld heeft maar is zeker net zo belangrijk.
E-mail:
Meestal wordt de data naar een of meerdere personen gemaild. Op zich een prima procedure omdat e-mail door veel website bezitters regelmatig gecontroleerd wordt. Echter is e-mail niet veilig. De e-mail zelf kan bij binnenkomst afgeluisterd worden of kan gelezen worden als iemand uw computer infiltreert. Het is dus beter om het systeem e-mail te laten sturen naar een beveiligde website waar u de ingevulde data kunt zien.
Opslaan in database:
Vaak wordt data primair of secundair ook opgeslagen in een database. Stel voor dat de e-mail een keer crashed dan zijn alle gegevens nog steeds aanwezig in de database. Een backup dus. Om dit echter goed te regelen kan lastig zijn (lees, kan tijdsintensief en dus kostbaar zijn). U moet ervoor zorgen dat de date encrypted (via SSL of PGP (Pretty Good Privacy)) opgeslagen wordt in de database zodat het niet direct leesbaar is voor iemand die inlogt in de database of de database backups. Daarnaast moet de user interface waarmee u de data uit de database bekijkt ook volledig veilig zijn.
U ziet dus dat een web formulier goed beveiligen vele facetten kent. Daarom gaat het bij de meeste kleine ondernemingen vaak mis terwijl dit voor u en uw website bezoekers zo belangrijk is.
CAPTCHA code:
Maar er zit meer in de trukendoos. Heeft u weleens van een CAPTCHA code gehoord? Waarschijnlijk wel als ik zeg dat dit dat plaatje is met moeilijk leesbare letters en cijfers die op de juiste manier overgenomen moeten worden alvorens u het formulier kunt verzenden. Een CAPTCHA code is vervelend voor de bezoekers maar zeer belangrijk in het tegenhouden van SPAM. Er circuleren vele automatische bots op het internet die formulieren automatisch invullen met reclame. De meeste bots kunnen tekst uit afbeeldingen niet lezen en het formulier dus niet verzonden. Implementatie van een CAPTCHA code kan veel SPAM voorkomen maar dient pas geïmplanteerd te worden als u de binnenkomende SPAM als “last” gaat ervaren omdat het toch een extra “obstakel” voor uw bezoeker is om het formulier in te vullen. Als u een CAPTCHA code implementeert zorg er dan wel voor dat het formulier automatische her-generatie van gegevens heeft zodat niet alle ingevulde gegevens weg zijn als de bezoeker de CAPTCHA code foutief invult. Dan bestaat er een grote kans dat de bezoeker de pagina verlaat.
Login pagina:
Ook inlog formulieren zijn formulieren. U bent gewend dat hier om een gebruikersnaam en een wachtwoord gevraagd wordt. Beter en veiliger is nog om OpenID of 2-factor authenticatie te gebruiken. Deze methodes zijn vaak prima te integreren en verhogen de veiligheid van het login formulier.
OpenID is een login methode om in te kunnen loggen op meerdere websites met maar 1 account, je OpenID account! Een gebruiker die inlogd met OpenID wordt (beveiligd) doorgestuurd naar de OpenID pagina waar de gebruiker inlogt. Na succesvol inloggen wordt de gebruiker weer teruggestuurd naar de pagina waar deze succesvol ingelogd wordt.
2-factor authenticatie (two factor authentication) is een dubbele authenticatie methode. Je gebruikt dus 2 van de 3 beveiligingsmethodes:
- iets dat je weet (b.v. een wachtwoord)
- iets dat je hebt (bijvoorbeeld een token-key/smartcard. Denk hierbij aan de inlogmethode voor online bankieren.)
- iets dat je bent (vingerafdruk, iris scanner)
Een veel gebruikte methode is om in te loggen met een gebruikersnaam + wachtwoord + token (zoals bijvoorbeeld met het inloggen bij de bank).
Inhoud validatie en Server Side validatie:
Alle door het formulier verzonden data moet gevalideerd worden door het verwerkingsscript en de database engine. Alle Javascript, speciale tekens, script tags, HTML etc. moet verwijderd worden of op een speciale manier verwerkt worden zonder dat het output genereerd. Als dit niet gebeurt kunnen malafide script op uw formulier ervoor zorgen dat data onderschept wordt of erger, dat bijvoorbeeld uw complete database onderschept wordt. Als deze technieken wordt toegepast noemen ze dat XSS (Cross Site Scripting) en SQL Injection. Cross Site scripting en SQL Injections zijn de meest onderschatte en gevaarlijkste hack mogelijkheden, mede omdat er makkelijke en gratis tools beschikbaar zijn om deze zwakheden te misbruiken.
Conclusie:
Bij een website beveiligen komt heel wat kijken. Dit onderwerp gaat alleen nog maar over formulieren en bevat een goede maar geen volledige lijst van belangrijke zaken die in acht genomen moeten worden als u uw web formulier(en) wilt beveiligen. Omdat formulieren een belangrijk aspect zijn van vele moderne websites is het belangrijk om deze formulieren zo veilig mogelijk te maken. Dit is fijn voor de gebruiker en dus ook voor u.