Veilig ontwikkelen met de OWASP Top 10: case VluchtelingenWerk Nederland

10-10-2017
VluchtelingenWerk Nederland

Dit artikel is gepubliceerd in het magazine van AG-Connect
Bouw je een systeem waarin gebruikers een blog kunnen schrijven, dan is security misschien geen topprioriteit. Maar als je een toepassing ontwikkelt waarin veel privacygevoelige informatie staat, dan is het juist essentieel. Hoe garandeer je veilige code en hou je hackers buiten de deur? Wij pasten de OWASP top 10 toe bij de ontwikkeling van een nieuw platform voor VluchtelingenWerk Nederland.

Zeer privacygevoelige informatie

Het oude systeem waarin VluchtelingenWerk Nederland alles registreert rondom procedures van vluchtelingen was flink verouderd. Een nieuw systeem moest de duizenden medewerkers en vrijwilligers beter gaan ondersteunen in hun werk. Deze medewerkers begeleiden vluchtelingen bij hun juridische procedure en helpen bij het invullen van belangrijke formulieren, het aanvragen van uitkeringen, het zoeken van woonruimte en werk en ga zo maar door.

Je kunt je voorstellen dat zo’n systeem persoonlijke dossiers vol zeer privacygevoelige informatie ontsluit. Deze dossiers bevatten niet alleen NAW-gegevens en de status van iemands aanvraag, maar ook of iemand bijvoorbeeld gezocht wordt door de overheid in het land van herkomst. Ook staat in zo’n dossier het vluchtverhaal met daarin de redenen waarom iemand gevlucht is. Informatie over nareizigers - familie die ook naar Nederland wil komen - is eveneens erg gevoelig. Security van de code en het zorgvuldig inrichten van de toegang tot deze informatie, waren dan ook topprioriteit bij de ontwikkeling van het nieuwe systeem.

Een gedegen securitycomponent: OWASP top 10

Veilig ontwikkelen omvat twee zaken: enerzijds heb je te maken met de veiligheid van code. Maak je daar kostbare fouten in? Dan is je systeem te hacken. Anderzijds is het essentieel om de toegang tot bepaalde informatie met behulp van rollen en rechten goed in te richten. Voor het eerste deel zijn we aan de slag gegaan met behulp van de OWASP top 10.

De OWASP Top 10 is een overzicht van typen kwetsbaarheden die volgens beveiligingsexperts het meest kritisch zijn als het gaat om webapplicaties. Het is een soort standaardlijst van zaken waar je aan moet denken als je je systeem goed wil beveiligen. Het is helaas geen kant-en-klare afvinklijst; hoe je het implementeert, hangt af van de toepassing die je bouwt en de eisen die er gesteld worden. Als je deze top 10 volgt, is de veiligheid van je toepassing dik in orde. Hieronder lees je hoe wij de 10 aandachtspunten voor dit project hebben aangepakt.

A1 Injection
Injectiekwetsbaarheden zoals sql-, os commando- of ldap-injectie ontstaan wanneer niet-geverifieerde data door een hacker wordt verzonden als onderdeel van een commando of query. Kort gezegd: het moet onmogelijk zijn om SQL-code in te voeren in een formulier. Dat hebben we technisch opgelost door geparametriseerde statements te gebruiken.

A2-Broken Authentication and Session Management
Het komt regelmatig voor dat autorisaties en sessiebeheer niet correct zijn geïmplementeerd, waardoor het mogelijk is om wachtwoorden, sleutels of sessietokens te achterhalen waarmee een hacker de identiteit van een andere gebruikers aan kan nemen. We hebben ervoor gezorgd dat wachtwoorden nergens worden opgeslagen (alleen een niet terug te herleiden hash). Ze worden ook niet gelogd op de server.

A3-Cross-Site Scripting (XSS)
In feite is dit net zoiets als nummer 1 van deze lijst, maar dan voor Javascript in plaats van SQL. Het moet onmogelijk zijn om Javascript of html in te voeren in formulieren. Dit wordt opgelost door alle invoer op de server te valideren.

A4-Insecure Direct Object Reference
Een Insecure Direct Object Reference ontstaat wanneer een ontwikkelaar onbedoeld verwijst naar een bestand, map of de sleutel van een gegevensbestand. In ons geval betekende dat: dossiernummers mogen niet makkelijk te raden zijn. Als je eenmaal weet hoe een link naar een volledig dossier er uitziet, zou het niet mogelijk moeten zijn om de link naar het dossier van een andere vluchteling af te leiden. Daar hebben we voor gezorgd. Ook controleert het systeem - iedere keer als een gebruiker een dossier opent - of deze specifieke persoon dit specifieke dossier(onderdeel) mag inzien.

A5-Security Misconfiguration
Deze eis heeft te maken met het up-to-date houden van software en het niet gebruiken van standaardwachtwoorden. Je zou het niet verwachten, maar het komt regelmatig voor dat er nog standaardwachtwoorden (user: admin, password: admin) worden gebruikt. Het klinkt vanzelfsprekend, maar ook controle hierop is noodzakelijk.

A6-Sensitive Data Exposure
Gevoelige gegevens moet je extra beschermen met behulp van versleuteling of andere speciale voorzorgsmaatregelen. Zorg dat alle data die ‘over de lijn gaat’ versleuteld is. Voor VluchtelingenWerk wordt er geen data naar de browser gestuurd, als iemand geen rechten heeft. Bovendien is zelfs het dataverkeer tussen de applicatie en de databaseserver SSL-encrypted, zodat ook niemand die fysiek aanwezig is op het kantoor gegevens kan onderscheppen. Zo ver gaan we meestal niet, maar ook dit risico kun je dus ondervangen.

A7-Missing Function Level Access Control
De meeste applicaties controleren toegang voordat de gevraagde data zichtbaar wordt in de gebruikersinterface. Dat geldt ook voor die van VluchtelingenWerk Nederland. Het is noodzakelijk dat dezelfde toegangscontrole als in de client-applicatie ook op de server wordt toegepast. Verder is het belangrijk om te loggen wat gebruikers doen in de applicatie en de invoer steeds te valideren. In een veld voor een e-mailadres hoort bijvoorbeeld een @ te zitten. Om aan deze eis te voldoen hebben we elke API call beveiligd. Je kunt geen enkele API aanroepen als je niet bent ingelogd, dat is de minimale eis. Met testen was dit overigens een behoorlijke klus, omdat we 40 a 50 API’s met verschillende rechten moesten nalopen. Maar het is noodzakelijk werk.

A8-Cross-Site Request Forgery (CRFS)
Nummer acht op de lijst heeft te maken met het kapen van sessies door de login van de ene applicatie te gebruiken voor een andere. Stel je logt in op de webapplicatie van VluchtelingenWerk, een hacker kan dan proberen in een ander venster in dezelfde browser jouw login te gebruiken. Deze mogelijkheid hebben we dichtgetimmerd.

A9-Using Components with Known Vulnerabilities
Componenten zoals libraries, frameworks en andere software-modules draaien vaak met volledige autorisatie. Loop daarom alle versies van libraries die je gebruikt na om te zien of er geen securityproblemen in zitten. Het is een hoop handwerk, maar wel essentieel als je een veilige toepassing wil.

A10-Unvalidated Redirects and Forwards
En tot slot nummer tien: niet-gevalideerde redirects. Als een applicatie je doorverwijst naar een andere pagina, en dat wordt niet gevalideerd, dan kan een hacker je omleiden naar phishing- of malwaresites of forwards gebruiken voor toegang tot ongeautoriseerde pagina's. We hebben ervoor gezorgd dat URL’s nooit worden samengesteld uit door de gebruiker ingevoerde gegevens, zonder dat deze gevalideerd zijn.

3 tips voor een veilige en functionele webapplicatie

Als je deze top 10 gevolgd hebt en op een succesvolle manier geïmplementeerd hebt, dan is je applicatie al goed beveiligd. Maar dan ben je er nog niet. Hieronder een aantal tips - aan de hand van onze case - om de security naar een nog hoger niveau te tillen en je applicatie functioneel te houden.

1. Veiligheid vs. functionaliteit: wat is belangrijker?
Dat laatste - het functioneel houden van de applicatie - is meteen de kern van deze eerste tip. Soms is veiligheid niet het allerbelangrijkste. Eén van de punten uit de OWASP top 10 is dat URL’s niet makkelijk te raden moeten zijn. Daar hebben we aan voldaan. Maar eigenlijk is het nog strenger: voor iedere gebruiker zou de verwijzing naar een vluchtelingendossier er anders uit moeten zien. Een anonieme url, zonder dossiernummer dus. Maar dat zou betekenen dat medewerkers geen links naar dossiers met elkaar kunnen uitwisselen. Dat is erg onpraktisch. Maak dus steeds de afweging wat belangrijker is; moet het extreem veilig zijn of wil je niet in functionaliteit inboeten?

2. Rollen, rechten en componenten
Voor VluchtelingenWerk was het - zoals gezegd - ook noodzaak om de toegang tot informatie goed in te richten. Als slechts een paar medewerkers met een systeem werken, dan licht je ze door en laat je ze een contract tekenen. Maar bij VluchtelingenWerk Nederland zijn duizenden vrijwilligers werkzaam, vaak maar een paar uur per week. Die kun je niet allemaal doorlichten. En ze hebben allemaal een ander soort rol. De een is bijvoorbeeld docent Nederlands, die mag alleen de naam inzien en cursusinformatie zoals cijfers. Maar niet hoe het staat met de asielprocedure of nareizigers.

Daarom was het noodzakelijk om een hele scherpe scheiding te maken tussen de componenten van het dossier enerzijds en de rollen en rechten anderzijds. Het inrichten hiervan moet zeer precies gebeuren. Alle informatie is gecategoriseerd: financieel, juridisch, NAW. Afhankelijk van de rechten, ziet een gebruiker bepaalde delen van een dossier wel of niet. De delen die hij niet mag zien, gaan ook niet over de lijn. Dus mocht iemand het netwerkverkeer onderscheppen, dan is die informatie veilig.

3. Test, test, test en laat een penetratietest uitvoeren
Besteed veel aandacht aan intern testwerk; doe niet alleen scenariotesten, maar gebruik ook tools die je op internet vindt om te kijken of je de applicatie zelf kunt hacken. Natuurlijk is het noodzakelijk om te testen met echte data. Maar ook dat is privacygevoelig. Op onze systemen stond daarom nergens productiegegevens. Ook de acceptatieomgeving stond niet bij ons, maar bij VluchtelingenWerk zelf. Dat had tot gevolg dat we alle testdata zelf moesten bedenken. Wederom iets waar veel tijd in gaat zitten. Maar als veiligheid zo belangrijk is, dan is het die tijd en moeite wel waard.

Laat tot slot een externe partij een penetratietest uitvoeren. De partij die wij daarvoor inschakelden, vond een kleine kwetsbaarheid. Een functionaliteit die we niet goed hadden afgeschermd. Ook al let je nog zo goed op, je kunt altijd iets over het hoofd zien.

Het systeem voor VluchtelingenWerk is zo ingericht, dat ze zelf de beveiliging kunnen inrichten en aanpassen waar nodig. Ze kunnen onbeperkt rollen aanmaken en rechten toekennen. Daar zit nu het grootste veiligheidsrisico. Met training en uitleg kom je een heel eind, maar fouten maken blijft menselijk. Dat geldt net zo goed voor ontwikkelaars. Wie het systeem dan ook beheert, het zou voor het waarborgen van de veiligheid verstandig zijn om de penetratietest regelmatig te laten herhalen.

Edwin van der Elst & Peter Zuiddam
Software Ontwikkelaar & Informatie Analist