API’s zijn een essentieel component van moderne applicaties. Een enterprise-organisatie heeft er meer dan 10.000 in gebruik, waaronder veel zelf ontworpen API’s. Externe gebruikers communiceren er volop mee, maar kwaadwillenden kunnen bij die processen voor veel problemen zorgen bij de organisatie die de API draait. OWASP (Open Worldwide Application Security Project) heeft onlangs een nieuwe top 10 geproduceerd van API-gevaren.
In 2019 kwam OWASP al met een top 10 van API-securityrisico’s. De twee vooraanstaande gevaren zijn nog altijd onveranderd: “Broken Object Level Authorization” (BOLA) en “Broken User Authentication”. In het eerste geval wist Filip Verloy, Field CTO bij Noname Security, ons eerder dit jaar te melden dat BOLA-aanvallen veel schade aan kunnen richten. In september 2022 kwam een dergelijk incident voor bij Australisch telecombedrijf Optus, dat bijna 10 miljoen persoonsgegevens lekte.
Een API is veelal ingericht om een gebruiker te voorzien van specifieke data, maar een kwaadwillende kan erachter komen hoe de API dit doet. Verloy stelt dat een aanvaller kan beginnen als doodgewone gebruiker en vervolgens na authenticatie en autorisatie queries kan doen die de API manipuleert. Zo kunnen reusachtige datalekken ontstaan, zoals wanneer een aanvaller de data van elke andere gebruiker afstruint en deze lekt. Wie immers doorheeft welke Object ID’s op te vragen zijn, kan ze systematisch opvragen en binnenhalen als er verder geen securitymaatregelen genomen worden.
Om ervoor te zorgen dat er geen BOLA-aanval plaatsvindt, is het belangrijk om user policies toe te passen die niet toegang tot zomaar elke object ID toestaan. Ook moeten de records hiervan niet op een voorspelbare manier van een ID worden voorzien. OWASP raadt aan om tests te doen op de API terwijl deze in ontwikkeling is, zoals Noname Security ondersteunt.
Daarnaast is nummer twee, kapotte authenticatie, nog altijd prominent. Door bijvoorbeeld zwakke wachtwoorden toe te staan, de authenticiteit van tokens niet te verifiëren of geen limieten te stellen op wachtwoordherstel kunnen API’s kwetsbaar zijn voor brute-force aanvallen.
Van effect naar oorzaak
OWASP stelt vervolgens dat ook object properties moeten worden voorzien van autorisatie-validatie. Wie dit niet of te weinig toepast, loopt veel gevaren. De groep haalt als voorbeeld aan dat gebruikers persoonsgegevens en geldbedragen kunnen aanpassen en daarmee foutieve informatie kunnen invoeren. Een legitieme API-call wordt dus aangepast om data te manipuleren waar een gebruiker niet aan zou moeten kunnen sleutelen. Om dit te voorkomen moet een organisatie ervoor zorgen dat de object properties waar gebruikers aan mogen sleutelen, erg beperkt blijven.
Tip: Noname Security introduceert tool om geen API ongetest te laten
Nummer vier is een vrij eenvoudige misconfiguratie: API-requests consumeren hardware-resources, die van nature eindig zijn en stroom kosten. Alles van CPU-cycli tot netwerkbandbreedte speelt daarbij een rol. Het is daarom belangrijk om grenzen te stellen aan deze consumptie, want anders kan een kwaadwillende via talloze API-calls een systeem platleggen. In feite kan men dus een klassieke DDoS-aanval uitvoeren op de IT-omgeving van een bedrijf. Execution time-outs, maxima aan geheugenverbruik, bestandsformaat en andere limieten zijn dus erg belangrijk om je hiertegen te beschermen.
Daarnaast is het mogelijk dat een aanvaller administratieve API-endpoints manipuleert. OWASP stipt dit gevaar als nummer vijf op de ranglijst aan: het nagaan van autorisatiechecks is een tijdrovende taak en kan erg verwarrend zijn door de wirwar aan roles, groups en user hierarchies. Daarbovenop kan een misconfiguratie hiervan eenvoudiger opgemerkt worden in de gestructureerde data van een API. Zo is het mogelijk dat administratieve functies gemanipuleerd worden om gevoelige gegevens te verkrijgen, door als kwaadwillende bijvoorbeeld toegang tot een applicatie te verkrijgen via een malafide API-call. Deze actie zou een doodgewone gebruiker niet moeten kunnen uitvoeren.
Overal is op te scannen
Nu zijn deze vijf genoemde gevaren bekende problemen. Ook nummers acht en negen uit de OWASP-lijst zijn niet nieuw. Security-misconfiguraties komen helaas nog veel voor en ontstaan vaak bij API’s. Dit omdat externe applicaties bijvoorbeeld nog niet gepatcht zijn voor een bekende kwetsbaarheid of omdat een API geen veilige standaardconfiguratie bevat. Onjuiste inventory-management is eveneens een makkelijk te maken fout: omdat veel organisaties klaarblijkelijk meer dan 10.000 API’s erop nahouden, is het lastig om hierbij het overzicht te bewaren.
Bijna al deze problemen zijn te verhelpen bij een zorgvuldige ontwikkeling van API’s. Als deze vanuit third parties komen is dat natuurlijk niet haalbaar. Maar wie zelf een API bouwt, kan beter alvast goed opletten. Verloy constateert: “De kosten om deze problemen te verhelpen zijn 10 tot 100 keer hoger dan als ze gevonden worden tijdens pre-productie.” Bij Noname ligt dan ook de focus op het assisteren van API-bouwers in plaats van het observeren van problemen bij bestaande API’s. Toch behoort ook dat tweede tot de capaciteiten van het Noname-aanbod.
Nieuwe gevaren
Noname kondigde deze week aan dat het voortaan alle tien door OWASP aangegeven API-kwetsbaarheden kan verhelpen, waarvan er drie geheel nieuw op de lijst zijn. Allereerst een wijdverspreid probleem dat ook klanten treft. API’s kunnen informatie bevatten over “business flows”, oftewel: processen die essentieel zijn om zaken te doen. Zo kan een ticketbureau of een restaurant respectievelijk tickets of reserveringen online aanbieden, maar is het proces hiervoor dermate geautomatiseerd en voorspelbaar dat iemand van buitenaf bots erop los kan laten. Het resultaat: een plotseling uitverkocht concert of volgeboekt restaurant, waarna de dader de tickets voor woekerprijzen doorverkoopt of het restaurant met lege tafels laat zitten. Zaken als device fingerprinting, captcha’s en het controleren op muisklikken die sneller zijn dan een mens zou kunnen, kunnen ervoor zorgen dat bots niet effectief zijn.
Ten tweede kunnen aanvallers server-side requests namaken. Wanneer een API een externe bron aanspreekt zonder een aangeleverde URL te controleren, kan een aanvaller bijvoorbeeld scannen naar kwetsbare netwerkpoorten. Denk bijvoorbeeld aan een platform dat het uploaden van afbeeldingen toestaat via een URL, maar deze niet op voorhand checkt. Opeens ontstaat er een ongewenste verbinding tussen de website van de aanvaller en het systeem van het getroffen bedrijf. Allow lists van vertrouwde websites, het tegengaan van HTTP-redirects en de inzet van een geteste URL-parses kunnen leed voorkomen.
De laatste toevoeging aan de OWASP-lijst betreft de overmatige consumptie van API’s, met name die van third parties. Hoewel Noname bijvoorbeeld kan helpen met het testen van eigen API’s tijdens het ontwikkelingsproces, is het veel lastiger om in de gaten te houden hoe goed het security-niveau van extern aangeleverde bronnen is. In feite heeft deze tiende valkuil veel overlap met andere API-gevaren: wie geen overzicht heeft over welke API’s men gebruikt of ze niet patcht, kan met third-party-varianten in de problemen komen.
Luister onze podcast waarin we in gesprek gingen met Filip Verloy van Noname Security:
20 uur geleden
