mediacollegeamsterdam / veilig_programmeren

Coop code base en onderzoeken van leerlingen en docenten van het MediaCollege voor beveiliging.

veilig_programmeren

Coop code base en onderzoeken van leerlingen en docenten van het MediaCollege voor beveiliging.

Sanitising

http://snoh.hosts.ma-cloud.nl/vakken/vp/week2/sanitising/form.html

• LET OP met de .htaccess.. Ik mag dat niet in github zetten: owncloud/core#6188 Je kunt zelf de files renamen in php-logging en stats, om ook voorbeeld 3 te laten werken.

Logging

Geen online voorbeeld, zie directory logging voor drie voorbeelden of presentatie.

XSS

http://snoh.hosts.ma-cloud.nl/vakken/vp/week5/xss-attack-me.php

preventie en ernst

• https://excess-xss.com/
• https://www.owasp.org/index.php/DOM_Based_XSS
• https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#Embedded_tab
• https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
• https://gist.github.com/kurobeats/9a613c9ab68914312cbb415134795b45
• https://brutelogic.com.br/blog/xss-without-event-handlers/
• https://stackoverflow.com/questions/22395316/xss-without-html-tags
• https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001)#Example_1
• https://stackoverflow.com/questions/1873793/html-encode-in-php
• https://www.dionach.com/blog/the-real-impact-of-cross-site-scripting

Online pen-test tools (niet bijster betrouwbaar natuurlijk)

• https://pentest-tools.com/home
• https://www.tinfoilsecurity.com/free_scan/sites/http-www-snoep-at/scans/se1509413723207200006
• http://iseebug.com/XSSOnline/
• http://xss-scanner.com/

Free pen-test tools

• https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
• http://www-03.ibm.com/software/products/en/appscan (free trial)

veilig_programmeren's Issues

Password Sanitization

Is password sanitisation echt noodzakelijk? Slaan we ooit het password op?

Hebben we een dbc variabele?

$password = mysqli_real_escape_string($dbc,trim($_POST['password']));

Kunnen we mysqli_real_escape_string ook anders doen?

LETOP: http://dev.mysql.com/doc/refman/5.1/en/news-5-1-11.html

php_logging 4. is niet up to date

php_logging 4. is niet up to date

Search

Ik vind de database minder elegant hierbij, ik probeer het algemeen te houden.
Ik zou dat WEL doen, als hij in een query gebruikt wordt, natuurlijk maar meer als laatste stap.

Gaat het om sanitisation en dus whitelisting,
dan is de vraag feitelijk, welke characters zijn toegelaten in een search..

[A-Za-z0-9 .,] natuurlijk maar welke nog meer..?

+,-,: als je google functionaliteit biedt, maar dat lijkt me eigenlijk sterk voor de meeste toepassingen die jullie zullen maken in de komende tijd..
Men mag wel zoeken op Frànçöis of zoiets dus ook alles met de Unicode Designation Letter.
Die dingetjes aan de letters heetten diacritics en kun je zien als internationale variaties op letters. Dit is overigens alleen zo in Unicode.. Dus communiceer je wel in unicode? Of in UTF-8?
Communiceer je in unicode, dan kun je zoeke op diacritics met RegEx: ^[.\p{L}]*$, zie: https://stackoverflow.com/questions/8923729/checking-for-diacritics-with-a-regular-expression

In verband met zoeken zou je ook het volgende kunnen overwegen:
https://stackoverflow.com/questions/6837148/change-foreign-characters-to-normal-equivalent
En dan op de te doorzoeken tekst dezelfde bewerking doen. Dat zorgt voor meer matches..

Kortom:
Je kunt dus ALLES weghalen, wat geen reguliere letter is + . , - () en {} spatie ! ?
niet genoeg om mee te programmeren.. Wel genoeg om google achtig te zoeken.
Dat laatste is natuurlijk alleen interessant als je dat daadwerkelijk ondersteund.
Kortom, de huidige search query is wat breed en database is niet echt nodig.

Code is broken..

Tja, daar is dat blame knopje voor, maar kennelijk ben ik de eerste die het ontdekt..
Ik ben niet zo'n blamer, ik fix het wel.

Normale gang van zaken, als je ziet dat de update de code breekt is blamen op degene die het gepost heeft. Da's nu een hoop uitzoekerij, waar ik geen zin in heb.

Gender sanitisation niet specifiek genoeg

-ik mis de isset constructie, dit breekt potentieel de code.
sanitise string haalt het gevaar eruit, maar is geen goede whitelisting.
In feite kun je direct checken tegen drie waarden.

Sanitize range

$range = preg_replace('/[^0-9.]*/','',filter_var($_POST['range'], FILTER_SANITIZE_NUMBER_INT));

Heeft het zin de . toe te voegen als je eerst santized naar int ?
:)