Maar waarom is het nu interessant om deze informatie tot je te nemen als niet-technisch persoon? Simpelweg omdat jij degene bent die technici aanstuurt, of op een andere manier iemand bent waarnaar geluisterd wordt. Jij hebt de mogelijkheid om onderwerpen zoals Secure Coding op de kaart te zetten en daarmee de mensen te ondersteunen die meestal een constante druk ervaren om nieuwe functionaliteit te blijven leveren. Deze engineers hebben het dan vaak te druk om genoeg aandacht te besteden aan de veiligheid van hun code. Input vanuit directie/management met betrekking tot het onderwerp Secure Coding is dan van onschatbare waarde, zeker wanneer dit met kennis van zaken geschiedt.

Veilig programmeren is zeker niet het enige onderwerp met betrekking tot het veiliger maken van een applicatie. In deze Executives Guide serie van artikelen, heb ik al geschreven over een aantal andere onderwerpen (zie de links onderaan dit artikel).

Manieren om Secure Coding toe te passen

Invoervalidatie

Invoervalidatie, ook wel input validation of data validation genoemd, is het op correctheid testen van invoer die door een gebruiker of applicatie wordt geleverd (bron: NTT Application Security). Denk hierbij bijvoorbeeld aan een gebruiker die op een website een gebruikersnaam en wachtwoord invoert. Ziet de gebruikersnaam eruit als een emailadres? Bevat het wachtwoordveld tekens die niet toegestaan zijn? We willen natuurlijk voorkomen dat iemand een manier heeft gevonden om onze applicatie in de war te brengen met rare invoerwaarden, waardoor ze ongewenste toegang verkrijgen tot onze systemen. Dit is een realistisch risico.

Omdat het moeilijk is om een kwaadwillende gebruiker te detecteren, moeten applicaties alle invoer in een systeem controleren en valideren. Invoervalidatie moet plaatsvinden wanneer gegevens worden ontvangen van een externe partij, vooral als de gegevens afkomstig zijn van niet-vertrouwde bronnen.

Hoe werkt dat dan, het valideren van invoer? Nadat een gebruiker tekst heeft ingevoerd in een applicatie, willen we de invoer het liefst al controleren voordat het naar onze server wordt opgestuurd. Dit doen we door een patroon op te geven waar de ingevoerde tekst aan moet voldoen. Bijvoorbeeld door te programmeren dat de tekst in het gebruikersnaamveld altijd een emailadres moet zijn. We kijken dan of er een ‘@’ en domeinnaam (b.v.: gmail.com) in zit. Als dit er allemaal goed uitziet, laten we de gegevens opsturen naar onze server, zodat we ze kunnen verwerken. Als we dan op onze server nog eens controleren of alles er goed uitziet, weten we zeker dat we het veilig kunnen gebruiken.

Authenticatie & autorisatie

Je bent vast al bekend met deze termen, maar de kans is groot dat het verwarrend is om ze uit elkaar te houden. Er zit namelijk een belangrijk verschil tussen de twee. Authenticatie is het proces om te verifiëren wie iemand is; denk aan het controleren van een ID-kaart (bron: SailPoint). Je controleert in dit geval iets wat iemand heeft. Je kunt ook iets controleren wat iemand weet (b.v.: een wachtwoord) of wat iemand is (b.v.: een vingerafdruk). Autorisatie is het proces om te verifiëren tot welke specifieke applicaties, bestanden en gegevens een gebruiker toegang heeft. Met andere woorden: welke rechten iemand heeft. Dit kun je vergelijken met het controleren van een gastenlijst. Nadat je iemands identiteit weet, kun je bekijken of ze het terrein op mogen en welke gebouwen ze mogen betreden.

Om het gehele proces goed te begrijpen, kan het helpen om aan een hotelkamerpas te denken. Bij de receptie wordt aan de hand van een identiteitsbewijs gecontroleerd of jij de persoon bent die de reservering heeft gemaakt. Dit is het stukje authenticatie. Vervolgens pakt de receptionist een blanco pas en programmeert hier een autorisatie op. Iets in de richting van: “Pas 123 heeft toegang tot alle deuren van kamer 456.” Eenmaal bij je kamer aangekomen, laat je het pasje uitlezen in het slot. Het apparaat controleert of het pasnummer geldig is en of deze toegang heeft tot de kamer. Als dit allemaal overeenkomt met het reserveringssysteem van het hotel, kun je de deur openen.

Sessiebeheer

Iedereen heeft dagelijks met deze techniek te maken, terwijl relatief weinig mensen begrijpen wat het is. Stel je even voor wat je elke dag zoal doet op het internet. Elke website waar je in moet loggen gebruikt al sessiebeheer, maar ook veel websites waarbij dit niet nodig is houden bij wie je bent. Het is namelijk een manier voor webapplicaties om te onthouden welke informatie er met jou is uitgewisseld. Het wordt ook wel omschreven als het proces van het veilig afhandelen van meerdere aanvragen van één gebruiker of entiteit voor een webapplicatie of -service (bron: Veracode).

Het is wel belangrijk om te begrijpen dat ik hier niet bedoel te zeggen dat iedere website weet wat je naam is of waar je woont. “Weten wie je bent” verwijst naar het contact wat jij eerder met de website hebt gehad. Welke pagina’s heb je bezocht bijvoorbeeld.

Waarschijnlijk spreekt het volgende wel tot de verbeelding. Je bezoekt je favoriete social mediawebsite. Je constateert dat je niet ingelogd bent, dus je voert je gebruikersnaam en wachtwoord in. Vervolgens speelt zich een stukje authenticatie en autorisatie af, waarna je een gepersonaliseerde omgeving te zien krijgt. Als ik je vraag hoe de website nu weet dat het berichten van jouw connecties moet laten zien, antwoord je waarschijnlijk: “Ik heb toch ingelogd? Dan weet de website wie ik ben.” Natuurlijk heb je gelijk, maar er komt nog net iets meer bij kijken. Dat inloggen hoef je alleen de eerste keer te doen. Daarna kun je onbezorgd de website doorspitten, zonder steeds aan te moeten tonen dat jij het bent. Dit wordt mogelijk gemaakt door sessiebeheer.

Nadat de webapplicatie had gecontroleerd of je inloggegevens correct zijn, heeft het een sessie aangemaakt door iets op te slaan in je browser (meestal met een cookie, ook wel session cookie genoemd). Bij elke pagina die je vanaf dat moment bezoekt, wordt die session cookie meegestuurd. Zo weet de applicatie dus constant of het jouw persoonlijke omgeving moet laten zien of die van iemand anders.

Waarom is sessiebeheer nou interessant in het licht van informatiebeveiliging? In de vorige paragraaf heb je gelezen dat een cookie de website vertelt wie je bent, waarna de website al jouw persoonlijke gegevens laat zien. Ik hoop dat je ziet dat dit een ontzettend groot risico vormt. Als ik het namelijk voor elkaar krijg om jouw session cookie te stelen, kan ik de website doen denken dat ik jou ben. Ik kan dan al jouw connecties zien, welke gegevens er in je profiel zitten en bijvoorbeeld je wachtwoord aanpassen. Dit is waarom het belangrijk is om na te denken op welke manieren je deze aanval kunt voorkomen. Op de erg technische webpagina OWASP Cheat Sheet Session Management, wordt uitgelegd welke acties je precies kunt nemen om goed sessiebeheer te implementeren.

Foutafhandeling, logging & monitoring

Dit is misschien wel een van de moeilijkste onderwerpen om goed uit te leggen, maar wel echt heel belangrijk. Als securityspecialisten willen we natuurlijk graag dat ontwikkelaars hun code zo veilig mogelijk maken, om te voorkomen dat er een hack plaatsvindt. We beseffen ons alleen wel dat je dit nooit 100 procent af kan dekken. Daarom vinden we het heel erg belangrijk om goede logging en monitoring te hebben.

Wat is dat dan, logging? We zijn natuurlijk allemaal bekend met het feit dat applicaties een bepaalde functionaliteit bieden. Neem bijvoorbeeld LinkedIn, een webapplicatie. In de applicatie is het mogelijk om berichten te schrijven, te lezen en nog heel veel meer. Elke actie die je onderneemt op de site, kan LinkedIn opslaan. Dit zal er dan ongeveer zo uitzien: “Gebruiker x heeft profiel y bekeken” of “Gebruiker x heeft een bericht geplaatst”. Het opslaan van deze ondernomen acties noem je logging.

Wat kun je daar dan mee? In de meeste gevallen is die logging helemaal niets waard. Maar wat als er iets fout gaat? Dat is wel interessant. Elke keer dat je een bericht probeert te plaatsen en een error terugkrijgt, wordt dit waarschijnlijk opgeslagen. Als honderden verschillende mensen deze error binnen een uur ervaren, is er waarschijnlijk iets aan de hand met de website. Het in de gaten houden van logging, heet monitoring. Je kunt hele nuttige conclusies trekken uit logging; ook op beveiligingsgebied. Als we bijvoorbeeld zien dat een gebruiker binnen een paar minuten vanuit vijf verschillende landen in probeert te loggen, is er waarschijnlijk iets niet in de haak.

Het ging in dit voorbeeld over het detecteren van errors. Hoe we daarmee omgaan noem je foutafhandeling. Vertellen we de gebruiker simpelweg dat de actie niet gelukt is en dat het maar opnieuw geprobeerd moet worden? Proberen we de actie automatisch nog eens uit te voeren? Blokkeren we de gebruiker, omdat we denken dat ze iets aan het doen zijn wat niet gewenst is? Dit zijn allemaal voorbeelden van het omgaan met fouten.

Codedekking

Nog een abstract concept, codedekking. Je kunt je vast voorstellen dat programmeurs hun code testen. Doet de applicatie wel wat het moet doen? Tegenwoordig laten de meeste ontwikkelaars dit automatisch uitvoeren. Ze schrijven dan een set regels waar de applicatie aan moet voldoen: “Als ik op knop a klik, opent scherm b.” Het percentage van code waarvoor je zo’n regel hebt geschreven, is codedekking. Je begrijpt het misschien al wel: hoe meer dekking, hoe beter.

Maar waarom is dit nou belangrijk vanuit een beveiligingsperspectief? De code die niet getest wordt, omdat er geen regel voor is geschreven, kan fouten bevatten die een beveiligingslek vormen. Dat willen we natuurlijk niet, dus is het belangrijk om er een gewoonte van te maken om voor elk klein dingetje in een applicatie een testregel te schrijven. Het houdt natuurlijk niet op bij het behalen van een zo hoog mogelijke codedekking, maar het is net zo belangrijk om goede testen te schrijven. Testen of een knopje een scherm opent is leuk, maar het is nog veel interessanter om te weten of het account wat een gebruiker aanmaakt wel op de juiste manier wordt opgeslagen. Op het moment dat het om het verwerken van informatie gaat, kunnen namelijk de grootste beveiligingsrisico’s ontstaan. Je kunt bijvoorbeeld testen of er geen gekke tekens worden opgeslagen of dat een getal wel als getal wordt opgeslagen (niet als tekst).

Hoe gebruik ik deze informatie in mijn voordeel?

Het is natuurlijk fijn wanneer je alle aangereikte kennis en informatie met betrekking tot Secure Coding in de praktijk kunt gebruiken. Omdat het veel materie is heb ik een aantal dingen voor je op een rijtje gezet:

1. Vraag eens na hoe er om wordt gegaan met invoervalidatie binnen een applicatie in jouw organisatie. Bepaal of er wat gedaan moet worden om dit te verbeteren en wat dan.
2. Hoe zit het met de (verschillende) authenticatie & autorisatie systemen in de organisatie? Wordt er gebruik gemaakt van het Single Sign-On (SSO) principe of heeft elke applicatie een eigen oplossing? Wordt er genoeg nagedacht over de beveiliging van deze systemen?
3. Hoe worden sessies beheerd in de applicatie? Gebeurt dit volgens de OWASP best practices? Als dit ingebouwd zit een applicatie framework, ga dan na of deze up-to-date is.
4. Stel vast welke logging er wordt gegenereerd. Gebeurt dit alleen op besturingssysteemniveau of doet de applicatie dit ook uitgebreid? Vervolgens moet je je afvragen of er wel genoeg gedaan wordt met de gegenereerde logging data. Worden deze data gebruikt in een dashboard wat inzichten verschaft of zijn er alerts ingesteld voor specifieke problemen?
5. Wordt de applicatie wel uitgebreid automatisch getest en hoeveel codedekking is er dan? Als de functionaliteit uitgebreid getest wordt, is het een goed idee om meer focus te leggen op securitytests.
6. Heb je moeite met het analyseren of implementeren van Secure Coding? Besteed het dan uit aan de cybersecurityspecialisten van SALT Cyber Security! Het inschakelen van een onafhankelijke specialist met (meer) expertise van Secure Coding is een aanrader, ook vanuit het principe van “vreemde ogen dwingen”

Be safe!

De cybersecurityspecialisten van SALT