Documentatie security-rapport

Er zijn heel veel mogelijke security vulnerabilities.

De beste bron ervoor (die ik heb gevonden) is OWASP .

Als je daar een beetje rondkijkt, zie je direct dat het onbegonnen werk is om alles in kaart te brengen. Daarom maak je een Threat-Assesment-Matrix (zie plaatje)

Van de gevonden vulnerabilities, waarvan je vermoedt dat het jou zo kunnen overkomen, check je waar ze zitten in de matrix. Soms is het heel moeilijk in te schatten of iets waarschijnlijk, dan wel onwaarschijnlijk is. Maar dan staat hij in ieder geval op de kaart.

Security is doorlopend werk. Er worden steeds nieuwe geintjes bedacht. Werk dus je Threat assesment regelmatig bij. (En je applicatie ook)

STRIDE geeft je een idee, waar je aangevallen kunt worden:

* ***S - poofing Identity***
* ***T - ampering with Data (die je naar de gebruiker zend. Je krijgt dan niet terug wat je verwacht of bijvoorbeeld niet de upload die je verwacht. )***
* ***R - epudiation (als je geen logs bijhoud, kan iemand gewoon zeggen: nee, hoor, dat is niet gebeurd)***
* ***I - nformation Disclosure (bijvoorbeeld wachtwoorden..)***
* ***D - enial of Service (zodat je site het niet meer doet, of een account gelocked wordt)***
* ***E - levation of Privilege (tot bijvoorbeeld Admin of Superuser)***

Het algemene idee achter dit voorkomen is voornamelijk de gebruiker zoveel mogelijk te beperken:

```
$id = preg_replace("/[^0-9]/",'',$_GET["id"]);

```

```
$id = filter_var(`$_GET["id"]`, FILTER_SANITIZE_NUMBER_INT);

```

Welke functie laat meer door? Kortom, welke tekens kunnen er in beide gevallen in $id terechtkomen? Wat beperkt de gebruiker dus meer in zijn poging ons systeem te hacken? Wat gebeurt er in het systeem als een gebruiker een negatieve id opgeeft? (Als de applicatie breekt, geen ik dan informatie weg? I-nformation Disclosure..)

Een klassiek voorbeeld van Information Disclosure is ook een foutmelding als: "Deze account bestaat niet". Heel handig, maar de juiste respons is: "De combinatie van account en wachtwoord komt niet voor". Anders geef je teveel informatie weg.

Elevation of Privilige/Spoofing Identity, is bijvoorbeeld als iemand WireShark gebruikt om een session-id te stelen en zo in te loggen als een gebruiker, of via handig spelen met de url opeens Admin pagina's ziet.

ALGEMEEN:

Geef de gebruiker zo min mogelijk controle, zo min mogelijk informatie die niet essentieel is en laat hem met afgepaste codes antwoorden. En log alles. (Dit maakt het heel lastig om een veilig CMS te maken, ik weet het...)

Al het andere is een potentieel risico. Hoe groot is dat risico? Dat is threat assesment.

Kijk in ieder geval naar:

* De top 10 van OWASP en dan vooral naar: Example Attack Scenarios van deze top 10, zou dat bij jou kunnen gebeuren?
* Cleanen van user-input (filter\_var of sterker: preg\_replace)
* AUTHENTICATION: Login. (Brute force..), forgot password etc...
* Uploads
* FRONT END: XSS-attacks. Hiermee kan user-informatie achterhaald worden, vrij makkelijk te voorkomen met het cleanen van user-input en als dat ECHT niet kan, met dingen als html-entities.
* Het verschil tussen blacklisten en whitelisten (whitelisten is altijd veiliger, blacklisten is handiger, maar niet alleen voor jou, ook voor hackers!).
* Hashen van passwords (wettelijk verplicht, hoge boetes!)
* Sha1 deprecication (ga naar sha384 op zijn minst)