Security & Compliance
Applicatiebeveiliging is de Verantwoordelijkheid van de Developer
Beveiliging in softwareontwikkeling (AppSec) was jarenlang een vak apart. Externe security consultants kwamen aan het einde van een project langs om via penetration testing de gaten in het systeem op te sporen. Vandaag de dag eisen moderne ‘shift-left’ DevSecOps culturen dat elke backend- én frontend-ontwikkelaar beschikt over een diepgaand begrip van de risico’s op het gebied van webbeveiliging. Bijna elke developer is inmiddels getraind om SQL-Injecties te voorkomen door Prepared Statements (via ORM’s) te gebruiken, en Cross-Site Scripting (XSS) in de browser af te stoppen dankzij moderne frameworks (React en Angular escapen HTML automatisch). Toch vormen deze oude gevaren slechts de oppervlakte van moderne attack-vectors volgens de OWASP Top 10.
Wanneer applicaties verschuiven van monolithische server-rendered pagina’s naar asynchrone SPA’s, headless architecturen, JWT-verificatie en third-party API-integraties, introduceren we nieuwe beveiligings-kwetsbaarheden (vulnerabilities) die veel dieper in de architectuur geworteld zijn. Hieronder bespreken we kritieke, moderne mechanismen die elke ontwikkelaar moet beheersen.
Het Content Security Policy (CSP) en Subresource Integrity (SRI)
Zelfs als uw eigen code 100% veilig is tegen XSS-aanvallen, loopt u een risico door uw afhankelijkheden. Bijna elke website laadt externe scripts in: Google Analytics, betalingsverwerkers (Stripe JS), of simpelweg icon-libraries en fonts (CDN’s). Wat gebeurt er als de servers van de aanbieder van de externe CDN worden gehackt en de legitieme JavaScript-bibliotheek wordt vervangen door een script dat stiekem creditcardgegevens steelt en doorstuurt naar het adres van de hacker?
Ontwikkelaars moeten zich hiertegen verdedigen via een Content-Security-Policy (CSP). Dit is een HTTP-header die de server meegeeft, waarmee de browser de strikte instructie krijgt: “Je mag op deze pagina uitsluitend scripts uitvoeren of afbeeldingen inladen die afkomstig zijn van ons-domein.com en analytics.google.com. Alle pogingen om scripts vanaf onbekende domeinen te laden, moeten direct worden geblokkeerd.” Daarnaast beschermt Subresource Integrity (SRI) u doordat de HTML-tag in uw applicatie een cryptografische hash (integrity="...") bevat van het verwachte scriptbestand. Mocht de inhoud van het externe bestand ook maar één letter worden gewijzigd, weigert de browser het uit te voeren.
De Valkuilen van JSON Web Tokens (JWT)
De transitie van traditionele sessie-cookies (beheerd door de server) naar stateless authentication in API’s heeft geleid tot de massale adoptie van JWT’s. Waar een sessie vereist dat de server in een database of geheugen controleert of de sessie-ID nog geldig is, is een JWT cryptografisch gesigneerd; de server hoeft enkel zijn ‘secret key’ te controleren om te weten wie de gebruiker is en welke rechten (roles) deze bezit.
Echter, de implementatie door ontwikkelaars bevat vaak pijnlijke hiaten. Waar moet de client (de browser) de JWT veilig opslaan? Vaak kiezen developers voor localStorage, omdat het makkelijk met JavaScript te benaderen is. Dit is echter catastrofaal bij een XSS-kwetsbaarheid, omdat elke schadelijk script op de pagina de JWT kan stelen. Best practice dicteert dat JWT’s opgeslagen dienen te worden in een zwaar beveiligde HttpOnly en Secure cookie, die onzichtbaar is voor JavaScript, met een strikte expiratie tijd (bijv. 15 minuten) om ’token hijacking’ onbruikbaar te maken.
Cross-Site Request Forgery (CSRF) in het API Tijdperk
Zodra authenticatie via beveiligde cookies verloopt, komt CSRF om de hoek kijken. CSRF is een aanval waarbij een kwaadaardige website (site-hacker.com) de browser van de gebruiker manipuleert om een (vaak verborgen of misleidend) ongewenst HTTP-verzoek uit te voeren naar een andere applicatie waar de gebruiker al is ingelogd (bijvoorbeeld een bank applicatie). Omdat de browser van de gebruiker (vanwege de sessie of de HttpOnly cookie) geauthenticeerd is op de bank-app, zal het de actie, bijvoorbeeld geld overmaken, zonder waarschuwing goedkeuren.
Om dit te mitigeren implementeren de ontwikkelaars moderne ‘SameSite’ attributen voor cookies (zoals SameSite=Lax of SameSite=Strict) en implementeren zij Anti-CSRF ‘Synchronizer Tokens’. Hierbij geeft de server bij het laden van het inlogvenster een unieke unieke verborgen token aan de client, welke door de frontend bij elke formulierinzending ter verificatie meegestuurd moet worden. Meer inzicht in robuuste dev-practices en beveiliging is beschikbaar via experts in DevSecOps op AG Connect.
Volgende: Microservices Architectuur: De Transitie van Monoliet naar Gedistribueerde Systemen
