Beveiliging webapplicaties OWASP top 10

Veiligheidsrisico’s in webapplicaties vermijden met de OWASP top 10

Het Open Web Application Security Project, of kortweg OWASP, focust zich op het verbeteren van softwareveiligheid door individuen en organisaties te informeren en sensibiliseren.. Hun top 10 van meest kritische veiligheidsrisico’s bij webapplicaties is erg belangrijk voor professionele webbouwers. Gezien we bij Datalink staan voor toonaangevende en innovatieve online platformen, houden we onze oren en ogen gespitst op vlak van cybersecurity trends. OWASP helpt ons hierbij.

OWASP

Enter OWASP! Het Open Web Application Security Project, of kortweg OWASP, focust zich dus op het verbeteren van softwareveiligheid door het informeren van individuen en ondernemingen. OWASP bestaat uit een open community met een groot aantal beveiligingsexperts. De organisatie verzamelt en analyseert data van organisaties uit verschillende landen om veiligheidsrisico’s op te lijsten en richtlijnen te geven voor platformen.

De OWASP top 10

De OWASP Top 10 is een lijst van de 10 gevaarlijkste en meest voorkomende veiligheidsrisico’s op het internet, gebaseerd op meer dan 500.000 kwetsbaarheden in meer dan 1000 applicaties. Het is volgens het Belgische centrum voor cybersecurity dan ook een krachtig bewustmakingsdocument voor beveiliging van webapplicaties dat webbouwers in acht dienen te nemen om steeds veilige code en software te ontwikkelen. Benieuwd naar de dreigingen die er in de top tien staan opgenomen?

Injectie

Volgens de OWASP zijn injection kwetsbaarheden de grootste risicofactor voor web applicaties. SQL injecties doen zich voor wanneer een cybercrimineel SQL queries op zo’n manier manipuleert dat deze onbedoelde commando’s gaat uitoefenen. Zo’n actie is mogelijk wanneer de query op een onveilige manier is opgebouwd en afhankelijk is van één of meerdere parameters die ingevuld moeten worden door een gebruiker. Verwerft een kwaadwillig persoon toegang tot je query? Dan heeft deze ook toegang tot je data en kan hij deze data wijzigen, corrupt maken of zelfs verwijderen.

Een voorbeeld: een SQL-query ziet er bijvoorbeeld als volgt uit=> “DELETE FROM my_data WHERE ‘id’ = “+inputID;
Stel dat <inputID> kan worden ingevuld met behulp van een formulier op een website of applicatie.
In plaats van een numerieke ID in te vullen, kan de gebruiker eventueel het volgende invullen: 1 OR 1=1
In dit voorbeeld zullen bijgevolg alle records in de tabel my_data verwijderd worden.

Gebroken authenticatie en sessiebeheer

OWASP geeft aan dat applicatiefuncties die te maken hebben met authenticatie en sessiebeheer vaak foutief geïmplementeerd worden. Hierdoor wordt het voor cybercriminelen mogelijk om toegang te verkrijgen tot wachtwoorden sessietokens en ‘sleutels’. In sommige gevallen maakt deze kwetsbaarheid het zelfs mogelijk om tijdelijk of permanent de identiteit van andere gebruikers over te nemen. Onder incorrecte implementatie van sessiebeheer en authenticatie vallen een heel aantal fouten. Dit kan gaan van het niet instellen van een tijdslimiet op gebruikerssessies tot  het ontbreken van encryptie bij opslag van data.

Graag een voorbeeldje? Er zijn een aantal manieren om aan “Session hijacking” te doen. Bij “Session Sniffing” kan de aanvaller bijvoorbeeld een sessie vinden genaamd “UserID”. Indien deze data niet geëncrypteerd is kan de aanvaller deze sessie simpelweg aanpassen naar een andere ID om zo toegang te krijgen tot een ander account van de applicatie. Een andere veelvoorkomende manier van Session Hijacking is “cross-site scripting” waarbij de aanvaller een stukje malafide code gebruikt om bestaande sessies te lezen. Zie hieronder.

Blootstelling van gevoelige data

Veel webapplicaties en API’s zorgen volgens OWASP onvoldoende voor een optimale bescherming van gevoelige data zoals financiële gegevens of persoonsgegevens. Gevoelige gegevens enkel afgeschermd opslaan, bijvoorbeeld in een database, is namelijk niet voldoende. Zo wordt deze data in gevaar gebracht door een gebrek aan encryptie tijdens opslag of in transit. Dit heeft als gevolg dat hackers makkelijk toegang kunnen verkrijgen om deze gevoelige data te stelen of aan te passen om credit card fraude te plegen of identiteitsgegevens te stelen.

Graag iets meer uitleg? Bij API’s is authenticatie superbelangrijk. Dit zorgt ervoor dat de derde partij toegang heeft tot de beschikbare data. Indien deze authenticatie niet volgens de huidige normen gebeurt, is de kans groot dat een aanvaller aan de haal kan gaan met data. Oauth 2.0 is de huidige standaard als het aankomt op API authenticatie. De applicatie die de API wilt gebruiken heeft eerst en vooral een “access token” nodig, die enkel kan verkregen worden via de oorspronkelijke applicatie. In het beste geval vervalt deze “access token” ook na een bepaalde tijd. Na het vervallen zal de applicatie die de API wilt gebruiken een nieuwe access token moeten aanvragen met behulp van een “refresh token”, dat ook werd aangeleverd door de oorspronkelijke applicatie.

XML External Entities (XXE)

Veel oudere of slecht geconfigureerde XML processoren evalueren externe entiteitsreferenties binnen XML documenten. Zo’n externe entiteiten kunnen gebruikt worden om interne documenten bloot te stellen.

Ontbrekende of defecte toegangscontrole

Nog een veelvoorkomend probleem is het feit dat toegangsrechten op regelmatige basis onvoldoende worden voorzien of beperkt. Hierdoor verkrijgen hackers gemakkelijk ongeautoriseerde toegang tot bepaalde functionaliteiten en data zoals gebruikersaccount en vertrouwelijke documenten én kunnen ze in veel gevallen zelfs user accounts en toegangsrechten aanpassen.

Misconfiguratie van beveiligingsvoorzieningen

Een webapplicatie bestaat meestal uit een aantal samenwerkende componenten.  Zo zijn applicaties uitbreidbaar met plug-ins, thema’s en andere elementen. Elk component houdt risico’s in voor de veiligheid van de webapplicatie. Daarom is het belangrijk dat de standaard instellingen veilig (en dus streng) zijn, zodat het CMS meteen veilig gebruikt kan worden. Dit houdt bijvoorbeeld in dat onnodige features automatisch uitgeschakeld zijn, er geen default accounts en paswoorden aanwezig zijn en dat het tonen van foutrapporten automatisch uitgeschakeld is. Misconfiguratie van beveiliging is meestal het resultaat van onstabiele standaard configuraties, open cloud opslag, incomplete of ad hoc configuraties, onduidelijke foutmeldingen die soms zelfs gevoelige data bevatten. Naast een optimale beveiliging is het ook erg belangrijk dat applicaties, API’s en systemen tijdig gepatched en geüpgraded worden. Bij Datalink voorzien wij bijvoorbeeld strenge onderhoudsroutines.

Cross-Site Scripting aanvallen (XSS)

Veel websites bevatten scripts die uitgevoerd worden door de webbrowser. Cross-Site Scripting stelt een cybercrimineel in staat om zijn eigen script te injecteren in een normaliter betrouwbare website. Aangezien het malafide script vanuit de webpagina zelf wordt uitgevoerd, heeft de browser geen idee dat het script onbetrouwbaar is. Het script zal dus gewoon uitgevoerd worden en geeft toegang tot cookies, sessietokens en andere elementen die in de HTML pagina zitten. Gelukkig bestaan er een aantal methodes om XSS kwetsbaarheden tegen te gaan. Deze methodes houden vooral in dat onbetrouwbare gegevens gefilterd worden afhankelijk van de HTML context waarin ze terecht zullen komen. Ook is het nuttig om input te valideren aan de hand van een aantal verwachte eigenschappen zoals de vereiste dat input numeriek dient te zijn.

Insecure Deserialization

Dit is een vrij recente toevoeging aan de OWASP top 10. Ik verduidelijk even hoe het werkt: in een applicatie wordt voortdurend data uitgewisseld naar bijvoorbeeld een ander script binnen de applicatie of de database. Deze data wordt “serialized” en omgevormd naar een byte stream. De code die deze byte stream ontvangt gaat deze byte stream “deserialiseren” om tot de oorspronkelijke data te komen. Indien de byte-stream niet wordt gevalideerd door de ontvangende software, kan de aanvaller eender welke data doorsturen naar de eindbestemming en op die manier eventueel andere eigen scripts aanspreken. Het is dus zeer belangrijk om alle user-input te valideren om geen onverwachte code uit te voeren.

Het gebruik van componenten met gekende kwetsbaarheden

Externe componenten zoals plug-ins, frameworks en andere modules hebben vaak volledige autorisatie tijdens het draaien van een applicatie. Is één van deze componenten kwetsbaar? Dan brengt dit component de gehele applicatie in gevaar. Onderzoek van Detectify uit 2016 wijst uit dat veel ontwikkelaars zich enkel op de veiligheid van hun eigen code concentreren en vergeten dat ze ook heel wat code hebben geïmporteerd die afkomstig is van derden. Dit blijkt nog vaker het geval bij webontwikkeling met open-source content management systemen. CMS-ontwikkelaars gebruiken in het algemeen namelijk veel verschillende modules, plug-ins of andere extensies die ze niet zelf ontwikkeld hebben. Het is dus van groot belang dat deze toegevoegde componenten worden gecontroleerd wat betreft beveiliging voordat ze beschikbaar worden gesteld aan het publiek.

Onvoldoende loggen en monitoren

OWASP geeft aan dat de gemiddelde tijd waarna een inbraak in een website of webapplicatie opgemerkt wordt meer dan 200 dagen is. Deze inbreuk wordt bovendien meestal door derden gedetecteerd en niet door de interne processen of de monitoring. Het is dus duidelijk dat onvoldoende logging en monitoring in combinatie met ontbrekende of ineffectieve integratie van incident management als gevolg hebben dat cybercriminelen systemen kunnen aanvallen of penetreren en zo gevoelige data kunnen bekijken, wijzigen en vernietigen.

Niet niks hé, die gevaren die er kunnen schuilgaan in de code van websites en webapplicaties? Naast de top 10 zijn er uiteraard nog veel meer risico’s op de loer. Als eigenaar van een website of webapplicatie zorg je er best voor dat je platform, je kostbare data én alle opgeslagen persoonsgegevens best optimaal beveiligd zijn, wil je hacks en natuurlijk ook sancties van de Belgische Gegevensbeschermingsautoriteit vermijden.

Is jouw website of webapplicatie met de grootste zorg gebouwd? Of wil je de veiligheid van je site of platform graag laten nakijken? Als developer met een specialisatie in ethical hacking help ik je samen met ons team heel graag verder! Neem vandaag nog contact op.

Scroll naar boven