Met deze blog ga ik je helpen met het motiveren van ontwikkelaars om een applicatie veiliger te maken en waarom Secure Coding (financieel) voordeliger en ook voor ontwikkelaars interessant is. Uiteraard wordt dit betoog onderbouwd met een uitleg van termen en onderwerpen die de revue zullen passeren.
Het belang van het schrijven van veilige code wordt vaak onderschat. Vaker dan wenselijk heeft het zo snel mogelijk opleveren van code in de praktijk de prioriteit. Dit terwijl onveilige code aan de basis ligt van bijna alle computerbeveiligingsproblemen. De overgrote meerderheid van beveiligingsproblemen is terug te leiden naar onveilige code: bugs die leiden tot onvoorziene acties en ongewilde toegang tot systemen of applicaties. Steeds meer ICT is afhankelijk van code. Niet alleen applicaties, maar ook de netwerkinfrastructuur (Infrastructure as Code) en beveiligingscontroles (Security as Code) worden steeds meer in code geschreven. Het schrijven van veilige code is daarom van essentieel belang.
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).
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.
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.
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.
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.
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).
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:
Be safe!
De cybersecurityspecialisten van SALT
Softwareontwikkelaars bij veel organisaties geven aan dat zij niet over de kunde en/of tijd beschikken om applicaties veilig te bouwen. In dit artikel, een nieuwe rol die de balans tussen functie en beveiliging beter kan waarborgen.
Softwareontwikkelaars bij veel organisaties geven aan dat zij niet over de kunde en/of tijd beschikken om applicaties veilig te bouwen. In dit artikel, een nieuwe rol die de balans tussen functie en beveiliging beter kan waarborgen.
In een tijd waar software steeds vaker in slecht daglicht komt te staan door beveiligingslekken en databreuken, lijkt het kennisniveau van beveiliging structureel te laag. Lees hier waarom.
In een tijd waar software steeds vaker in slecht daglicht komt te staan door beveiligingslekken en databreuken, lijkt het kennisniveau van beveiliging structureel te laag. Lees hier waarom.
Cyber security lijkt in veel ontwikkelteams een optionele eis te zijn die pas aan eind van een traject wordt meegenomen. Benieuwd hoe dit komt en anders kan? Lees het hier.
Cyber security lijkt in veel ontwikkelteams een optionele eis te zijn die pas aan eind van een traject wordt meegenomen. Benieuwd hoe dit komt en anders kan? Lees het hier.
Toename datalekken in webapplicaties Het komt steeds vaker in het nieuws: datalekken in webapplicaties. Eén van de meest recente gevallen is een gegevenslek in de
Toename datalekken in webapplicaties Het komt steeds vaker in het nieuws: datalekken in webapplicaties. Eén van de meest recente gevallen is een gegevenslek in de
In dit artikel scheppen we orde in de chaos van cybersecurity, om catastrofale beveiligingsincidenten te voorkomen. In dit eerste artikel: pentesting en ethical hacking.
Ontwikkelaars moeten nieuwe features blijven implementeren en securityspecialisten hebben het te druk om ze te coachen. Een groot probleem, maar gelukkig is er een goede oplossing voor.
Informatiebeveiliging is een complex onderwerp. Hoe voer je een gesprek over Dependency Scanning en wat is het?
