Als je ons vraagt om een penetratietest (pentest) uit te voeren op een applicatie, dan gaan wij je vragen om de code van die applicatie vooraf met ons te delen. Een pentest is namelijk veel effectiever als de pentester de code bij de hand heeft. In ons jargon noemen we dit een white box test.
In deze blog ga ik het hebben over drie bezwaren die wij soms te horen krijgen tegen het delen van code en hoe we hiermee omgaan. Maar eerst in het kort nog even waarom het delen van de code een test zoveel effectiever maakt.
Toegang tot code maakt een test effectiever
Een applicatie testen zonder de code te kunnen zien is blind prikken om te achterhalen wat er mis is. Natuurlijk zitten veel zwakheden direct aan de oppervlakte: direct object references, onvoldoende input- en outputvalidatie of file upload kwetsbaarheden. Maar andere zwakheden niet. Logische problemen of race conditions bijvoorbeeld, zijn veel minder zichtbaar en kosten meer tijd om te vinden.
De kans is groot dat een ervaren pentester, voorzien van de juiste tools, uiteindelijke de meeste van dit soort kwetsbaarheden wel zal achterhalen, maar met af en toe een blik op de code gaan we ze altijd sneller vinden. En vollediger: hebben we eenmaal een kwetsbaarheid dan kunnen we in de code zo alle plekken zien waar die voorkomt. En diepgaander: met prikken zie je symptomen, in de code zie we de oorzaak waar we advies op kunnen geven.
Daarom is een pentest niet compleet zonder toegang tot de code en vragen we er om: zo bereiken we het snelst resultaat zonder in te leveren op kwaliteit. Sterker nog: een partij die pentests aanbiedt zonder zelf naar de code te vragen is wat ons betreft een partij om te mijden.
Maar soms horen we bezwaren. Hieronder beschrijf ik er drie, en hoe we ermee omgaan.
“Jullie zijn toch hackers? Waarom zouden we jullie de code geven?”
De gedachte achter deze opmerking is dat het “valsspelen” is om ons de code en daarmee een oneerlijke voorsprong te geven, en dat het geen realistische nabootsing is van de werkelijkheid, waarin tegenstanders geen toegang hebben tot de code.
En dat is waar. Maar wat ook waar is, is dat elke applicatie aan internet non-stop onder vuur zal komen te liggen van geautomatiseerde scans, scripts en hackpogingen, inclusief van tijd tot tijd handmatige pogingen. Geen enkele black box test met een redelijke prijs kan daarbij in de buurt komen.
Een pentest is dus niet bedoeld om een realistische nabootsing van de werkelijkheid te zijn. Een pentest is een manier om inzicht te krijgen in de zwakheden van een applicatie en die wil je zo effectief mogelijk gebruiken om je risico’s te kunnen managen. Met dit inzicht begrijpen de meeste mensen dat het de voorkeur heeft om onze ethische hackers inzicht in de code te geven.
“Onze ontwikkelaars willen de code niet geven” Dit bezwaar horen we, maar gelukkig niet vaak. Als ontwikkelaars hun code niet willen delen met een derde, dan komt dat meestal doordat er geen vertrouwen is. Het kan zijn dat ze niet op de hoogte waren dat er een test zou gaan plaatsvinden of niet betrokken waren bij de aanloop er naartoe. En mogelijk zien ze de test als een soort ongewenst examen: een externe partij gaat hun werk beoordelen.
Het is best te begrijpen dat ontwikkelaars hun code beschermen en het is uiteindelijk ook zo dat een pentest betekent dat een externe partij zwakheden gaat aanwijzen in die code. Maar daar moet je natuurlijk gewoon doorheen. Je zou het kunnen forceren, maar een extra sessie met de ontwikkelaars waarin wij het proces, de uitkomsten en de doelstellingen toelichten helpt vaak al voldoende om mensen mee te krijgen. We zijn er om te helpen en de uitkomsten van een test kunnen leerzaam zijn en gebruikt worden om het product te verbeteren.
“Dit is intellectueel eigendom van ons / onze externe ontwikkelaar”
Het is problematisch als je de opdracht hebt gegeven tot het ontwikkelen van een applicatie en ervoor hebt betaald, maar de externe ontwikkelaar wil de code niet delen voor de uitvoer van een pentest. Je zult je contract moeten nalopen: als daarin expliciet uitgesloten wordt dat code mag worden gedeeld zul je dat eerst moeten aanpakken. Afhankelijk van de urgentie van de pentest moet je die wellicht door laten gaan zonder de code te delen. In een toekomstige blog zullen we dit onderwerp bespreken: contractuele afspraken met externe ontwikkelaars.
Het is waarschijnlijker dat er niks in je contract staat over het delen van code en dat de externe ontwikkelaar zich beroept op het feit dat de code intellectueel eigendom is. Of: soms wil je zelf je code niet delen omdat het je eigen intellectueel eigendom is.
Het willen beschermen van intellectueel eigendom is een valide doelstelling. Een geheimhoudingsverklaring is een prima instrument waarmee dagelijks duizenden bedrijven wereldwijd de risico’s managen die kleven aan het delen van vertrouwelijke informatie. In onze optiek zijn er maar weinig omstandigheden waarin een geheimhoudingsverklaring niet toereikend is, eventueel aangevuld met een beschrijving van beveiligingsmaatregelen. Denk dan bijvoorbeeld aan situaties waarin er direct mensenlevens op het spel zouden kunnen staan, of situaties waarin de regels van de (gerubriceerde) informatie het simpelweg niet toelaten. In alle andere gevallen helpt een extra sessie waarin we dit toelichten vaak voldoende om dit bezwaar weg te nemen.
Goede communicatie kan de meeste bezwaren wegnemen
Ik heb drie bezwaren toegelicht die we met enige regelmaat tegenkomen als we naar de code van een applicatie vragen, en de manier waarop we daarmee omgaan. Het zal geen verrassing zijn dat goede communicatie cruciaal is om deze bezwaren weg te nemen.
Ben jij nog niet overtuigd? Neem dan gerust contact op als je meer wil weten over het delen van code.