Security Les 2: CSRF

• Applicatie- en mediaontwikkelaar
• MBO
• Studiejaar 3

Wat hebben we vorige les besproken?

Python intro

Programming basics-II

Les 3 / Week 7a

Security: XSS, CSRF, SQL Injectie

Delta

Les 2 / 3 over Security

🪧Deze lessen

Les 1: 

• Inleiding
• XSS

Ondanks dat we veel op WEB security focussen, zijn de concepten ook voor NATIVE relevant.

Les 2:

• CSRF
  

Les 3

• SQL Injectie

Waarom moet je cookies in jouw browser nooit delen of verliezen aan hackers?

Waar staat de X voor in XSS?

1. XML
2. XAML
3. Cross
4. Cheat

Hoe voorkomen dat hackers XSS uitvoeren op onze website?

Output Encoding / Escaping

Zie moduleboek

Lees de theorie na en maak opdracht 6.6 t/m 6.10 voor jezelf

Dit was de opdracht vorige week. Al klaar?

State & Sessies

HTTP is stateless... Hoe onthouden we dan wie ingelogd is?

State & Sessies

HTTP heeft geen geheugen. Elke request staat op zichzelf.

Toch willen we bijhouden:

• Wie is ingelogd?
• Wat zit er in het winkelmandje?
• Welke rol heeft de gebruiker?

1. Gebruiker logt in
2. Server maakt sessie aan met uniek ID (bijv. iqh4wj6jha2wSwsr8)
3. Dat ID wordt in een cookie naar de browser gestuurd
4. Bij elke volgende request stuurt de browser de cookie automatisch mee
5. Server kijkt: welke sessie hoort bij dit ID?
6. Stuurt een pagina terug voor de gebruiker met die sessie ID

State & Sessies

State & Sessies

Omdat onze session id bewijst wie we zijn, moeten we die beschermen. Met XSS zou die session id cookie gestolen kunnen worden.

Maar ook CSRF is een aanval om rekening mee te houden

Wat is CSRF?

Cross-Site Request Forgery

Een aanvaller laat een ingelogde gebruiker onbewust een actie uitvoeren op een website waar die gebruiker al is ingelogd.

Voorbeeld CSRF

1. Jij bent ingelogd op https://mijnbank.nl (tabblad A)
2. Je bezoekt https://slechte-site.com (tabblad B)
3. Die site bevat een verborgen formulier dat automatisch verstuurt:
   
   
   
   
   
   
4. De browser stuurt jouw sessiecookie van de bank automatisch mee
5. De bank denkt: dit is een geldige, ingelogde gebruiker → actie uitgevoerd

CSRF

Kernmechanisme:

De browser stuurt automatisch cookies mee — ook als het verzoek van een andere website komt.

CSRF ↔️ Sessies

Browsers sturen automatisch alle cookies mee die horen bij het domein waarnaar het verzoek gaat, ongeacht van welke site het verzoek afkomstig is. 

Dus als jij naar https://google.com navigeert, zoekt jouw browser de google.com cookies erbij en stuurt die mee met jouw verzoek.

Een kwaadaardige site stuurt een verzoek naar de bank, en de browser voegt de bankcookie automatisch toe. Dus het verzoek lijkt van de ingelogde gebruiker te komen

Wanneer is CSRF mogelijk?

De vier voorwaarden voor een succesvolle CSRF-aanval:

1. De gebruiker is ingelogd op de doelsite
2. De browser stuurt sessiecookies automatisch mee (is altijd waar)
3. Er bestaat een gevoelige actie (POST naar /change-email, /delete-account)
4. Die actie is niet extra beveiligd (geen 'csrf-token', geen bevestiging)

Is deze actie kwetsbaar voor CSRF als er geen bescherming is? (De gebruiker is ingelogd)
Sleep naar Ja of Nee.

Ja

Nee

GET /profiel tonen

POST /change-email

POST /geld-overmaken

POST /make-admin

GET /zoeken?q=laptop

POST /wachtwoord-wijzigen

POST /delete-account

GET /admin list tonen

Verdediging: CSRF-tokens

In plaats van forms zomaar te accepteren als legitiem, willen we ze op een of andere manier markeren met iets wat alleen de échte website weet. Zodat hackers geen forms kunnen namaken.

Verdediging: CSRF-tokens

Hoe werkt het?

1. Server genereert een willekeurig, geheim token en slaat dat op in de sessie
2. Token wordt als verborgen veld meegestuurd in elk formulier:
   
   
   
   
3. Bij verwerking van het formulier controleert de server:
   
   
   
4. Klopt het niet → request geweigerd (419 Page Expired)

• Zit er een csrf_token in de request?
• Komt die overeen met het token in de sessie?

Hoe voeg je in Laravel een CSRF-token toe aan een formulier?

Verdediging: CSRF-tokens

https://laravel.com/docs/12.x/csrf

Zie moduleboek

Lees de theorie (7.5 bevat aanvullende theorie)

Maak opdracht 7.6 t/m 7.10 voor jezelf

SQL Injection

SQL Injection is een kwetsbaarheid waarbij een aanvaller eigen SQL-code laat uitvoeren binnen een databasequery van jouw applicatie.

SQL Injection

Dit ontstaat wanneer:

• Gebruikersinput direct "geplakt" wordt in een SQL-query
• Er geen scheiding is tussen SQL-code en data

→ Dit geeft alle gebruikers terug. De aanvaller is ingelogd.

SQL Injection

Stel dat de delete functie werkt via delete.php?id=1

Bedenk een kwaadaardige invoer voor het volgende formulierveld dat alle orders uit de tabel verwijdert:

delete.php?id=

SQL Injection

delete.php?id=1 OR 1=1

→ resulteert in DELETE FROM orders WHERE id = 1 OR 1=1
Dit verwijdert alle orders omdat 1=1 altijd waar is.

SQL Injection

delete.php?id=1; DROP TABLE orders

Deze alternatieve aanval zou ook kunnen werken, maar dan moeten meerdere verschillende queries (DELETE + DROP) in één opdracht worden toegestaan door zowel PHP als MySQL (wat tegenwoordig niet standaard ingesteld staat)

Verdediging: Prepared Statements

De oplossing tegen SQL Injection: prepared statements

Verdediging: Prepared Statements

Het idee:

• SQL-structuur wordt vooraf naar de database gestuurd
• Data (parameters) worden apart meegegeven
• De database behandelt parameters altijd als data, nooit als SQL-code

Veilig voorbeeld (PHP met PDO):

Verdediging: Prepared Statements

Zelfs als $username de waarde ' OR '1' = '1 bevat, blijft de query veilig. De invoer wordt nooit als SQL geïnterpreteerd.

ORMs helpen, maar omzeil ze niet!

Frameworks zoals Laravel (Eloquent), Doctrine en Hibernate gebruiken intern prepared statements.

Veilig (je gebruikt Eloquent ORM):

Gevaarlijk (raw query zonder binding):

Wachtwoorden & gevoelige data

Data = gegevens

Wachtwoorden opslaan

Wachtwoorden & gevoelige data

In .NET (C#): https://github.com/BcryptNet/bcrypt.net

Gevoelige data

• Sla alleen op wat écht nodig is
• Sla alleen op wat je mag opslaan (BSN mag niet zomaar [link])
• Overweeg versleuteling voor gevoelige gegevens (BSN, betaalgegevens)
• Beperk wie er bij kan (least privilege)

⚠️ True story: Er zijn bedrijven waarvan logs gehackt zijn. Wachtwoorden stonden er in plain text in omdat een developer var_dump($user) had laten staan.

Een collega zegt: "Ik doe inputvalidatie op het wachtwoordveld, dan heb ik geen prepared statement nodig." Wat antwoord je?

1. Hij heeft gelijk, inputvalidatie is voldoende
2. Hij heeft ongelijk, inputvalidatie vervangt prepared statements niet
3. Hij heeft gelijk als hij ook output encoding toepast
4. Hij heeft gelijk als de database MySQL is

Zie moduleboek

Lees de theorie (8.6 + 8.8 bevatten aanvullende theorie)

Maak opdracht 8.10 t/m 8.13 voor jezelf

Alles samen: 'defense in depth' in de praktijk

Gebruikersinvoer komt binnen

[ Inputvalidatie ]
Klopt het formaat? Is het verwacht?

[ Prepared statement ]

Query structuur gescheiden van data

[ Least privilege DB-gebruiker ] 
Beperkte rechten bij schade

[ Output encoding ]
Veilig tonen in de browser

[ Fail secure foutmeldingen ]
Geen technische details naar buiten

[ Logging ] 
Detecteren van verdacht gedrag

Afsluiting Security Lessen

Les 1:

• Fundament: begrippenkader, basisprincipes
• XSS: hoe het werkt, drie varianten
• Inputvalidatie vs. output encoding

Les 2:

• State, sessies en cookies
• CSRF: hoe het werkt, verdediging met tokens en SameSite
• Sessiebeveiliging: HttpOnly, Secure, time-outs
• SQL Injection: hoe het ontstaat, prepared statements, least privilege

Welke combinatie van maatregelen beschermt het beste tegen zowel XSS als SQL Injection?

1. Inputvalidatie alleen
2. Output encoding en een sterk wachtwoord
3. HTTPS en CSRF-tokens
4. Inputvalidatie + output encoding + prepared statements

Security is geen afvinklijstje, het is een houding

Het landschap verandert voortdurend. Nieuwe frameworks, nieuwe aanvalstechnieken, nieuwe kwetsbaarheden. Wat vandaag veilig is, kan morgen een bekend lek zijn.

Security is geen afvinklijstje, het is een houding

Hoe blijf je actueel?

📰 Volg de OWASP-website: owasp.org publiceert continu guides, checklists en updates over nieuwe risico's
📬 Abonneer je op een security-nieuwsbrief: bijv. tldrsec.com, kort, wekelijks, praktisch
🐛 Volg CVE-meldingen: cve.org registreert bekende kwetsbaarheden in software die jij misschien gebruikt

🔔 Houd je dependencies bij: tools zoals npm audit of composer audit waarschuwen je als een pakket dat jij gebruikt een bekend lek heeft

🎯 Doe mee aan CTF-uitdagingen: Capture The Flag-competities (bijv. via picoctf.org of hackthebox.com) leren je aanvallen begrijpen door ze zelf uit te voeren in een veilige omgeving
💬 Praat erover met collega's en medestudenten: security-awareness groeit het snelst in een team dat het normaal vindt om elkaar te wijzen op risico's