In januari 2020 zijn we gestart met hoofdstuk 1 (link), in februari met hoofdstuk 2 (link), in april met hoofdstuk 3 (link), in mei met hoofdstuk 4 (link), in juni met hoofdstuk 5 (link), in juli met hoofdstuk 6 (link), in augustus hoofdstuk 7 (link), in september hoofdstuk 8 (link), in november hoofdstuk 9 (link), in februari 2021 hoofdstuk 10 (link), in maart 2021 hoofdstuk 11 (link), in april 2021 hoofdstuk 12 (link), in mei 2021 hoofdstuk 13 (link) en nu wordt het tijd voor hoofdstuk 14.
De Timo-samenvatting
Voer niet alleen code-reviews uit, maar ook code-security reviews. Zorg dat er pen-testen uitgevoerd worden, deel de resultaten en zorg voor een oplossing voor het complete probleem en niet alleen van deze bevindig. Zorg dat je up-to-date blijft met de laatste security issues. Als je het vermoeden hebt dat er wat aan de hand is, ga niet alleen kijken wat er aan de hand is, maar mobiliseer je collega's en andere afdelingen om ook te kijken of er wat gebeurt en zo ja, wat er aan gedaan kan worden. Beter 10x vals alarm, dan 1x geen alarm en dat al je klantgegevens op straat liggen.
A final word
We hebben het laatste hoofdstuk bereikt. A final word, dat klopt niet helemaal, want het hoofdstuk is 16 pagina's lang. Dus het is iets langer dan een woord ;) De vorige hoofdstukken waren over hoe je eigenlijk "ongemerkt' je code veiliger maakt, dit hoofdstuk gaat er juist expliciet over. Ergens in hoofdstuk 1 zijn deze zaken geconstateerd:
- Ontwikkelaars vinden het moeilijk en afleidend om tijdens het programmeren over veiligheid/security na te denken. "Ik heb hier een probleem X en daar heb ik het al moeilijk genoeg mee om er een werkende oplossing voor te vinden".
- Ontwikkelaars vinden het gewoon om tijdens het programmeren over het ontwerp na te denken (en gewenste aanpassingen door te voeren)
- Veel security-zaken ontstaan door bugs, code die net anders werkt dan bedoeld en daardoor zaken open zet die niet opengezet hadden moeten worden
- Een goed ontwerp vermindert het aantal bugs, welke bugs voorkomen worden, dat hangt dan weer af van welk type ontwerp je kiest
In dit hoofdstuk worden een aantal zaken benoemd om je code veiliger te maken. Kort behandeld, als er dieper ingedoken zou worden, zou dat een boek op zichzelf kunnen vullen.
Code security reviews
Het is de bedoeling om met code reviews te gaan werken. Laat je collega('s) de code zien en hoor wat zij er van vinden. Dit kun je ook met een security-bril doen. Dus kijken of er met domein-objecten gewerkt wordt. Of dat er met MD5 hashing gewerkt wordt (dat is al een tijd niet meer afdoende).
Om een goede security review te doen is het natuurlijk niet de bedoeling dat je in het wilde weg maar wat gaat bekijken/testen. Je kunt het beste een checklist gebruiken, zodat je zaken kunt afvinken. Het boek komt met de volgende voorbeeldlijst:
- wordt de data die heen en weer gaat in de web-applicatie op een correcte manier geëncode?
- worden HTTP headers die security-gerelateerd zijn goed gebruikt?
- wat wordt gedaan om cross-site scripting aanvallen te voorkomen?
- worden de onveranderlijke zaken in domein primitieven goed genoeg gecontroleerd?
- zit er in het deployment ook geautomatiseerde security tests?
- hoe vaak worden wachtwoorden in het systeem vervangen?
- hoe vaak worden certificaten in het systeem vervangen?
- hoe wordt voorkomen dat gevoelige data in log-bestanden/data weggeschreven wordt?
- hoe worden wachtwoorden beschermd en opgeslagen?
- worden alle query's naar de database via parameters doorgegeven (sql injection)?
- wordt er gemonitord op security zaken en is er een proces als er incidenten gedetecteerd worden?
Het advies is om niet alleen je eigen team te laten security-testen, maar ook andere partijen.
Keep track of your stack; als je een paar projecten hebt, dan kun je de updates e.d. wel bijhouden. Maar als je 100-en projecten hebt, met tig nuget-packages (bijvoorbeeld), dan zul je iets moeten maken om te zorgen dat als er een groot security-issue is je met gepaste snelheid ervoor kunt zorgen dat je code bijgewerkt wordt.
Het samenvoegen van informatie; er zijn tools die een overzicht kunnen geven van meerdere security-issues. Het boek noemt https://dependencytrack.org. Voor specifieke uitleg zul je bij de component/bouwer zelf moeten zijn, maar met deze tools kun je een algemeen overzicht krijgen van wat er mogelijk speelt qua risico's met security.
Denk na hoe je de prioriteit van de security-issues gaat bepalen. Kan iedereen bij logbestanden komen, of kan er iets fout gaan bij een bepaalde input op een URL, maar is die URL afgeschermd van de buitenwereld? Ook zul je moeten bepalen wie de bugs gaat fixen/updates gaat doorvoeren, omdat er ook andere werkzaamheden uitgevoerd moeten worden.
Voer penetratie-tests uit (pen tests) om de zwakke punten in je applicatie bloot te leggen. In 9 van de 10 gevallen zul je code opleveren die "niet helemaal is hoe je het had willen bouwen". Dat kan door externe oorzaken komen (ik moet een verbinding maken met een legacy system wat een oude TLS standaard gebruikt) of door interne oorzaken (tijdgebrek: zo moet het maar). Volgens het boek moet de pen tests ook de technische aspecten van een systeem kennen (authenticatie mechanisme, certificaten), zodat de business-rules getest kunnen worden. Hierbij wordt het voorbeeld genoemd van online reserveren bij een restaurant. Annuleren is kosteloos. Dus je reserveert eerst alle plekjes. En dan 5 minuten daarvoor annuleer je jouw reserveringen. Een soort "denial of service", want het restaurant is deze avond leeg. Dit is een scenario wat meegenomen zou moeten worden in een pen-test.
Leer van je fouten; als er bevindingen zijn, bespreek die met iedereen van het team. Je moet zulk soort zaken niet onder het tapijt vegen, maar juist goed bespreken. Het opent de ogen, "oh, daar had ik niet over nagedacht" en zal er (hopelijk) voor zorgen dat een volgende keer er wel over nagedacht wordt en dus niet weer voorkomt.
Wanneer en hoe vaak je een pen-test uit moet voeren, daar kan het boek niet echt een uitspraak over doen. Het hangt ook af van je project. Wijzigt de externe API die je gebruikt en dus ook jouw code, dan is dat een goede gelegenheid om een pen-test uit te voeren. Ook wordt verwezen naar context driven testing: https://context-driven-testing.com/
Je kunt naast een professionele organisatie de boel te laten testen ook een "bug bounty hunt" starten. Tenminste, dat zegt het boek. De eigen ervaring is dat Indiërs of Pakistani gaan melden dat een wp-json URL open staat en of je even een hoodie wilt sturen. Je moet dus wel erg zeker van je zaak zijn (en ook zaken die niet heel spannend zijn) dicht spijkeren. Zoals het boek zegt: je moet bij een bevinding wel checken: hoe serieus is het, hoeveel is het waard en hoe snel moet het gefixt worden? Het boek verwijst naar Hack the Pentagon en
Blijf op de hoogte van security-zaken. Voor (goede) developers is het al zwaar om met je huidige werk bij te blijven bij alle ontwikkelingen. Maar daar hoort dus ook security bij. Het boek verwijst naar de top 10 van 2017 van OWASP (link). Dat is bijna 4 jaar geleden, hoewel die zaken vast nog actueel zijn, kun je het beste ook de gewone OWASP pagina bekijken: link. Voor mezelf staat hier nog het boek "Domain Driven Design" van Evans op de boekenplank, door blogposts, meetings te volgen leer je er weer zaken bij.
Een security-issue treedt op. En nu?
Je site ligt plat omdat via SQL injection een stuk javascript in je pagina's geplaatst is. Of een ander vervelende actie. Wat doe je?
Incident afhandeling
De developers / het team weet hoe de site werkt. Dus bij een probleem kan dit deel van het bedrijf het beste de eerste actie ondernemen. De vragen die ontstaan tijdens zo'n voorval, daar wil je snel antwoorden op krijgen. Het boek komt met de volgende vragen:
- hoe krijgen de aanvallers toegang tot het systeem? En hoe kunnen we dat zo snel mogelijk afsluiten (bijvoorbeeld DB-connectie uitschakelen).
- welke andere onderdelen (databases, infrastructuur) kunnen hierna overgenomen worden en wat kunnen de aanvallers met de data die ze nu hebben (vanuit toegang tot 1 database vervolgens toegang tot de hele database-server en dus alle databases op dit systeem).
- welke gegevens hebben de aanvallers kunnen inzien (klantgegevens, financiële informatie)?
- kun je zorgen dat de hoeveelheid data die ingezien kan worden beperkt wordt (zelf een tabel legen, aangezien er nog wel een backup is)?
- kun je ook "nep-data" toevoegen, zodat de hacker niet meer weer wat nu wel geldige info is en wat niet?
- hoe kun je de schade beperken (bijvoorbeeld door klanten, partner, agentschappen of het publiek te informeren)?
Probleem oplossen
Dit is de vervolgstap. Hoe kon het probleem ontstaan en hoe kunnen we voorkomen dat het nogmaals gebeurt.
- welke zwakke punten in het systeem heeft de aanvaller misbruikt? zat er een fout in de code of in een code-bibliotheek die gebruikt wordt?
- of wat het een combinatie van meerdere zwakke punten waarmee die gedaan kon worden? bijvoorbeeld: machine X had een issue, maar werd afgeschermd door code Y. Dat was een externe code-bibliotheek, daar is een update van doorgevoerd en daar zat een security-issue in, waardoor het issue van machine X misbruikt kon worden.
- hoe kon de aanvaller weten welke zwakke punten er in het systeem waren? Teveel informatie in de error-schermen? Een ander soort disclosure?
- hoe kwam het zwakke punt in de code? een eigen fout (en bij de code review niet gevalideerd) of door een externe code-bibliotheek die niet op tijd bijgewerkt is?
Het is niet alleen de boel dichttimmeren om het probleem in de toekomst te voorkomen, maar ook het proces: waardoor is het ontstaan en hoe kunnen we dat in de toekomst voorkomen?
Resilience, de wet van Wolff’s en anti-fragiliteit
Door bevindingen en oplossingen moet het systeem "sterker" worden. Door bij problemen je checklists aan te vullen zorg je dat er meer en beter getest wordt en dat problemen waar je eerder (mogelijk) tegenaan liep nu al eerder opgelost worden.
Het boek toont een lijstje met acties die op een SQL injection bevinding van een pen-test op kunnen treden;
0: het team negeert de bevinding(en) en zet het product online. Je vraagt dus om problemen...
1: het team zorgt dat de bevinding afgevangen wordt. Maar dat is het dan ook.
2: het team controleert en fixt ook de andere plaatsen waar deze bug op kon treden. Een iets actievere aanpak.
3: het team denkt na over de gedachtegang van deze test en bevinding en concludeert dat de code aangepast moet worden om te zorgen dat de fix structureel is, de bevinding van de pen-test heeft alleen case A aangetoond, maar het team zorgt dat ook case B en case C voorkomen worden.