Eind 2017 heeft het Owasp (Open Web Application Security Project) een nieuwe top 10 gepubliceerd van de grootste en meest voorkomende risico's binnen webapplicaties. Deze top 10 is een belangrijk hulpmiddel voor webontwikkelaars om kwetsbaarheden te identificeren en te voorkomen. Op het gebied van het web is sinds 2013, het jaar van de vorige top 10, veel veranderd. Hebben we nog steeds last van dezelfde problemen als de vorige decennia, of is er sprake van totaal nieuwe risico's?
De afgelopen jaren zijn er een aantal grote trends ontstaan op het gebied van webontwikkeling. Een belangrijk voorbeeld hiervan is dat niet langer de back-end het grootste gedeelte van de applicatielogica bevat, maar dat steeds vaker ‘single page applications’ worden gebouwd op basis van JavaScript-frameworks. Waar vroeger de server dynamisch webpagina’s genereert, wordt nu steeds vaker een api aangeboden waar de front-end vanuit de browser, of vanuit een mobiele app, mee communiceert. Daarnaast is er meer aandacht voor schaalbaarheid, de nieuwe opties die browsers aan ontwikkelaars bieden, en het verbeteren van de gebruikerservaring op verschillende apparaten.
Hebben dit soort veranderingen veel invloed op het type kwetsbaarheden in webapplicaties? Een eerste blik op de Owasp Top 10 geeft het idee dat dat wel meevalt.
Risico’s op een rij
Het eerste risico is dezelfde als in 2013 en 2010: injectie. Dit is een algemene term voor het risico dat ontstaat wanneer commando’s in een instructietaal (bijvoorbeeld SQL, Bash of LDAP) onveilig gemixt worden met gebruikersinvoer. Wanneer een aanvaller tekens met een speciale betekenis (‘metakarakters’) invoert, kan deze vervolgens de betekenis van dit commando aanpassen en vaak ernstige schade aanrichten. Het bekendste voorbeeld van zo’n aanval is SQL-injectie, waarbij een aanvaller eigen queries kan laten uitvoeren en daarmee de inhoud van de database kan uitlezen of wijzigen. Hoewel SQL-injectie al bijna twintig jaar een groot probleem is, komen we het tijdens beveiligingsonderzoeken steeds minder vaak tegen. Ontwikkelaars zijn tegenwoordig goed op de hoogte van deze beruchte aanval en web-frameworks zijn er standaard op ingericht om dit risico te vermijden. Dat geldt echter niet per se voor andere injectie-kwetsbaarheden: een interessant voorbeeld is NoSQL-injectie, waarbij een vergelijkbare aanval wordt uitgevoerd tegen de querytalen van alternatieve, niet-relationele, databases.
Het tweede risico, authenticatiefouten, is ook onveranderd. Voorkomen dat aanvallers andermans account overnemen blijft in het algemeen ingewikkeld. Trends zoals stateless sessiebeheer, single-sign on en authenticatiemethoden die ook geschikt zijn voor apps, introduceren nieuwe risico’s, waar ontwikkelaars mogelijk minder bekend mee zijn.
Het derde risico is het lekken van gevoelige data, bijvoorbeeld door een gebrek aan versleuteling of (sterke) gebruikersauthenticatie. Ook worden tegenwoordig gevoelige gegevens nog vaak, per ongeluk, publiek toegankelijk gemaakt. Een pluspunt is wel dat het gebruik van transportversleuteling, door middel van https, enorm is toegenomen.
Het vierde risico op de lijst is een opvallende nieuwkomer: het toestaan van externe xml-entiteiten. Dit is een oud probleem dat aanvallers toestaat bestanden op de server (en het netwerk achter de firewall) uit te lezen door een, bij nader inzien niet zo handige, feature uit te buiten in (verouderde) software die xml-berichten uitleest. Dit risico is in de top 10 beland omdat broncode-analyse aantoont dat het in de praktijk zeer vaak voorkomt. Hopelijk zal de opname in de Owasp-lijst ervoor zorgen dat deze obscure maar gevaarlijke kwetsbaarheid meer bekendheid krijgt.
Het vijfde risico is falende toegangscontroles. Een klassiek probleem, dat bij moderne webtechnologieën – die vaak ingewikkeldere vormen van authenticatie gebruiken – ook erg vaak voorkomt. Het ontbreken van autorisatiecontroles is ook een typische kwetsbaarheid dat lastig is om op te testen, of om te vinden met automatische tools.
Het zesde risico luidt: configuratiefouten. Software is vaak standaard ingesteld zodat het makkelijk in gebruik te nemen is, maar niet per se op een manier die veilig is. Zorg er altijd voor dat belangrijke security-functies aan staan, u geen gebruik maakt van standaardwachtwoorden en debug-functies uitzet op de productieomgeving.
Het zevende risico is cross-site-scripting, het overnemen van andermans browsersessie door scripts in een webpagina te injecteren, is flink gedegradeerd: van nummer drie in 2013 tot nummer zeven in de nieuwste editie. Deze kwetsbaarheid kan nog steeds catastrofaal zijn, maar is vanwege mitigaties van web-frameworks moeilijker uit te buiten dan voorheen. Dit soort beveiligingsmaatregelen worden echter vaak expliciet uitgeschakeld wanneer ze in de weg zitten, en ze beschermen ook niet tegen alle mogelijke vormen van cross-site-scripting.
De top 10 wordt afgesloten met respectievelijk onveilige deserialisatie (het mogelijk maken voor een aanvaller om een getransporteerd programmeertaal-object aan te passen, waardoor de server overgenomen kan worden), het gebruik van software met bekende kwetsbaarheden (tegenwoordig gemakkelijk uit te buiten met hacker-tools waarmee op verouderde software gescand kan worden) en onvoldoende logging en monitoring. Het laatste risico is nieuw op de lijst, en erkent dat je niet kunt aannemen dat preventieve maatregelen afdoende zijn: het is ook belangrijk om aanvalspogingen te kunnen detecteren, adequaat erop te kunnen reageren, en een plan te hebben voor wanneer het misgaat.
Lang niet alle risico’s
De Owasp Top 10 bevat natuurlijk lang niet alle web-risico’s, en de relevantie en bijbehorende business risks van elk punt zullen per applicatie sterk verschillen. Toch biedt de lijst een toegankelijke checklist van risico’s waar ontwikkelaars van webapplicaties rekening mee moeten houden. Verder biedt Owasp veel informatie om dergelijke risico’s te voorkomen, maar ook om de beveiliging van bestaande applicaties te testen (middels de Owasp Testing Guide).
Het zou geen verrassing zijn als bij de eerstvolgende Owasp Top 10 technologie-specifieke problemen als externe xml-entiteiten en onveilige deserialisatie alweer verdwenen zijn: dit type risico’s zijn gemakkelijk te detecteren, mitigeren en vermijden. Fundamentelere zaken zoals fouten in toegangscontroles en verouderde software zullen waarschijnlijk nog wel vele jaren op de lijst blijven staan. Dit zijn voorbeelden van risico’s twintig jaar geleden een uitdaging blijven voor ontwikkelaars. Ik hoop wel dat we ooit gaan leren geen data met instructietalen te vermengen, zodat injectie-kwetsbaarheden eindelijk eens van de risicotroon gestoten kunnen worden.
