Wat is de OWASP top-10?

10 belangrijkste applicatie veiligheidsrisico’s

Het is onwijs belangrijk om de 10 belangrijkste veiligheidsrisico’s uit de OWASP top-10 op te lossen. Door deze veiligheidsrisico’s dicht te timmeren, maak je het voor een kwaadwillende al behoorlijk lastig om (ongewenst) toegang te verlenen.

1. Injectie

De meest gebruikte injectie om ongewenst toegang te krijgen door hackers, is de SQL injectie. Met een SQL injectie voert de hacker een query direct uit op de database, waarmee diegene zichzelf toegang kan verlenen. Het kan ook zijn dat mede door een SQL injectie de hele applicatie niet meer werkt en alle data verloren is gegaan.

De bekendste injectiemethoden zijn:

• SQL injectie

• OS commando injectie

• LDAP injectie

2. Authenticatie fouten

Wanneer je een webapplicatie met een gebruikersaccount, dan is het zeer aannemelijk om te zeggen dat er een authenticatiesysteem wordt gebruikt. Het terugsturen van foutmeldingen die een hacker potentieel kunnen helpen bij het vaststellen of een gebruikersaccount bestaat vormt een behoorlijk risico.

3. Gevoelige data

Vrijwel alle webapplicaties werken met zeer gevoelige data. Het is dus belangrijk om deze goed af te schermen, door middel van een goede encryptie. Inmiddels hebben wij hier ook een wetgeving dat ons verplicht om goed met gevoelige data om te gaan, genaamd de AVG wetgeving. 

4. Externe XML entities (XXE)

Hackers kunnen door middel van een XML bestand zichzelf toegang verlenen tot bestanden en programma’s op het besturingssysteem van de server. Dit komt met name door gedateerde XML verwerkers. Het zou ook mogelijk kunnen zijn dat de hacker data aan koppelingen, zoals bijvoorbeeld met een boekhoudpakket, door kan sturen met foutieve data en daardoor geld kan overmaken naar een bankrekening.

5. Rollen en rechtensysteem kwetsbaarheden

Wanneer een gebruiker foutieve rechten krijgt bij zijn rol, kan de gebruiker eventueel meer handelingen verrichten dan gewenst is. Het is daarom erg belangrijk dat het rollen- en rechtensysteem goed op elkaar afgestemd en getest wordt.

6. Foutieve configuratie

Een ontwikkelaar gebruikt configuratiebestanden om zijn server en frameworks in te stellen, die absoluut niet inzichtelijk mogen zijn voor het openbare publiek. Het komt verrassend vaak genoeg voor dat een ontwikkelaar zijn configuratie niet op orde brengt voor het besturingssysteem van de server en van de gebruikte frameworks, wat de hacker in staat kan stellen om toegang te verlenen.

7. Cross-Site Scripting (XSS)

Als een webapplicatie onvoldoende validatie toepast op de te verwerken data, kan het voorkomen dat een hacker code injecteert in de webapplicatie. Hiermee kan de hacker bijvoorbeeld onveilige bestanden plaatsen op de computer van een andere gebruiker, maar ook de webapplicatie volledig vernietigen.

8. Onveilige serialisatie

Er zijn webapplicaties die objecten omzetten naar tekst, al voor deze in de database opgeslagen worden. Wanneer een webapplicatie hiervan gebruik maakt en niet voldoende controles uitvoert op de ingevulde data, kan de hacker commando’s uitvoeren op het besturingssysteem van de gebruikte server.

9. Gebruik van software met bekende kwetsbaarheden

Vaak maakt een ontwikkelaar gebruik van open-source frameworks of stukken software dat door andere ontwikkelt worden. Als deze niet tijdig geüpdatet worden door de makers en de gebruikers, kunnen veiligheidsrisico’s benut worden door hackers.

10. Onvoldoende logging en monitoring

Feitje, een lek wordt gemiddeld pas na 200 dagen gemeld bij de makers van de webapplicatie. Als de makers van de webapplicatie onvoldoende of zelfs helemaal geen logbestanden bijhoudt, waarin vastgehouden wordt wat er precies is gegaan binnen de applicatie, kan het heel lang duren voor de makers het lek boven water krijgen.

Met behulp van monitoring heeft een ontwikkelaar tevens veel sneller in de gaten of een webapplicatie nog wel bereikbaar is en kan hierop beter reageren wanneer dit niet het geval is.

Hoe gaat CodeBros met OWASP top-10 om?

Voor iedere webapplicatie opgeleverd wordt, testen wij de applicatie uitvoerig tegen de veiligheidsrisico’s die hierboven zijn omschreven. Mocht het zijn dat wij constateren dat één van de testen negatief uitpakt, zullen wij de applicatie ook niet opleveren.

Wij zorgen zelf aan de hand van een onderhoudscontract dat al het door ons gebruikte software en frameworks altijd up-to-date zijn en standaard maken wij een dagelijkse back-up van al onze data. Hiermee verkleinen wij het risico op veiligheidslekken na oplevering en voorkomen wij schade bij jou als klant dat veroorzaakt wordt door een hacker.

Het komt uiteraard voor dat wij met gevoelige data werken. In dit soort scenario’s schrijven wij extra geautomatiseerde testen, die controles uitvoeren op basis van encryptie en andere veiligheidslekken afkomstig uit de OWASP top-10. Doordat deze testen geautomatiseerd zijn, kunnen wij voor iedere nieuwe release controleren of de data nog steeds veilig bewaard wordt. Mocht dit niet het geval zijn, dan kunnen wij de nieuwe release ook niet opleveren.

Tot slot bieden wij de broncode van de webapplicatie niet openbaar aan en blijft dit veilig op de door ons aangeboden eigen servers staan. Dit blijft in bezit tussen ons en jou als klant.