Security Les 3: SQL Injectie + Afronding

• 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 3 / 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

SQL Injection

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

Injectie is breder dan SQL

Injectie-aanvallen zijn niet uniek aan SQL. Elke plek waar gebruikersinput in een commando of query terechtkomt zonder validatie is een risico.

Injectie is breder dan SQL

Andere kwetsbare voorbeelden: Command Injection

Attacker roept aan: ?host=google.com; cat /etc/passwd → Na de ping wordt een tweede commando uitgevoerd. Het /etc/passwd bestand op Linux bevat wachtwoorden!

Injectie is breder dan SQL

Andere kwetsbare voorbeelden: Path Traversal

Attacker roept aan: ?file=../../etc/passwd

$file wordt 'passwd'

Injectie is breder dan SQL

Bedenk: 

1. Verwerk ik input van de gebruiker?
2. Wat gebeurt er met die input? 
3. Hoe kan de gebruiker invloed uitoefenen?
4. Hoe maak ik de invoer onschadelijk? Wat kan ik allemaal uit de invoer 'escapen' / weghalen? Bestaan daarvoor functies/best-practices?

Zoek altijd online naar actueel en betrouwbaar advies! Vraag ook na bij, en leer van, Senior Developers op je werk.

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