Webapplicaties zijn de belangrijkste vectoren die aanvallers gebruiken om inbreuken te plegen. Volgens Verizon's "Data Breach Investigations Report" (PDF) waren webapplicaties de toegangspoort voor ongeveer 70% van alle onderzochte inbreuken.

Na het uitvoeren van meer dan 300 penetratietesten voor webapplicaties, begrijp ik waarom. Ontwikkelaars blijven hetzelfde maken beveiligingsmisstappen die kwetsbaarheden creëren. Ze gebruiken vaak geen veilige frameworks en proberen zelf beveiligingscode en authenticatieprocessen te schrijven.

Het is belangrijk op te merken hoeveel druk ontwikkelaars hebben om producten snel op de markt te brengen. Ze worden beloond op basis van het aantal functies dat ze zo snel mogelijk kunnen introduceren, niet noodzakelijkerwijs zo veilig mogelijk. Dit leidt tot het nemen van beveiligingssnelkoppelingen en, op de weg, kwetsbaarheden in webapplicaties.

Vijf lessen voor veiligere apps

Pentesters speel de rol van advocaat van de duivel en reverse-engineering van wat applicatie-ontwikkelaars maken om te laten zien waar en hoe aanvallers toegang krijgen. De resultaten hebben veelvoorkomende fundamentele fouten aan het licht gebracht. Hier volgen vijf lessen die softwareontwikkelingsbedrijven kunnen leren om hun applicaties veiliger te maken.

1. Aanvallers maken nog steeds gebruik van cross-site scripting (XSS). XSS is al lang een populaire kwetsbaarheid in webapplicaties. In 2021 kwam het uit de Open Web Application Security Project (OWASP) top 10-lijst vanwege verbeteringen in frameworks voor applicatie-ontwikkeling, maar het is nog steeds duidelijk in bijna elke penetratietest die we uitvoeren.

   Het wordt vaak gezien als een laag risico, maar de XSS-risico's kunnen ernstig zijn, inclusief accountovername, gegevensdiefstal en het volledig compromitteren van de infrastructuur van een applicatie. Veel ontwikkelaars denken dat het gebruik van een validatiebibliotheek met volwassen invoer en het instellen van de juiste HttpOnly-cookiekenmerken voldoende is, maar XSS-bugs vinden nog steeds een weg naar binnen wanneer aangepaste code wordt gebruikt. Neem bijvoorbeeld WordPress-sites: een XSS-aanval die gericht is op een beheerder is van cruciaal belang omdat de inloggegevens de gebruiker in staat stellen plug-ins te laden en zo code-achtige kwaadaardige payloads op de server uit te voeren.

2. Geautomatiseerde scanners gaan niet ver genoeg. Als u alleen webapplicaties scant met behulp van geautomatiseerde tooling, is de kans groot dat kwetsbaarheden door de mazen van het net glippen. Die tools gebruiken fuzzing - een methode die misvormde gegevens in systemen injecteert - maar die techniek kan valse positieven creëren.

   Scanners zijn doorgaans niet up-to-date met moderne webontwikkeling en bieden niet de beste resultaten voor JavaScript-toepassingen met één pagina, WebAssembly of Graph. Gecompliceerde kwetsbaarheden hebben een handgemaakte payload nodig om ze te valideren, waardoor de geautomatiseerde tools minder effectief worden.

   Er is een menselijke factor vereist voor de meest nauwkeurige en gedetailleerde analyse van kwetsbaarheden en exploits, maar deze scanners kunnen een aanvullende hulpbron zijn om snel het laaghangende fruit te vinden.

3. Wanneer authenticatie van eigen bodem is, is deze meestal te zwak. Authenticatie is alles om een ​​webapplicatie te beveiligen. Wanneer ontwikkelaars hun eigen workflow voor vergeten wachtwoorden proberen te creëren, doen ze dat meestal niet op de veiligste manier.

   Pentesters krijgen vaak toegang tot de informatie van andere gebruikers of hebben buitensporige privileges die niet in overeenstemming zijn met hun rol. Dit zorgt voor horizontale en verticale toegangscontroleproblemen waardoor aanvallers gebruikers de toegang tot hun accounts kunnen ontzeggen of de applicatie kunnen compromitteren.

   Het gaat erom hoe deze protocollen worden geïmplementeerd. Security Assertion Markup Language (SAML)-authenticatie is bijvoorbeeld een single sign-on-protocol dat steeds populairder wordt als middel om de beveiliging te verhogen, maar als je het verkeerd implementeert, heb je meer deuren geopend dan gesloten.

4. Aanvallers richten zich op fouten in de bedrijfslogica. Ontwikkelaars kijken naar functies om te bepalen of ze voldoen aan de use case van een klant. Ze kijken vaak niet vanaf de andere kant van de lens om vast te stellen hoe een aanvaller die functie kwaadwillig zou kunnen gebruiken.

   Een goed voorbeeld is het winkelwagentje voor een e-commerce website. Het is bedrijfskritisch, maar vaak niet veilig, wat ernstige kwetsbaarheden veroorzaakt, zoals het op nul zetten van het totaal bij het afrekenen, het toevoegen van artikelen na het afrekenen of het vervangen van producten door andere SKU's.

   Het is moeilijk om ontwikkelaars de schuld te geven dat ze zich concentreren op de primaire use-case en andere, typisch snode, toepassingen niet herkennen. Hun prestaties zijn gebaseerd op het leveren van de functie. Leidinggevenden moeten de andere kant van de medaille zien en begrijpen dat de bedrijfslogica gecorreleerd moet zijn met beveiligingslogica. De functies met de hoogste zakelijke waarde, zoals een winkelwagentje of authenticatieworkflow, zijn waarschijnlijk niet geschikt voor een junior ontwikkelaar.

5. Er is geen "buiten bereik" in een goede penetratietest. Webapplicaties kunnen snel complex worden op basis van het aantal resources en middelen dat erin gaat. Er moet rekening worden gehouden met back-end API-servers die de functionaliteit van de hoofdtoepassing mogelijk maken.

   Het is belangrijk om al die externe middelen, en hoe ze verband houden met wat de ontwikkelaars hebben gebouwd, te delen met beveiligingsauditors die penetratietesten uitvoeren. De ontwikkelaar kan van mening zijn dat deze activa "buiten bereik" zijn en dat hij er daarom niet verantwoordelijk voor is, maar een aanvaller zou die lijn in het zand niet respecteren. Zoals penetratietesten aantonen, is niets "buiten bereik".

Een vraag over de balans

Wanneer softwareontwikkelingsbedrijven enkele van deze veelvoorkomende risico's van tevoren begrijpen, kunnen ze betere afspraken maken met beveiligingsauditors en penetratietesten minder pijnlijk maken. Geen enkel bedrijf wil zijn ontwikkelaars tegenhouden, maar door creativiteit in evenwicht te brengen met beveiligingsframeworks, weten ontwikkelaars waar ze vrijheid hebben en waar ze moeten aansluiten bij de vangrails die applicaties veilig houden.