
Security by design: architectuur Mendix
Geschreven door Rob Dekkers
In de vorige blog Security by design: introductie hebben wij gedefinieerd wat wordt verstaan onder een veilige applicatie. Daarin worden de aspecten vertrouwelijkheid, integriteit, beschikbaarheid en afrekenbaarheid in voldoende mate gegarandeerd. In deze blog zullen we kijken naar de architectuur van Mendix applicaties en de runtime-omgeving, zodat we beter kunnen aangeven welke onderdelen we meer of minder op de genoemde aspecten kunnen vertrouwen en waar zich kwetsbaarheden kunnen bevinden.
Architectuur Mendix app
Op de website van Mendix Docs staat een uitgebreide beschrijving van de architectuur van de Mendix Runtime. Hier worden alleen de voor ons doel benodigde hoofdzaken besproken.
Een Mendix app bestaat uit twee delen: Mendix runtime server en client. De runtime server draait over het algemeen op het Mendix platform (in de cloud) en de client draait in een web browser (webapplicatie) of in een mobile app-container (mobile applicatie). De client communiceert met de runtime server via een web server van het platform, specifiek voor CRUD acties op data en uitvoeren van business logica met de client API. Naast een client kunnen ook service consumers communiceren met published services uit de app via de web server (Soap, REST, OData). En een derde mogelijkheid is low level communicatie volgens http-protocol via request handlers.
Een schematische weergave van de architectuur is in de volgende afbeelding gegeven.
Trust boundary
Het begrip trust boundary is een hulpmiddel bij threat modelling, het in kaart brengen van kwetsbaarheden en het bepalen van risicoverlagende maatregelen. Het idee is dat het gebied binnen de grenzen voldoet aan een bepaalde vorm van vertrouwen in de onderliggende integriteit van systeemonderdelen, data en/of processen en dat er ook een actieve beïnvloeding daarvan mogelijk is.
In de afbeelding van de architectuur is een trust boundary in rood aangegeven. Binnen dit gebied hebben we invloed op de veiligheid van de applicatie of kunnen we die (in combinatie met Mendix als vertrouwde partner) goed vaststellen.
Het Mendix platform wordt beheerd door Mendix. Er is actieve controle en verbetering van de veiligheid. Het platform wordt zwaar bewaakt en toegang is alleen mogelijk voor geautoriseerde gebruikers en beheerders. Data is encrypted in transit (https) en at rest (opslag). Toegang tot de database en file storage kan alleen via de app.
Allerlei voorzieningen zijn getroffen of beschikbaar om bepaalde kwetsbaarheden in Mendix apps te vermijden (in een latere blog wordt hier nog op ingegaan).
De Mendix app is door ons zelf ontwikkeld; we hebben de code zelf geschreven (gemodelleerd) en kunnen daarmee de volledige verantwoordelijkheid voor de kwaliteit van de code nemen. We kunnen de veiligheid van de app beoordelen en verbeteren, indien gewenst.
Echter wordt er bij de ontwikkeling ook gebruik gemaakt van onderdelen waar minder kennis van is en die meestal door anderen zijn ontwikkeld: appstore modules en Java libraries. Het is soms lastig om van deze onderdelen de integriteit te kunnen bepalen. En voor verbetering van de veiligheid ben je vaak afhankelijk van die anderen. De Java library Log4J is hiervan een goed voorbeeld. Niemand had gedacht dat zo’n veel gebruikte open source library een ernstige kwetsbaarheid zou bevatten.
Untrusted clients
Het is goed er bewust van te zijn dat alles wat zich in de client afspeelt niet vertrouwd kan worden. Hoewel het wellicht lijkt dat de verwerking in de client altijd onder de verantwoordelijkheid en restricties van de pages en widgets uit de Mendix app gebeurt, hoeft dat niet het geval te zijn. Het is mogelijk om buiten de client om de client API te gebruiken. Dat is heel eenvoudig, mede omdat de client API volledig is gedocumenteerd. In een latere blog zullen we laten zien hoe we hier met pentesten dankbaar gebruik van maken.
Ook kun je buiten de app om de object store en aanroepen van microflows op de server vanuit de client manipuleren.
Hierdoor is het mogelijk om validaties op de client te omzeilen, kun je schermblokkades opheffen, kun je de inhoud van schermen, de lokale objecten in de client en de waarden van parameters van microflows aanpassen.
Naast de Mendix client, kunnen onbevoegden gebruik maken van de published webservices en request handlers. Deze API’s zijn publiekelijk voor iedereen toegankelijk, tenzij hiervoor infrastructurele restricties worden gedefinieerd.
En dan zijn er nog kwetsbaarheden in de browser zelf, die te maken hebben met het uitvoeren van kwaadaardige Javascript code die door onbevoegden zijn geïnjecteerd of gelinkt. Of het onderscheppen van de communicatie over internet tussen browser en webserverover. De belangrijkste van deze kwestbaarheden zijn beschreven in de bekende OWASP-lijst waar we later nog aandacht aan zullen besteden.
Een kwaadaardige gebruiker kan onverwachte schade aanrichten. Daarom is het belangrijk te weten welke gebruikersprofielen er zijn, waar mogelijke risico’s liggen en welke oplossingen je zou willen implementeren tegen welke kosten. Het Mendix platform biedt mogelijkheden om bepaalde kwetsbaarheden te verminderen, vooral op het gebied van infrastructuur, communicatie en browserbeveiliging. Maar het veilig maken van een Mendix app kost serieus denkwerk en ontwikkelinspanning en soms zelfs een heel andere architectuur van de applicatie, dan je standaard met Mendix zou ontwikkelen. Dit zal in deze blogreeks aan de orde komen.
In een volgende blog Security by design: authenticatie besteden we aandacht aan het inloggen op Mendix apps, de belangrijkste stap om de deur dicht te kunnen houden voor onbevoegden.