Ben je een start-up founder of developer? Of ben je een app aan het bouwen als hobbyproject? Misschien gaat er wel ergens een belletje rinkelen bij de woorden ‘security audit’, of misschien is dit onbekend terrein voor je. In beide gevallen biedt deze blog je een heldere uitleg. Het neemt je mee in de wereld van security audits van mobiele apps: waarom ze belangrijk zijn en hoe je ze uitvoert.
Voordat je verder leest, moeten we wel een kanttekening maken. De uitvoering van een security audit kan situatieafhankelijk zijn. Als je bijvoorbeeld een fintech app bouwt, heb je waarschijnlijke zwaardere beveiliging nodig dan wanneer je een eenvoudig spelletje maakt. Maar na het lezen van deze blog heb je in ieder geval een stevige basis wat betreft security audits!
Wat is een Security Audit van een mobiele app of webapp?
First things first: wat is een security audit? Dit is een analyse van een mobiele app, webapp, of hybride app om mogelijke beveiligingsrisico's op te sporen. Tijdens dit proces worden de code, de architectuur en het ontwerp van de app onderzocht om mogelijke kwetsbaarheden in de beveiliging op te sporen.
Het doel van een security audit is dan ook om app developers te ondersteunen in het verhelpen van eventuele beveiligingsproblemen. Je kunt een security audit doen voordat je een app lanceert, maar ook erna of bijvoorbeeld op regelmatige basis.
Waarom is een Mobile App Security Audit belangrijk?
Er zijn veel redenen waarom je een security audit van je app zou willen uitvoeren. Misschien bereid je je voor op een grote lancering en wil je zeker weten dat alles veilig is. Of misschien heb je onlangs een beveiligingsfout ontdekt en moet je de omvang van de schade inschatten. Of misschien wil je je software verkopen aan een overheidsorganisatie of een enterprise klant, en eisen die als onderdeel van de deal een security audit. Wat de reden ook is - een security audit helpt je om alles rondom de beveiliging van jouw app goed in kaart te brengen.
Mobiele Apps of Webapps: wat bedoelen we daarmee?
Voordat we dieper de wereld van security audits induiken, is het belangrijk om te specificeren wat we bedoelen met mobiele apps. Dit artikel geeft uitleg met betrekking op apps in het algemeen. Dit kunnen dus zowel native (een app specifiek gebouwd voor Android of iOS) als webapps of hybride apps zijn. De basis van de beveiligingsvraagstukken voor deze verschillende soorten apps is vergelijkbaar met elkaar en behandelen we daarom uitgebreid in deze blog.
Stap 1. Start met een high-level review van je app
Een goed begin is het halve werk. Begin goed met de eerste stap van het uitvoeren van een security audit en maak een high-level overzicht van je app. Wat we daarmee bedoelen is dat je uiteen zet wat het doel is van je app, hoe het werkt, en welke afhankelijkheden het heeft. Daarnaast moet je ook de gevoeligheid van de gegevens die je app verwerkt beoordelen. Dit helpt je bepalen welke beveiligingsrisico's het belangrijkst zijn om aan te pakken.
1. Systeemarchitectuur
Start met het creëren van een systeemarchitectuur diagram. Dit geeft je een overzicht van alle componenten van je app en hoe ze op elkaar inwerken.
Met behulp van een systeemarchitectuur diagram kan je inzicht krijgen in potentiële kwetsbaarheden. Denk bijvoorbeeld aan elementen van je app die afhankelijk zijn van diensten van derden, hierdoor kan hij vatbaarder zijn voor aanvallen of storingen.
2. Databases & Persoonsgegevens
Werp vervolgens een kritische blik op de databases waar gegevens worden opgeslagen. Identificeer waar gevoelige gegevens worden opgeslagen en ga na hoe deze worden beschermd.
Werk je bijvoorbeeld in een gedeelde database of sla je alles op in een eigen database? Ga goed na wie toegang heeft tot de verschillende onderdelen. Is die toegang voor iedereen echt noodzakelijk of kun je de meest gevoelige gegevens voor minder mensen toegankelijk maken?
Maak daarna een lijst van alle gegevens die jouw app verwerkt. Denk hierbij aan gebruikersgegevens, gevoelige bedrijfsgegevens en alle andere vertrouwelijke informatie. Zodra je deze lijst hebt, kun je beginnen met het beoordelen van de risico's die aan elk type gegevens zijn verbonden.
3. Diensten van derden
Daarnaast is het waardevol om een overzicht te maken van alle diensten van derden die je gebruikt voor het runnen van de app, bijvoorbeeld een SaaS. Diensten van derden worden door start-ups vaak gebruikt om tijd en geld te besparen. Denk aan cloud storage, betalingsproviders en analytics tools.
Hoewel diensten van derden vaak noodzakelijk zijn voor het bouwen van apps, kunnen ze ook veiligheidsrisico's met zich meebrengen. Bij de beoordeling van diensten van derden is het belangrijk om na te gaan hoe ze in jouw app geïntegreerd zijn en tot welke soort gegevens deze derde partij toegang heeft. Bovendien moet je de houding van elke dienstverlener beoordelen ten aanzien van beveiliging. Als een dienstverlener bijvoorbeeld geen sterk beveiligingsbeleid voert, kan de kans op een gegevensinbreuk groter zijn.
Hoe beoordeel je diensten van derden? Controleer bijvoorbeeld:
- Welke certificering en auditverklaringen ze hebben;
- Of ze voldoen aan de gangbare standaarden zoals ISO27001 en NEN7510;
- Of er sub-leveranciers zijn, en of deze ook voldoen aan de standaarden;
- Of er (indien van toepassing) een verwerkersovereenkomst is afgesloten;
- Of gebruikelijke beveiligingsnormen worden toegepast, zoals in ieder geval tijdige patching, encryptie en toegangsbeheer;
- Of periodiek pentesten en audits worden uitgevoerd.
Stap 2. Beoordeel vervolgens de veiligheid van je mobiele app
Mobiele apps hebben te maken met een breed palet aan veiligheidsrisico’s. Soms zie je door de bomen het bos niet meer, dus helpt het om een lijstje paraat te hebben met mogelijke risico’s. De Open Web Application Security Project (OWASP) verstrekt daarom een lijst met tien risicocategorieën die je in het oog moet houden tijdens een security audit.
1. Broken Access Control
Broken Access Control, ook wel autorisatie genoemd, heeft betrekking op de rechten die een app verleent aan een gebruiker. Broken Access Control wil zeggen dat de applicatie gevoelige onderdelen niet beschermt. Een voorbeeld kan zijn dat niet-ingelogde gebruikers onbedoeld meer rechten hebben dan de bedoeling is. Potentieel kunnen gebruikers hierdoor gevoelige informatie bekijken of de gegevens van een ander wijzigen.
2. Cryptographic Failures
Dit type risico ontstaat wanneer vertrouwelijke informatie niet goed wordt versleuteld. Met de komst van de AVG is het bij wet verplicht om gevoelige data te beschermen. In ieder geval tijdens het versturen en in sommige gevallen ook bij het opslaan van gegevens (zoals medische gegevens of creditcard gegevens).
Een cryptographic failure kan voorkomen wanneer er sprake is van het volgende:
- Data die wordt verstuurd of opgeslagen in gewone tekst in plaats van code (dit is het meest voorkomend)
- Data die wordt beschermd met een zwakke of verouderde encryptiesleutel
- Data die niet voldoende wordt gefilterd of beschermd tijdens het versturen, bijvoorbeeld van een lokale opslag naar een cloud opslag.
3. Injection
Bij een injection stuurt een aanvaller kwaadaardige gegevens naar de applicatie om deze door de app te laten verwerken, zodat de app iets doet wat hij niet hoort te doen. Vooral in verouderde code is hier soms de ruimte voor, bijvoorbeeld omdat de ingevoerde gegevens door de toepassing niet worden gevalideerd, gefilterd of gezuiverd. Het gevolg kan zijn dat een aanvaller gegevens steelt, de inhoud van de site en database verandert, of zelfs je database helemaal vernietigt.
4. Insecure design
Bij deze risicofactor is de systeemarchitectuur niet voldoende veilig ontworpen. In andere woorden: het is belangrijk om ook tijdens het ontwerpen van de app stil te staan bij alle risico’s en kwetsbaarheden. Worden de laatste best practices omtrent veiligheid ook in het ontwerp toegepast?
Een onveilig ontwerp is niet direct de oorzaak van alle andere kwetsbaarheden en risicofactoren in dit lijstje. In de praktijk zien we vaak dat de beveiligingsproblemen het gevolg zijn van de implementatie van een ontwerp, en niet zozeer van het ontwerp zelf. Daarom is het goed om nog apart stil te staan bij het ontwerp van de app.
5. Security Misconfiguration
Bij deze risicofactor is het systeem van een mobiele app onvoldoende veilig geconfigureerd. Misconfiguratie kan optreden op elk niveau van een app en omvat een verscheidenheid aan problemen. Een bekend voorbeeld hiervan is als je gegevens opslaat op Amazon S3 zonder de juiste beveiligingsinstellingen. Ook vormen onnodig ingeschakelde features een risicofactor die mogelijk leidt tot misconfiguratie.
6. Vulnerable and Outdated Components
Webapplicaties hebben veel verschillende componenten, waaronder bibliotheken, frameworks en besturingssystemen. Wanneer deze componenten niet up-to-date worden gehouden, loop je risico op een breed scala aan beveiligingsproblemen. Patch management is het proces van het up-to-date houden van software. Dit is nodig om kwetsbaarheden te voorkomen.
7. Identification and Authentication Failures
De bevestiging dat gebruikers zijn wie ze zeggen dat ze zijn, is cruciaal voor de veiligheid van gegevens. Kwetsbaarheden bij het inloggen zorgen ervoor dat aanvallers toegang kunnen krijgen tot accounts.
Er zijn mogelijk kwetsbaarheden in een app wanneer veel voorkomende wachtwoorden - zoals Password123 - worden toegestaan. Een andere risicofactor is de mogelijkheid voor brute-force aanvallen. Bij een dergelijke digitale aanval kan een aanvaller systematisch wachtwoorden en encryptiesleutels uitproberen totdat er één blijkt te werken.
8. Software and Data Integrity Failure
Deze kwetsbaarheid heeft betrekking op zwakke punten in de beveiliging van een app die ertoe leiden dat de software of code waar een app gebruik van maakt, onvoldoende veilig en geverifieerd zijn.
Dit komt steeds vaker voor doordat de complexe architectuur van moderne apps ervoor zorgt dat app-ontwikkelaars steeds vaker gebruik maken van externe plug-ins, bibliotheken van niet-vertrouwde bronnen, opslagplaatsen en content delivery networks (CDN's). Deze toevoegingen aan een app maken het lastiger om de code te beschermen tegen indringers en bugs.
9. Security Logging and Monitoring Failures
Als beveiligingsgebeurtenissen, zoals inlogpogingen, niet voldoende worden geregistreerd, gecontroleerd of gerapporteerd, is verdacht gedrag moeilijk te detecteren. Een aanvaller kan bijvoorbeeld een toepassing of softwarecomponenten gedurende een langere periode op bekende kwetsbaarheden onderzoeken. Als dat lang ongemerkt door kan gaan, wordt de kans groter dat de aanvaller uiteindelijk een kwetsbaarheid in jouw app vindt en met succes uitbuit.
10. Server Side Request Forgery (SSRF)
Op deze laatste risicocategorie moet je extra scherp letten als je in je app toestaat dat de gebruiker data kan importeren via een URL. Bijvoorbeeld een LinkedIn profiel of een afbeelding.
URL’s kunnen eenvoudig gemanipuleerd worden. Als hier geen veilig validatieproces voor is geïmplementeerd, kan een hacker deze kwetsbaarheid in de beveiliging gebruiken om via een server ‘foute’ code toe te voegen en het systeem te hacken.
Vraag om hulp
Hoewel je nu misschien overweldigd ben door de hoeveelheid informatie, heb je in ieder geval nu voldoende basiskennis om aan de slag te gaan met de security audit van jouw app! Toch kan het fijn zijn om een partner te hebben die kan helpen met de ontwikkeling en beveiliging van jouw app.
IGNE is zo’n tech partner. We hebben ervaring in het samenwerken met start-ups, en kunnen helpen met het ontwikkelen en beveiligen van jouw app. Schroom dus niet om contact op te nemen voor een kop koffie, want we denken graag met je mee!
ready to ignite?
