Web Application Testing
Beveiliging van webapplicaties tegen misbruik en kwetsbaarheden
Frontend en API, gezamenlijk getest
Een moderne webapplicatie bestaat uit twee onderdelen: de interface die uw gebruikers te zien krijgen, en de API-laag daarachter. Als u slechts één van beide test, krijgt u een verkeerd beeld van de dekking.
Elke CREDS-test van webapplicaties omvat beide aspecten. Wij testen de frontend op kwetsbaarheden die via de browser aan het licht komen, en wij testen de API-laag rechtstreeks, met inbegrip van eindpunten die de frontend nooit aanroept, autorisatielogica die uitsluitend aan de serverzijde wordt afgedwongen, en functionaliteit die bereikbaar is zonder ook maar enigszins via de interface te gaan.
In de praktijk zijn het juist de API-problemen die doorgaans de ernstigste bevindingen opleveren. Gebreken in de autorisatie op objectniveau, ontbrekende toegangscontrole op individuele eindpunten en bedrijfslogica die uit de juiste volgorde kan raken, zijn vanuit de frontend niet zichtbaar en worden ook niet door een scan opgespoord.
Frontend
Authenticatie en sessiebeheer, verwerking van invoer, logica aan de clientzijde, toegangscontrole zoals deze in de interface wordt toegepast, en de kwetsbaarheden die de browser van een gebruiker bereiken.
API
Autorisatie op eindpuntniveau, toegangscontrole op objectniveau, misbruik van bedrijfslogica, aaneengeschakelde verzoeken en eindpunten die niet via de interface toegankelijk zijn.
Hoe wij testen
Een penetratietest is een project met een vastgestelde tijdsduur. Daardoor is de echte vraag niet „wat er getest kan worden”, maar „waar de beschikbare tijd het best kan worden besteed”. Alles in onze aanpak is erop gericht om die vraag te beantwoorden.
Automatisering legt de basis
Wij passen in de aanloop naar en tijdens de test een hoge mate van automatisering toe: het in kaart brengen van het aanvalsoppervlak, het inventariseren van eindpunten en het voorbereiden van de werkzaamheden waarvoor geen menselijke tussenkomst nodig is. Dat is niet de test zelf. Het is wat onze testers bevrijdt van repetitief werk, zodat zij hun tijd kunnen besteden aan de bevindingen die automatisering niet kan opsporen: bedrijfslogica, aaneengeschakelde kwetsbaarheden, autorisatiefouten en misbruik van de daadwerkelijke functionaliteit van de applicatie.
Beoordeling van de broncode, waar mogelijk
Wij geven er de voorkeur aan om geautomatiseerde broncodecontrole in de opdracht op te nemen. Toegang tot de code biedt ons twee voordelen: een duidelijker beeld van waar de zwakke punten daadwerkelijk hun oorsprong vinden, in plaats van alleen waar ze aan het licht komen, en een aanzienlijk efficiëntere test, omdat wij geen tijd hoeven te besteden aan het achterhalen van de werking van de applicatie.
Met broncode-analyse duiken we in de code om potentiële kwetsbaarheden te identificeren; het fungeert als een diepgaande beoordeling in plaats van een op zichzelf staande oplossing of vervanging voor beveiligingscontrole-analyse. Deze dubbele aanpak zorgt ervoor dat potentiële beveiligingsfouten worden geïdentificeerd en verholpen vanuit zowel een structureel als functioneel perspectief.
Handmatig testen waar het ertoe doet
Automatisering spoort bekende patronen op. Zij spoort echter niet de fout op die uitsluitend voortkomt uit de manier waarop uw applicatie een bepaald bedrijfsproces afhandelt. Dat werk gebeurt handmatig, door een tester die begrijpt waarvoor uw applicatie dient, en daar gaat het grootste deel van de uren van het project naartoe.
Drie testniveaus
Wij delen onze testactiviteiten in niveaus in die zijn afgestemd op de ontwikkelingsfase van uw applicatie en uw organisatie. Welk niveau het meest geschikt is, hangt af van hoe vaak de applicatie wordt gewijzigd, hoe cruciaal deze is en in hoeverre deze al is getest.
- 01
Basispenetratietest
De essentiële test, geschikt voor elke webapplicatie. Gericht op het opsporen van veelvoorkomende kwetsbaarheden in zowel de frontend als API, getest aan de hand van erkende normen. Het juiste uitgangspunt voor een eerste test, een pas gelanceerde applicatie of regelmatige, terugkerende kwaliteitscontrole.
Typical duration: 1 week
- 02
Geavanceerde penetratietest
Gaat dieper in op geavanceerde problemen die bij een basistest niet aan het licht komen: complexe aanvalsketens, misbruik van bedrijfslogica, subtiele autorisatiefouten en kwetsbaarheden die pas zichtbaar worden wanneer meerdere kleinere zwakke punten worden gecombineerd. Geschikt voor applicaties die gevoelige gegevens verwerken, of wanneer een eerdere basistest relatief weinig problemen aan het licht bracht.
Typical duration: 2 weken
- 03
Scenario-gebaseerde penetratietest
Op maat gemaakte scenario’s die zijn afgestemd op uw operationele omgeving en dreigingslandschap, waarbij wordt getest wat een specifieke, realistische aanvaller daadwerkelijk zou proberen uit te halen tegen uw applicatie. Geschikt wanneer u een specifieke vraag wilt beantwoorden in plaats van een brede dekking te realiseren.
Typical duration: 2 tot 3 weken
Weet u niet zeker welk niveau geschikt is? Dat is het eerste wat we samen vaststellen tijdens de verkenningsfase, en we zullen u laten weten als een minder uitgebreide test de juiste keuze is.
Getest volgens erkende normen
Testen is alleen zinvol als de diepgang en reikwijdte ervan verifieerbaar zijn. Wij werken volgens internationale normen, zodat de dekking van uw test vergelijkbaar, herhaalbaar en verdedigbaar is tegenover een auditor, in plaats van afhankelijk te zijn van de tester die u toevallig krijgt toegewezen.
OWASP ASVS. De Application Security Verification Standard, ons belangrijkste raamwerk voor het vaststellen van de diepgang van een test van webapplicaties.
OWASP Top 10. De basisreeks van beveiligingsrisico’s voor applicaties.
OWASP-handleiding voor het testen van webbeveiliging. De werkwijze die onze testers hanteren.
OWASP: Overzicht van beveiligingsmaatregelen voor webservices. Toegepast op API-tests, voor zover van toepassing.
NCSC-richtlijnen inzake ICT-beveiliging. Voor webtoepassingen en voor Transport Layer Security (TLS).
BIO. Baseline Informatiebeveiliging Overheid, voor overheidswerkzaamheden.
Logius-normen. Voor DigiD-beoordelingen.
Certificeringen en lidmaatschappen
Er gaat niets de deur uit zonder dat er nog eens goed naar is gekeken
Elke CREDS-penetratietest wordt, volgens ons vierogenprincipe, op twee vlakken door vakgenoten beoordeeld voordat deze aan u wordt aangeboden.
Technische beoordeling
Een tweede tester controleert de bevindingen zelf: is de kwetsbaarheid reëel, is de impact correct ingeschat, is de stap-voor-stapbeschrijving nauwkeurig en is er iets binnen de reikwijdte over het hoofd gezien?
Inhoudscontrole
Een afzonderlijke controle van het rapport als document: wordt elke bevinding duidelijk genoeg toegelicht om er actie op te ondernemen, is de risicobeoordeling onderbouwd, is het advies voor het verhelpen van de problemen specifiek in plaats van algemeen, en zal het rapport begrijpelijk zijn voor de ontwikkelaar die het probleem moet verhelpen en voor de manager die het werk moet goedkeuren?
Dit geldt ook voor grote projecten. Het is van toepassing op elke test, op elk niveau.
DigiD-beoordelingen, waarbij de auditor reeds deel uitmaakt van ons team
Organisaties die een DigiD-beoordeling moeten ondergaan, hebben doorgaans twee leveranciers nodig: een partij die de penetratietest uitvoert en een geregistreerde IT-auditor die het auditrapport opstelt. Dit houdt in: twee contracten, twee tijdschema’s en een overdracht tussen beide partijen.
CREDS beschikt over eigen, gecertificeerde IT-auditors (RE). Onze RE begeleidt de penetratietest, werkt gedurende het gehele proces rechtstreeks samen met de testers en stelt het aanvullende hoofdstuk op dat als input dient voor uw DigiD-audit, als onderdeel van dezelfde opdracht.
Wij integreren controlekaders zoals DigiD in de test zelf, zodat de test vanaf het begin is afgestemd op de vereisten en niet pas achteraf hieraan wordt aangepast. Het resultaat is één leverancier, één tijdschema en een auditrapport dat is opgesteld door iemand die de test heeft bijgewoond.
Van toepassing op DigiD en op organisaties die volgens BIO werken.
U wacht niet in het donker
Een penetratietest mag geen ‘black box’ zijn die pas drie weken later een rapport oplevert. Hieronder leest u wat er gebeurt terwijl het werk in volle gang is.
Dagelijkse meldingen bij het starten en stoppen
U ontvangt elke dag een melding wanneer de testactiviteiten beginnen en eindigen, zodat uw team altijd weet of het verkeer naar de applicatie van ons afkomstig is of van iemand anders.
Bevindingen met een hoog risico worden onmiddellijk doorgegeven
Mocht er iets ernstigs aan het licht komen, dan wordt u hiervan op de hoogte gesteld zodra dit is bevestigd, en niet pas in het rapport. Een kritieke kwetsbaarheid is niet iets dat men moet achterhouden tot de afsluitende vergadering.
Resultaten zijn in realtime zichtbaar
Bevindingen verschijnen direct in het klantenportaal zodra ze worden gemeld, zodat uw ontwikkelaars al aan de slag kunnen gaan voordat de opdracht is afgerond, in plaats van te moeten wachten op een document.
Wij stellen de test samen met u opnieuw af
Een penetratietest heeft een vast tijdsbestek, wat betekent dat er altijd een keuze is waar de resterende uren aan worden besteed. Tijdens de test brainstormen wij samen met uw team over waar wij ons vervolgens op moeten richten, op basis van wat wij tot dusver hebben vastgesteld en wat u weet over de applicatie. Een bevinding op één gebied maakt een ander gebied vaak interessanter dan in het oorspronkelijke plan was voorzien.
Wat u ontvangt
Een ontwerpverslag, dat wordt besproken voordat het definitief wordt. Wij nemen de bevindingen en de risicobeoordelingen met u door, zolang er nog tijd is om eventuele misverstanden over uw omgeving recht te zetten. Geen enkele klant zou een definitief rapport voor het eerst moeten lezen.
Het volledige rapport. Elke bevinding, de gevolgen daarvan, een procedure voor het reproduceren ervan en specifiek advies voor herstelmaatregelen.
Een klantoverzicht voor uw belanghebbenden. Een afzonderlijke, begrijpelijke samenvatting die is bedoeld voor degenen die inzicht moeten krijgen in het resultaat en het werk moeten goedkeuren, en niet voor degenen die het werk uitvoeren.
Een stappenplan voor sanering, indien van toepassing. Indien uit de bevindingen blijkt dat er eerder een plan dan een takenlijst nodig is, zullen wij dit samen met u uitwerken.
Blijvende toegang tot onderzoeksresultaten. Uw uitslagen blijven beschikbaar in het klantenportaal, inclusief verzoeken om heronderzoek.
Uw bevindingen, allemaal op één plek
Bij elk CREDS-webapplicatieproject krijgt u toegang tot het klantenportaal. Daar verandert de test van een document in iets waarmee uw team daadwerkelijk aan de slag kan.
Live-bevindingen
Bevindingen worden op het portaal gepubliceerd zodra ze tijdens de test aan het licht komen, vergezeld van informatie over de gevolgen en aanbevelingen voor het verhelpen ervan.
Verzoeken om heronderzoek
Wanneer een oplossing is geïmplementeerd, dient u via het portaal rechtstreeks een hercontrole aan te vragen met betrekking tot de oorspronkelijke bevinding, zodat de verificatie bij het probleem zelf wordt vastgelegd in plaats van in een spreadsheet te worden bijgehouden.
Integratie van het ticketsysteem
De bevindingen worden geïntegreerd in de tools waarmee uw ontwikkelaars al werken, waaronder Jira en ServiceNow, zodat het verhelpen van problemen plaatsvindt binnen uw bestaande sprintproces in plaats van in een parallel proces.
Geschiedenis van de verschillende opdrachten
Eerdere tests en de bijbehorende resultaten blijven beschikbaar, zodat u kunt zien wat er tussen de ene test en de volgende is veranderd.
Hertesten zijn inbegrepen in de opdracht. Het controleren of een oplossing daadwerkelijk heeft gewerkt, kost u niets extra.
Security that moves with your release schedule
Wij geloven dat het testen van webapplicaties een samenwerkingsreis is. Door met u samen te werken, streven we ernaar niet alleen kwetsbaarheden te identificeren, maar ook samen te werken om de algehele beveiliging en functionaliteit van uw product te verbeteren. Onze aanpak omvat een continue dialoog, waarbij we onze testinspanningen afstemmen op uw ontwikkelcyclus om ervoor te zorgen dat beveiliging gelijk groeit met uw applicatie.
We pleiten voor periodieke tests die aansluiten bij uw ontwikkelsprints en releaseschema. Deze methode stelt ons in staat om systematisch nieuwe functies en wijzigingen aan te pakken, zodat elk aspect van uw applicatie wordt gecontroleerd op kwetsbaarheden voordat het live gaat. Dit doorlopende proces helpt niet alleen bij het handhaven van een robuuste beveiligingshouding, maar integreert ook naadloos met agile ontwikkelpraktijken, waardoor beveiliging een hoeksteen wordt van uw productontwikkelingscyclus.
Because findings flow into your ticket system and retests are requested from the portal, recurring testing fits your existing sprint process rather than sitting alongside it.
Vragen over het testen van webapplicaties
Test u zowel de API als de frontend?
Welk testniveau hebben wij nodig?
Heeft u toegang nodig tot onze broncode?
Is dit een geautomatiseerde test?
Maakt u gebruik van het ART-platform voor het testen van webapplicaties?
Hoe weten wij dat de test grondig is uitgevoerd?
Wat gebeurt er als wij de geconstateerde gebreken hebben verholpen?
Kunnen de bevindingen rechtstreeks naar onze ontwikkelaars worden doorgestuurd?
Hoe lang duurt een test?
Kunt u onze DigiD-beoordeling ondersteunen?
Zullen wij al vóór de publicatie van het rapport op de hoogte worden gesteld van ernstige bevindingen?
Bent u klaar om uw applicatie te testen?
Vertel ons wat de applicatie doet en hoe vaak deze verandert, dan zullen wij u aangeven welk testniveau geschikt is en wat daarvoor nodig is.