OWASP 2022: de praktijk

Auteurs: Patrick Bes en Arjen Kraak

Begin dit jaar is voor het eerst in lange tijd een nieuwe versie van de OWASP top 10 uitgebracht. Cybersecurity behoort een vast agendapunt te zijn voor elke ontwikkelaar en organisaties die betrokken zijn bij het ontwikkelen en onderhouden van software. Het adresseren van bedreigingen is niet alleen een technisch onderwerp maar ook een organisatorisch. In dit artikel delen we onze inzichten op beide onderwerpen.

De technische aspecten

De OWASP foundation is een non-profit organisatie met als doelstelling de veiligheid van software te vergroten. Ze hebben naam en faam gekregen door het samenstellen van de OWASP top 10. Hierin publiceren zij het overzicht van de 10 meest voorkomende kwetsbaarheden. Dit doen ze onafhankelijk van de gebruikte programmeeromgeving waardoor het overzicht breed toepasbaar is voor alle software ontwikkelingsprojecten. Voor .NET is een cheatsheet beschikbaar om je snel op weg te helpen: https://cheatsheetseries.owasp.org/cheatsheets/DotNet_Security_Cheat_Sheet.html.

De OWASP top 10 geeft een concrete lijst met risico’s waarmee je je software project controleert. Dit is iets wat gedurende het gehele ontwikkeltraject in de achterhoofden van ontwikkelaars moet zitten.

De nieuwe top 10

In 2021 hebben ze een update gegeven op de lijst zoals deze beschikbaar was vanaf 2017. Deze bevat een aantal wijzigingen. De lijst is het resultaat van uitgebreid onderzoek dat heeft plaats gevonden. Hierin wordt onder andere gemeten hoe vaak bepaalde kwetsbaarheden voorkomen en wat daarvan de impact is. Op basis van deze getallen is de volgorde binnen de top 10 vastgesteld. Wij zullen hier de belangrijkste aanpassingen en toevoegingen op de top 10 beschrijven.

blankBroken Access Control is nieuw binnengekomen op nummer 1 van plek 5 in 2017. Dit is een vrij algemene kwetsbaarheid en komt in de praktijk neer op gebruikers die zich meer toegang weten te verschaffen dan de gezette restricties zouden toestaan. Een concreet voorbeeld van deze kwetsbaarheid is het datalek bij Facebook in 2018. Men kon hier de “View As” functie gebruiken om een profiel te bekijken als iemand anders. De video upload functie werd dan sporadisch getoond wat niet de bedoeling was. Indien dit het geval was kreeg men een nieuw access token van de persoon waarmee men keek. Met dit token kon men vervolgens inloggen op het betreffende account. Dit komt dus grofweg neer op het misbruiken van bestaande functionaliteiten die op het eerste gezicht een logisch doel dienden. Het uitvoeren van security integratie testen en threat-modeling sessies kunnen in dergelijke gevallen wellicht een maatregel bieden om risico’s in kaart te brengen en te bewaken.

Cryptographic Failures deze kwetsbaarheid is 1 positie gestegen t.o.v. van 2017. Ook dit een vrij algemene kwetsbaarheid gerelateerd aan cryptografie (of het gebrek hieraan). Voorbeelden hiervan zijn b.v. het gebruik van verouderde algoritmes zoals: MD5, SHA1, DES. Zo is cryptografische hash methodiek van SHA-1 in 2017 al succesvol gehackt en sindsdien al niet meer bruikbaar. Helaas zijn er nog veel legacy applicaties in omloop waar deze algoritmes in zitten. De noodzaak om legacy applicaties aan te passen is hoog, maar niet altijd in het vizier. Een goede scan van de huidige code base op het gebruik van deze verouderde algoritmes is hier zeker een aanrader.

blankInjection is de kwetsbaarheid die jarenlang op nummer 1 heeft gestaan. Het is goed nieuws dat men hier bewuster van is geworden waardoor deze iets op de lijst is gezakt. Daarnaast is het een combinatie geworden van de oude vertrouwde SQL injection en de Cross-Site Scripting  kwetsbaarheid. Het gebrek aan het valideren van invoer is vaak een oorzaak. Na al deze jaren boven aan de top 10 te hebben gestaan zijn er toch nog concrete voorbeelden zoals b.v. de Fortnite hack uit 2019 was een combinatie van Cross-Site scripting en SQL-Injection. In je code base is het zaak rekening te houden met potentiële SQL Injection risico’s. Dus let op bij het dynamisch samenstellen van queries, doe aan invoer validatie, implementeer het least priviledge principe. Er zijn legio mogelijkheden om deze kwetsbaarheden te mitigeren en een scan op een legacy code base op dergelijke issue is altijd een aanrader.

blankAlle kwetsbaarheden die zijn opgenomen in de Top 10 zijn van groot belang. Een aantal hiervan staan al meerdere jaren vast en staan wellicht wel helder op het netvlies. Maar een aantal zijn volledig nieuw op de lijst en verdienen daarom wat extra aandacht.

Insecure Design legt de focus veel meer op de kwetsbaarheden die ontstaan door design en architectuur fouten. Deze kwetsbaarheid vraagt meer om oplossingen in de proces sfeer in plaats van technologische oplossingen. Denk hier b.v. aan Threat Modeling en secure design patterns, verder in dit artikel komen wij hierop terug. Voorbeelden van insecure design zijn scenario’s die op de tekentafel een goed idee lijken, maar waar in praktijk misbruik van kan worden gemaakt. Zo klinkt het voor een webshop vrij logisch om zoveel mogelijk klanten te kunnen helpen in zo kort mogelijke tijd. Maar in de praktijk kan dit betekenen dat kwaadwillenden de hele voorraad kunnen opkopen middels geautomatiseerde scripts. Dit is b.v. in praktijk voorgekomen bij de introductie van de Playstation 5. Aangezien dit niet te herleiden is naar een technische onvolkomenheid maar misbruik is van bewust geïmplementeerde features kan het dit lastig zijn om deze vroeg te herkennen. Door als team in de huid te kruipen van de kwaadwillende tijdens een threat modeling sessie kun je het wellicht wel herkennen als risico.

Software and Data Integrity Failures is een categorie die gaat over het doen van aannames gerelateerd aan software updates zonder hiervan de bron te controleren. In de loop van de tijd zijn we steeds meer afhankelijk geworden van externe code die afkomstig is van verschillende bronnen. Denk bijvoorbeeld aan NPM packages, Nuget packages, Docker images enz. Deze packages kunnen allemaal bronnen zijn van potentiële kwetsbaarheden die wij introduceren in onze code. Dit betreft dan supply chain hacks zoals wij hier al beschreven. Een voorbeeld hiervan is de hack van Asus laptop update service in 2019. Hierbij kregen gebruikers een update op hun laptop geïnstalleerd waarbij een kwetsbaarheid werd geïntroduceerd. Inmiddels zijn er legio producten op de markt die dit soort risico voor een groot gedeelte kunnen mitigeren in je build/release pipelines. (b.v. OWASP dependency check, Whitesource, Snyk, Prisma cloud, Sonatype Nexus en nog vele anderen) Nog veel organisaties hebben het gebruik van deze tooling helaas niet afdwongen. Dit is een aandachtspunt wat met relatief weinig effort te verhelpen is.

Server-Side Request Forgery is een nieuwe kwetsbaarheid die gaat over het ophalen van externe resources zonder dat de URL die wordt aangeleverd wordt gevalideerd. Een eenvoudig voorbeeld van deze kwetsbaarheid is bijvoorbeeld het aanleveren van een URL als file:///etc/passwd</span> waardoor er paswoorden gelekt kunnen worden in het resultaat. Andere scenario’s zijn bijvoorbeeld het kunnen scannen van interne poorten om zo een map van een intern netwerk te kunnen maken. Dit soort kwetsbaarheden zijn wat lastiger te vinden. DAST tools (zoals b.v. Tenable.io of Nessus) kunnen je hier wel bij helpen om hier (evt. geautomatiseerd) risico’s af te dekken.

Dit is maar een korte lijst van de belangrijkste verschillen maar neem vooral de tijd om goed te kijken naar alle kwetsbaarheden die in de top 10 zijn opgenomen. Daarnaast worden er op de site van OWASP.org nog meer oplossingsrichtingen aangedragen welke je in de juiste richten kunnen wijzen.

OWASP voor teams en organisaties

Het adresseren van bedreigingen kan niet zonder het borgen van maatregelen in de werkprocessen. We beschrijven de methodieken die kunnen worden gebruikt bij de waardeketen van softwareontwikkeling en onderhoud.

blank

De maatregelen worden genomen met verschillende invalshoeken:

  • Kijken naar de toekomst; wat kan gebeuren?
  • Kijken naar de actualiteit; welke impact maken we met huidige inspanningen?
  • Kijken naar de actualiteit; wat gebeurt er op dit moment in het landschap?

Wat zou er kunnen gebeuren?

Het beperken van beveiligingsrisico’s begint al tijdens het nadenken over vernieuwing en onderhoud. Het beleid van ‘security by design’ is hier van toepassing.  Met deze invalshoek kijken de bedenkers van oplossingen (ontwikkelaars) en de gebruikers (klant en stakeholders) samen naar mogelijke bedreigingen.

Dit kan worden gedaan tijdens een plenaire ‘Threat modeling’ sessie. Threat Modeling is een methodiek waarbij men bedreigingen in kaart brengt op basis van scenario’s en persona’s. Eerder is hierover een artikel geschreven.

In het kader van zo vroeg mogelijk inzicht krijgen in de mogelijke kwetsbaarheden is het aan te raden om een security self-assessment uit te voeren. Een dergelijk assessment geeft je veel handvatten om volledig beeld te krijgen van volwassenheid op security gebied. Dit geldt voor organisatorisch tot technisch. Het SAMM assessment van OWASP is hier een goed voorbeeld van SAMM Assessment (owaspsamm.org)

Cloud diensten bieden geautomatiseerde assessments aan tegen gangbare standaarden. Zo biedt Azure in Microsoft Defender for Cloud controles ten opzichte van: ISO 27001, HIPAA. Per standaard wordt een score gegeven:

blank

Microsoft Defender for Cloud geeft direct aanbevelingen voor aanpassingen in de eigen infrastructuur om de score ten opzichte van standaarden te verbeteren. De beheerder wordt direct doorgeleid naar de resources waarop de aanpassingen van toepassing zijn.

Welke impact maken we met de huidige inspanningen?

Als eigenaar van broncode is de organisatie verantwoordelijk voor de doorontwikkeling waarbij het ‘security by design’ principe als uitgangspunt wordt gehanteerd. Hiervoor worden de volgende middelen ingezet.

Borg beveiligingsoverwegingen in de ‘Definition of Done’; tijdens het schrijven van software geeft deze DoD een beleid over wanneer een stuk ontwikkelwerk als gereed kan worden beschouwd. De ‘DoD’ wordt tijdens discussie over de oplossing en taakverdeling gebruikt om de taken voor beveiliging te adresseren. Op deze manier, worden de maatregelen onderdeel van het reguliere ontwikkelwerk. Voorbeelden van ‘checkpoints’ zijn:

  • Wordt bij het uitvoeren van T-sql in code functie parameters gebruikt?
  • Worden foutmeldingen en stacktraces niet aan de gebruiker getoond?
  • Zijn controllers (MVC) voorzien van een Authorize attribuut of afgeleide ervan?

Pas het principe van ‘fail fast, fail often’ toe; dit principe heeft als doel om zo snel mogelijk inzicht te krijgen van de gevolgen van aanpassingen aan code. Dit kan worden gedaan door het toepassen van de volgende:

  • Beleid voor het verwerken van pull-requests (pull-request policies)
  • Verzekering van herleidbaarheid naar de Product Backlog door middel van links
  • Uitvoeren van een ‘pre-merge’ build
  • Automatische scans van de samengevoegde code door gereedschappen als SonarQube en WhiteSource. SonarQube kijkt vooral naar de code die de ontwikkelaar zelf schrijft. WhiteSource kijkt naar code die wordt hergebruikt van anderen (packages)

Wat gebeurt er op dit moment?

Het is cruciaal ook de huidige omgevingen te blijven bewaken. Deze bewaking kan worden uitgevoerd door het gebruiken van technische oplossing als bijvoorbeeld Azure Security Center of Azure Sentinal. Deze oplossingen bieden ‘high-end’ oplossingen voor het beveiligen van de cloud infrastructuur.

Tegenwoordig hebben veel organisaties een ‘hybride’ cloud afname. Hierbij bestaat een infrastructuur in eigen beheer naast een oplossing bij een cloud provider als Microsoft of Amazon. Hybride of niet, het is gebruikelijk om het platform bloot te stellen aan een ‘pentest’. Deze test, vaak uitgevoerd door een onafhankelijke partner, onderzoekt het platform als een hacker. De bevindingen hieruit worden geïntegreerd in het ontwikkelproces zoals dat eerder is beschreven. Op deze manier is de gehele waardeketen gedekt.

© Auteurs: Arjen Kraak en Patrick Bes © 2022 Bergler Competence Center

4.5/5 - (8 stemmen)
Deel deze pagina via:
berglerOWASP 2022: de praktijk