Security Les 1: Begrippen + XSS

• Applicatie- en mediaontwikkelaar
• MBO
• Studiejaar 3

Security

Python intro

Programming basics-II

Les 3 / Week 7a

Security: XSS, CSRF, SQL Injectie

Delta

Les 1 / 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 jouw code een doelwit is

Elke applicatie die jij bouwt, is een potentieel doelwit.
Niet per se van criminelen in hoodies, maar van geautomatiseerde scripts die 24/7 zoeken naar zwakke plekken

Wat bescherm je eigenlijk?

🔒 Vertrouwelijkheid: Alleen bevoegde personen mogen gegevens zien

✏️ Integriteit: Gegevens mogen niet ongewenst worden aangepast

✅ Beschikbaarheid: De applicatie moet bruikbaar blijven

Wat bescherm je eigenlijk?

Voorbeeld: Je bouwt een webshop:

• Klantgegevens blijven privé
• Bestellingen kunnen niet door anderen worden aangepast
• De site blijft bereikbaar, ook onder hoge belasting

🔒 Vertrouwelijkheid: Alleen bevoegde personen mogen gegevens zien
✏️ Integriteit: Gegevens mogen niet ongewenst worden aangepast
✅ Beschikbaarheid: De applicatie moet bruikbaar blijven

Begrippenkader

De taal van security

Basisprincipes

1. Defense in depth

Vertrouw nooit op één maatregel. Meerdere lagen = minder schade als één laag faalt.

2. Least privilege
Geef onderdelen alleen de rechten die ze écht nodig hebben.

→ De databasegebruiker van je webapp heeft geen DROP TABLE-rechten nodig.

3. Fail secure
Als er iets misgaat, zorg dat het veilig misgaat.
→ Toon "gebruikersnaam of wachtwoord onjuist" — niet welke van de twee fout is.
→ Geen stacktraces tonen aan gebruikers.

Een developer toont bij een inlogfout de melding: "Gebruiker bestaat niet in de database." Welk principe wordt hier geschonden?

1. Least privilege
2. Defense in depth
3. Fail secure
4. Beschikbaarheid

OWASP Top 10

OWASP (Open Web Application Security Project) publiceert de meest voorkomende en gevaarlijke kwetsbaarheden voor webapplicaties.

https://owasp.org/Top10/2025/

OWASP Top 10

In deze module behandelen drie onderdelen die terugkomen in de OWASP Top 10:

🔴 XSS (Cross-Site Scripting)
🔴 CSRF (Cross-Site Request Forgery)
🔴 SQL Injection

Zie moduleboek

Lees de theorie na en maak opdracht 5.5 voor jezelf

XSS

Alles is input en input is onbetrouwbaar

"Never trust the client"

Waar komt input vandaan?

• Formulieren (POST/GET)
• URL-parameters
• Cookies
• HTTP-headers (User-Agent, Referer)
• Geüploade bestanden
• Externe APIs
• De eigen database (als die ooit onveilig gevuld is)

💡 Alles wat van buiten jouw eigen proces komt, is in principe onbetrouwbaar.

Wat is Cross-Site Scripting (XSS)?

Een aanvaller slaagt erin om eigen JavaScript te laten draaien in de browser van een andere gebruiker, binnen jouw website.

Wat kan een aanvaller dan?

• Sessiecookies stelen
• Formulieren automatisch versturen
• Nep-inlogschermen tonen (phishing)
• Pagina-inhoud aanpassen (defacing)

Drie varianten van XSS

1. Reflected XSS
Input zit in de request (bijv. query string) en wordt direct teruggegeven in de response.
→ Zoekresultatenpagina die de zoekterm ongefilterd toont.
2. Stored XSS
Kwaadaardige input wordt opgeslagen (in de database) en later aan andere gebruikers getoond.
→ Een reactie op een blogpost met <script> erin.
3. DOM-based XSS
De kwetsbaarheid zit in JavaScript in de browser zelf, dat onveilige waarden uit de DOM of URL injecteert in de pagina. Gebeurt volledig aan de front-end kant.

Drie varianten van XSS

1. Reflected XSS
Input zit in de request (bijv. query string) en wordt direct teruggegeven in de response.
→ Zoekresultatenpagina die de zoekterm ongefilterd toont.
2. Stored XSS
Kwaadaardige input wordt opgeslagen (in de database) en later aan andere gebruikers getoond.
→ Een reactie op een blogpost met <script> erin.
3. DOM-based XSS
De kwetsbaarheid zit in JavaScript in de browser zelf, dat onveilige waarden uit de DOM of URL injecteert in de pagina. Gebeurt volledig aan de front-end kant.

Drie varianten van XSS

1. Reflected XSS
Input zit in de request (bijv. query string) en wordt direct teruggegeven in de response.
→ Zoekresultatenpagina die de zoekterm ongefilterd toont.
2. Stored XSS
Kwaadaardige input wordt opgeslagen (in de database) en later aan andere gebruikers getoond.
→ Een reactie op een blogpost met <script> erin.
3. DOM-based XSS
De kwetsbaarheid zit in JavaScript in de browser zelf, dat onveilige waarden uit de DOM of URL injecteert in de pagina. Gebeurt volledig aan de front-end kant.

Een webshop slaat productenreviews op in de database en toont die aan alle bezoekers. Een aanvaller plaatst een review met daarin:


Welk type XSS is dit (Reflected, Stored of DOM-based), en wat is het gevolg?

Inputvalidatie vs. Output Encoding

Twee verdedigingslinies, beide nodig

Inputvalidatie

Controleer of input voldoet aan wat je verwacht.

Strategie: allowlisting/whitelisting (wat mag?) is veiliger dan blocklisting/blacklisting (wat mag niet?).

• Leeftijd: getal tussen 0 en 120
• Gebruikersnaam: alleen letters, cijfers, _, max. 20 tekens
• E-mail: geldig formaat

Output encoding (escaping)

Maak data veilig op het moment dat je die in een context plaatst.

https://emn178.github.io/online-tools/html_encode.html

Zie moduleboek

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