Onze specialisatie
API-security
Autorisatiefouten in API's zijn de meest gemaakte en de duurste fout. Ze worden zelden door een scanner gevonden, omdat er niets kapot uitziet.
Bijna elke moderne applicatie praat via een API met haar eigen achterkant: de mobiele app, de webshop, het klantenportaal, de koppeling met uw boekhoudpakket. Die API’s zijn ontworpen om door software gebruikt te worden, niet door mensen. Precies daarom worden ze minder goed getest.
De meest voorkomende fout is ook de saaiste. De API vraagt netjes om een geldige login, maar controleert daarna niet of het opgevraagde item wel van die gebruiker is. Het gevolg: één cijfer aanpassen in een webadres en u leest het dossier van iemand anders. Dat heet BOLA en het staat al jaren op nummer één van de OWASP API Security Top 10.
Waarom een scanner dit mist
Een geautomatiseerde scanner zoekt naar iets dat stuk is: een foutmelding, een crash, een onverwacht antwoord. Bij een autorisatiefout gebeurt geen van die dingen. De API antwoordt netjes met status 200 en levert de gegevens. Technisch werkt alles precies zoals geprogrammeerd. Alleen: het is de verkeerde gebruiker.
Om dit te vinden moet iemand begrijpen wat de applicatie doet, twee accounts naast elkaar leggen en systematisch proberen of account A bij de gegevens van account B geraakt. Dat is handwerk.
Wie het doet
Deze tests worden uitgevoerd door een actieve bug bounty hunter met API-kwetsbaarheden als specialisatie — iemand die dit dagelijks doet bij bedrijven die daar publiek een beloning voor uitloven en dus alleen betaald wordt voor wat echt werkt.
Waar we naar kijken
- BOLA — toegang tot andermans gegevens
- De API controleert of u ingelogd bent, maar niet of het opgevraagde dossier van u is. Wijzig het nummer in de URL en u ziet de factuur van een andere klant.
- BFLA — toegang tot beheerfuncties
- Een gewone gebruiker kan een functie aanroepen die alleen voor beheerders bedoeld is, omdat de knop wel verborgen is maar de API-oproep niet afgeschermd.
- Te veel teruggegeven gegevens
- De app toont een naam, maar de API stuurt ook het rijksregisternummer, het salaris en het wachtwoordhash mee. Alles wat verstuurd wordt, is leesbaar.
- Mass assignment
- Een gebruiker past zijn profiel aan en stuurt stiekem het veld "rol" mee. De API neemt dat klakkeloos over en de gebruiker wordt beheerder.
- Geen rate limiting
- Niets houdt iemand tegen om duizenden wachtwoorden per minuut te proberen of om uw volledige klantenbestand op te halen, record per record.
- Kapotte authenticatie
- Tokens die niet verlopen, die niet gecontroleerd worden op handtekening of die in de URL staan en dus in logbestanden belanden.
Wat u terugkrijgt
- Per bevinding de exacte oproep waarmee ze te reproduceren is, zodat uw developer het meteen kan nabootsen
- Uitleg over welke gegevens werkelijk bereikbaar waren, niet enkel dat er "een risico" is
- Een concrete oplossing op codeniveau, geen algemene aanbeveling
Veelgestelde vragen
- Wat is BOLA?
- BOLA staat voor Broken Object Level Authorization: de API controleert of u ingelogd bent, maar niet of het opgevraagde item van u is. Wie één nummer in een webadres aanpast, ziet het dossier of de factuur van een andere klant. Het staat al jaren op nummer één van de OWASP API Security Top 10 en wordt zelden door een scanner gevonden, omdat de server gewoon netjes antwoordt.
- Hoeveel testaccounts hebben jullie nodig?
- Minstens twee gewone gebruikersaccounts, liefst in verschillende rollen of bij verschillende klantorganisaties. Zo kunnen we systematisch nagaan of account A bij de gegevens of functies van account B geraakt. Dat is de enige betrouwbare manier om autorisatiefouten te vinden.
Weten wat er van u zichtbaar is?
Vertel ons welk domein u wilt laten nakijken. We bepalen samen de scope, u tekent het mandaat en daarna beginnen we.