De stille datalekken van low-code
Een datalek hoeft niet het gevolg te zijn van een sluwe hack of een kwetsbaarheid in de software. Met name bij low-codeplatforms, zoals Mendix of Salesforce, kan één verkeerde configuratie al genoeg zijn om gevoelige informatie openbaar te maken. ‘Bij ruim 1 op de 10 onderzochte applicaties konden onbevoegden bij gegevens die niet voor hen was bestemd.’
De bevindingen komen van het Dutch Institute for Vulnerability Disclosure (DIVD), dat de problematiek recent tijdens een presentatie in het Tech Theater op Cybersec Netherlands toelichtte.
DIVD onderzocht vooral applicaties die met Mendix zijn gebouwd. In Nederland werden 1.460 Mendix-applicaties gevonden. Bij iets meer dan 150 daarvan stuurde DIVD een melding omdat de applicatie mogelijk gevoelige of kritieke informatie aan onbevoegden blootstelde.
Onder de radar
Het gaat niet om een formeel wetenschappelijk onderzoek, maar de cijfers geven volgens DIVD wel een indicatie van een breder probleem binnen low-code. Een verkeerde instelling, bijvoorbeeld een gastrol of te ruime standaardrechten, kan toegang geven tot gegevens die niet voor iedereen bedoeld zijn.
Technisch functioneert de applicatie dan zoals ontworpen; de beveiliging is alleen verkeerd geconfigureerd. ‘Securityteams weten vaak niet dat er applicaties zoals Mendix binnen hun omgeving bestaan’, aldus Jeroen Ellermeijer, Head of Research & Development bij DIVD. Daardoor blijven deze toepassingen dus vaak onder de radar.
En Salesforce?
Het probleem beperkt zich niet tot Mendix. DIVD zag een vergelijkbaar fenomeen bij Salesforce, waar eveneens door configuratiefouten gegevens via de bedoelde functionaliteit toegankelijk kunnen worden. Voor Salesforce heeft DIVD nog een onderzoek lopen.
Low-codeplatforms worden vaak gepositioneerd als veilig by design. Maar tijdens de ontwikkeling en uitrol worden toegangsrechten en functionaliteiten regelmatig ruimer ingesteld. Bij de overgang naar productie moeten die instellingen daarom kritisch worden gecontroleerd. ‘Iemand moet de vinkjes nog goedzetten’, stelt Jeroen Ellermeijer het eenvoudig.
Hoe beperk je het risico?
Ellermeijer raadt een aanpak aan op drie niveaus en verantwoordelijkheden.
Voor het blue team begint de aanpak met zichtbaarheid. ‘Breng alle low-code-applicaties binnen de organisatie in kaart en controleer vervolgens welke informatie zonder authenticatie toegankelijk is’, haalt Ellermeijer aan. ‘Test applicaties expliciet vanuit het perspectief van een anonieme gebruiker en monitor api-endpoints en runtime-verkeer op onverwachte toegang.’
Het red team, het tweede niveau, moet volgens hem gericht zoeken naar configuratiefouten, publiek toegankelijke functionaliteit en data die via de applicatie of api zonder de juiste autorisatie beschikbaar komt.
Voor ontwikkelaars ligt de nadruk ten slotte op toegangscontrole. ‘Valideer entity access en module roles, test de runtime-toegang vóór livegang en schakel anonieme toegang standaard uit.’
