In deze blogpost gaan we dieper in op gebroken toegangscontrole, ook wel bekend als Broken Access Control. Een belangrijke kwetsbaarheid op de OWASP-top 10-lijst die in 2021 en 2022 zelfs op de nummer 1 plek van de meest voorkomende kwetsbaarheid kwam te staan!

Wat is Broken Access Control?

Webapplicaties die een vorm van authenticatie vereisen (bijvoorbeeld inloggen met gebruikersnaam en wachtwoord) moeten er voor zorgen dat gegevens ook echt alleen te benaderen zijn voor ingelogde gebruikers. Maar daarnaast is het ook belangrijk dat de applicatie goed onderscheid kan maken tussen verschillende ingelogde gebruikers; de applicatie moet zo zijn gemaakt dat gebruikers alleen die informatie kunnen benaderen (of alleen die functies kunnen gebruiken) die bij de aan hen toegekende rol passen. Dit mechanisme wordt doorgaans beschreven als “Access Control”. Wanneer er fouten of onvolkomenheden in de Access Control implementatie zitten, is er sprake van gebroken toegangscontrole, of ook wel ‘Broken Access Control‘ genoemd.

De meest voor de hand liggende kwetsbaarheid op het gebied van broken access control is toegang zonder authenticatie. Hier is sprake van wanneer een aanvaller toegang kan krijgen tot data of functies in de webapplicatie zonder zich te hoeven authentiseren met een geldige set inloggegevens, zoals een gebruikersnaam en wachtwoord.

Als een website bijvoorbeeld vereist een account aan te vragen om toegang te verkrijgen tot bepaalde data maar daarnaast ook een openbare API heeft die toegankelijk is zonder authenticatie, kan een aanvaller deze API mogelijk misbruiken om toegang te krijgen tot de beveiligde gegevens of functies zonder de juiste autorisatie.

Vormen van Broken Access Control

Naast toegang zonder authenticatie zijn er nog twee veelvoorkomende scenario’s die betrekking hebben op broken access control:

• Horizontal privilege escalation
• Vertical privilege escalation

Horizontal privilege escalation treedt op wanneer een gebruiker toegang krijgt tot bronnen of functies die bedoeld zijn voor andere gebruikers met hetzelfde autorisatieniveau. Hier is bijvoorbeeld sprake van als een ingelogde klant toegang weet te verkrijgen tot bestellingsinformatie van andere klanten.

Vertical privilege escalation treedt op wanneer een gebruiker toegang krijgt tot bronnen of functies die bedoeld zijn voor gebruikers met hogere autorisatieniveaus. Denk bijvoorbeeld aan een klant die toegang weet te verkrijgen tot functies die alleen beheerders van een webshop zouden moeten kunnen uitvoeren.

In de praktijk komt nSEC/Resilience regelmatig dergelijke kwetsbaarheden tegen. Met name applicaties die gebruik maken zogenaamde Direct Object References zijn vaker kwetsbaar wanneer access control in deze applicaties niet juist is geïmplementeerd, ook wel bekend als ‘Insecure Direct Object Reference’ (IDOR) kwertsbaarheden.

Een voorbeeld van een Insecure Direct Object Reference kwetsbaarheid is wanneer een website gebruikers toegang geeft tot specifieke gegevens door middel van een unieke identifier, zoals een ID-nummer. Als deze identifier in de URL of in het verzoek aan de server wordt gebruikt, kan een kwaadwillende deze mogelijk manipuleren en toegang krijgen tot gegevens die niet voor hen bedoeld zijn. Stel bijvoorbeeld dat een website een pagina heeft waarop gebruikers hun eigen profiel kunnen bekijken en bewerken. De URL van deze pagina bevat de identifier van het profiel, bijvoorbeeld “website.nl/profiel/1234”. Als een kwaadwillende de identifier verandert in een ander nummer, bijvoorbeeld “website.nl/profiel/5678”, en de pagina opent, kunnen ze mogelijk toegang krijgen tot het profiel van een andere gebruiker.

Testen op broken access control

Het testen op broken access control kan een uitdaging zijn omdat testgevallen en uitkomsten vaak in elk geval voor een groot deel menselijke interpretatie behoeven. Het is voor een generieke scanning tool of een generiek script niet mogelijk om kennis te hebben van de verschillende rollen en functies in de applicatie, en welke rol welke functie zou moeten mogen gebruiken. Zelfs de betere scanners op de markt doen daardoor over het algemeen geen bevindingen op broken access control.

Hierdoor is testen op broken access control vaak nog een handmatige activiteit.

Wanneer er veel functies en rollen zijn, is het aantal mogelijke combinaties ook erg groot, wat een goede afdekking in testen nog lastiger maakt. Dit vormt een grote uitdaging omdat relatief veel bevindingen  te maken hebben met broken access control, en deze bevindingen doorgaans direct een hoge impact hebben in termen van bijvoorbeeld reputatieschade.

Het risico op broken access control kwetsbaarheden vormt op dit moment dan ook één van de voornaamste reële redenen om regelmatig een penetratietest uit te laten voeren op webapplicaties door een erkende penetratietest aanbieder zoals nSEC/Resilience.

Op het gebied van het geautomatiseerd testen van access control zijn er zeker wel hulpmiddelen die door developers kunnen worden gebruikt. Zo heeft de test tool OWASP ZAP bijvoorbeeld een add-on voor het testen van access control. In deze add-on kan worden gedefinieerd:

• Welke rollen aanwezig zijn
• Welke functies toegang zouden moeten kunnen hebben tot welke rollen
• Hoe kan worden herkend dat ongeoorloofd toegang tot een functie is verkregen

Wanneer deze instellingen zijn gedaan, kan ZAP vervolgens zelf geautomatiseerd controleren op broken access control kwetsbaarheden. Omdat de configuratie kan worden bewaard, kunnen deze controles gemakkelijk worden herhaald, waardoor bijvoorbeeld deze testen bij elke release weer kunnen worden uitgevoerd. nSEC/Resilience kan ook ondersteunen bij het opzetten en inrichten van dergelijke controles.

Broken access control voorkomen

Er zijn verschillende best practices die kunnen helpen om gebroken toegangscontrole te voorkomen:

• Implementeer een goed toegangscontrolemodel: zorg voor een duidelijke en strikte toegangscontrole met de juiste niveaus van machtigingen en beperk de toegang tot gevoelige gegevens tot alleen degenen die deze nodig hebben om hun werk te doen
• Minimaliseer het gebruik van direct object references: maak gebruik van indirecte verwijzingen in plaats van directe verwijzingen naar gegevens, zoals sessie-ID’s, om te voorkomen dat kwaadwillenden toegang krijgen tot gegevens die niet voor hen bedoeld zijn. Voor specifieke objecten kunnen ook UUIDs worden gebruikt als identifier
• Monitor en rapporteer ongeautoriseerde toegangspogingen: implementeer monitoringmechanismen om ongebruikelijke activiteiten te detecteren en stel rapportageprocedures in om incidenten van gebroken toegangscontrole te rapporteren en aan te pakken
• Zorg voor regelmatige audits: voer regelmatig audits en penetratietesten uit om te controleren of de access control nog steeds voldoet aan de vereisten en om eventuele kwetsbaarheden op te sporen en aan te pakken
• Houd systemen up-to-date: zorg ervoor dat alle software en systemen up-to-date blijven en patch eventuele beveiligingslekken direct. Verouderde software kan immers kwetsbaar zijn voor bekende aanvallen

Zie ook: https://owasp.org/www-community/Broken_Access_Control voor meer informatie over broken access control.

Geschreven door Kevin Blank, gepost op 23 Mei 2023

Benieuwd of uw web applicatie kwetsbaarheden bevat met betrekking tot broken access control en wat nSEC/Resilience hier in kan betekenen? We vertellen u er graag meer over. Neem contact met ons op voor meer informatie of bekijk onze pakketten/prijzen pagina!