[php]Hoe te beveiligen tegen XSS? *

[Meijuh]

De volgende vraag heb ik over acunetix. Deze heb ik laten scannen op XSS, hierbij gaf hij de melding dat $_GET variabelen mogelijk gebruikt kunnen worden voor XSS, is mysql_real_escape_string() niet genoeg om XSS te voorkomen?

Ik gebruik dus mysql_real_escape_string() alleen zegt acunetix dus dat het niet veilig genoeg is. Het advies dat het geeft: "you should filter metacharacters". Als ik dus in google zoek naar "filter metacharacters" dan zeggen de resultaten dat mysql_real_escape_string() goed genoeg moet zijn. Moet ik beter filteren, of heeft acunetix het niet bij het rechte eind?

Groeten,
Jeroen Meijer

[ Voor 27% gewijzigd door Meijuh op 14-08-2009 13:35 . Reden: 1 oplossing al gevonden ]

[RedHat]

Ik gebruik zelf altijd mysql_real_escape_string en filter op verwachte input (Dus kijk of iets echt numeriek is met is_num b.v. En anders gebruik ik regex om te kijken of hij voldoet aan mijn verwachtingen).

[Verwijderd]

Bij XSS gaat het om het filteren van de output, dat doe je niet met mysql_real_escape_string, maar met htmlentities(). Verder weet ik even niet wat dit met recursie te maken heeft?

offtopic:
Het algemeen beleid #groeten

[ Voor 15% gewijzigd door Verwijderd op 14-08-2009 15:07 ]

[Woy]

Idd wat GuidoH zegt. mysql_real_escape_string is niet bedoeld om XSS tegen te gaan, maar bedoeld om strings te escapen voor het gebruik in mysql queries.

XSS kan ontstaan doordat iemand HTML/Javascript in je output kan injecteren. Alle input van je gebruiker die je later weer output, zul je dus moeten filteren/escapen op het moment van het outputten. Dit kan ondermeer door htmlentities te gebruiken.

[Erkens]

Woy schreef op vrijdag 14 augustus 2009 @ 15:21:
Alle input van je gebruiker die je later weer output, zul je dus moeten filteren/escapen op het moment van het outputten. Dit kan ondermeer door htmlentities te gebruiken.

Een kleine, maar belangrijke aanpassing op jouw tekst Want het maakt niet uit waar die input vandaan komt, of dit nu een tekst file is die op de server staat, uit de database komt, of inderdaad bij de gebruiker vandaan komt maakt daarbij niet uit.

Never trust any input!

[Woy]

Erkens schreef op vrijdag 14 augustus 2009 @ 15:26:
[...]

Een kleine, maar belangrijke aanpassing op jouw tekst Want het maakt niet uit waar die input vandaan komt, of dit nu een tekst file is die op de server staat, uit de database komt, of inderdaad bij de gebruiker vandaan komt maakt daarbij niet uit.

Never trust any input!

Op zich heb je een punt, maar bij mijn eigen input is het soms wel de bedoeling om HTML/Javascript te ouputten, dan is het immers ook niet echt XSS

offtopic:
Ik heb je titel even iets aangepast, je vraag over recursie had je al weg-geedit, en het is ook niet specifiek voor acunetix

[ Voor 11% gewijzigd door Woy op 14-08-2009 15:50 ]

[Erkens]

Woy schreef op vrijdag 14 augustus 2009 @ 15:31:
[...]

Op zich heb je een punt, maar bij mijn eigen input is het soms wel de bedoeling om HTML/Javascript te ouputten, dan is het immers ook niet echt XSS

Nee uiteraard, maar dan heb je toch op de een of andere manier die input gechecked

[cariolive23]

XSS heeft niets met databases te maken, een database-functie (mysql_real_escape_string() in dit geval) kan dan ook onmogelijk dit probleem oplossen.

Uiteraard kan XSS wel worden veroorzaakt door content die toevallig uit een database komt, maar deze content kan net zo goed ergens anders vandaan komen.

[Verwijderd]

Woy schreef op vrijdag 14 augustus 2009 @ 15:31:
[...]

Op zich heb je een punt, maar bij mijn eigen input is het soms wel de bedoeling om HTML/Javascript te ouputten, dan is het immers ook niet echt XSS

offtopic:
Ik heb je titel even iets aangepast, je vraag over recursie had je al weg-geedit, en het is ook niet specifiek voor acunetix

Toch wel, want hoe weet je wat de uitwerking van die HTML/JS is in de browser van de gebruiker? Voor opmaak kan je daarom beter UBBC gebruiken, dan kan je zelf een set met randvoorwaarden opstellen.
Als die javascriptcode nou bijvoorbeeld de sessioncookie als parameter gebruikt bij het opvragen van een andere website, dan kan die andere website die cookie forgen en zo inbreken in jouw pagina.
Wat ik zelf doe is bij het in SQL voegen een escape functie gebruiken (bijv. mysql_real_escape), en bij het uitvoeren naar HTML htmlentities er overheen halen. Zo staat in de database (zonder injectiekans) de waarde zoals door de gebruiker ingevoerd, en komt op het scherm de tekst zoals door de gebruiker ingevoerd (plain text dus, niet met html, want je wilt zelf de controle houden over welke html je weergeeft!)

@cariolive23:
Klopt, het veroorzaakt geen XSS, zolang de code die uit de database komt door htmlentities gehaald wordt. Je kan immers niets meer aannemen over de inhoud van je database (laat staan tabellen), aangezien die best wel eens veranderd kunnen zijn door een injectie (DROP TABLE / SELECT password FROM users / UPDATE user SET permission='admin' WHERE username='hacker'), injecties zijn dus geen XSS, maar kunnen wel direct een XSS tot gevolg hebben.

[ Voor 16% gewijzigd door Verwijderd op 14-08-2009 16:05 ]

[cariolive23]

@RoadRunner84: Wanneer je niet in staat bent om SQL injection tegen te gaan, hoor je ook niet met databases te werken. Hallo! Het is inmiddels 2009 geworden, SQL injection is toch echt iets van de vorige eeuw. Wanneer je zelfs DROP-rechten geeft aan jouw gebruikers, waar hebben we het dan nog over? Of een databaserol die zomaar admin-rechten binnen de applicatie kan toekennen? Hier kies je voor problemen, je WILT blijkbaar problemen krijgen. Die krijg je dan ook, mag je dan blij om zijn.

Sorry dat het wat bot is, maar we hebben het hier wel over basis basis basis kennis van het gebruik van databases. Dat de gemiddelde PHPprutser niet met databases kan werken, tja, zoek dan een andere hobby.

Output moet je door htmlentities halen, maakt dus niet uit of dat nu toevallig content is die uit een database komt.

[Verwijderd]

Verwijderd schreef op vrijdag 14 augustus 2009 @ 16:02:
[...]

Toch wel, want hoe weet je wat de uitwerking van die HTML/JS is in de browser van de gebruiker? Voor opmaak kan je daarom beter UBBC gebruiken, dan kan je zelf een set met randvoorwaarden opstellen.
Als die javascriptcode nou bijvoorbeeld de sessioncookie als parameter gebruikt bij het opvragen van een andere website, dan kan die andere website die cookie forgen en zo inbreken in jouw pagina.
Wat ik zelf doe is bij het in SQL voegen een escape functie gebruiken (bijv. mysql_real_escape), en bij het uitvoeren naar HTML htmlentities er overheen halen. Zo staat in de database (zonder injectiekans) de waarde zoals door de gebruiker ingevoerd, en komt op het scherm de tekst zoals door de gebruiker ingevoerd (plain text dus, niet met html, want je wilt zelf de controle houden over welke html je weergeeft!)

@cariolive23:
Klopt, het veroorzaakt geen XSS, zolang de code die uit de database komt door htmlentities gehaald wordt. Je kan immers niets meer aannemen over de inhoud van je database (laat staan tabellen), aangezien die best wel eens veranderd kunnen zijn door een injectie (DROP TABLE / SELECT password FROM users / UPDATE user SET permission='admin' WHERE username='hacker'), injecties zijn dus geen XSS, maar kunnen wel direct een XSS tot gevolg hebben.

Eigen input wél filteren omdat je niet weet wat de uitwerking is in de browser? Ik weet niet hoor, maar als je het voor elkaar krijgt om perongeluk een sessioncookie naar een andere server te sturen, dan ben je niet goed bezig. En daarbij is het wel handig om ook server-side het een en ander tegen session-hijacking te doen, dus dan heeft diegene alsnog niks aan de cookie.

Verder vind ik dat je wel dingen kan aannemen over de inhoud van de database, tenzij je site vol met SQL injecties zit, maar dan is de daar (eventueel) op volgende XSS niet het probleem, maar slechts het gevolg van de brakke beveiliging.

[Verwijderd]

cariolive23 schreef op vrijdag 14 augustus 2009 @ 16:14:
@RoadRunner84: Wanneer je niet in staat bent om SQL injection tegen te gaan, hoor je ook niet met databases te werken. Hallo! Het is inmiddels 2009 geworden, SQL injection is toch echt iets van de vorige eeuw. Wanneer je zelfs DROP-rechten geeft aan jouw gebruikers, waar hebben we het dan nog over? Of een databaserol die zomaar admin-rechten binnen de applicatie kan toekennen? Hier kies je voor problemen, je WILT blijkbaar problemen krijgen. Die krijg je dan ook, mag je dan blij om zijn.

Sorry dat het wat bot is, maar we hebben het hier wel over basis basis basis kennis van het gebruik van databases. Dat de gemiddelde PHPprutser niet met databases kan werken, tja, zoek dan een andere hobby.

Output moet je door htmlentities halen, maakt dus niet uit of dat nu toevallig content is die uit een database komt.

Dan zijn we het eens: filter altijd vóór een SQL query tegen injecties en altijd vóór HTML output op htmlentities.

Een usersysteem in een webapplicatie kan alleen maar via databases bepalen wie er wel of niet admin is (of het moet hardcoded, maar dat is nog smeriger vind ik), dus ik zie niet hoe je dit kan voorkomen. Feitelijk komt het er toch op neer dat het aan de designer is om door filtering te voorkomen dat userinput hier bij kan komen.

@GuidoH:
Ja.... de XSS is het gevolg van de injectie, en je hebt niet goed tegen injecties beveiligd.... klopt. Maar als ik tevens beveilig tegen XSS bij de output naar de HTML heb ik een dubbele beveiliging, mocht er dan toch nog een injectie plaatsvinden, dan heeft dat niet desastreuze gevolgen.
Als ik bij een stad een slotgracht aanleg en iemand slaagt erin om een brug er overheen te leggen, dan zeg je toch ook niet dat je de slotgracht breder/dieper moet maken? Dan zeg je dat je na de slotgracht ook een vestingmuur moet bouwen.

[ Voor 16% gewijzigd door Verwijderd op 14-08-2009 16:23 ]

[cariolive23]

Een usersysteem in een webapplicatie kan alleen maar via databases bepalen wie er wel of niet admin is (of het moet hardcoded, maar dat is nog smeriger vind ik), dus ik zie niet hoe je dit kan voorkomen.

Je werkt webbased, je werkt met userinput die 100% onbetrouwbaar is, je weet dat er hackers op jouw systeem zitten, en dus zorg je er voor het niet mogelijk is om via de applicatie admin te worden. De databaserol die wordt gebruikt vanuit jouw applicatie om een connectie met de database te leggen, mag dus géén rechten hebben op de tabel waarin de admin's van jouw systeem staan. Deze tabel is uitsluitend rechtstreeks te benaderen op de database met een aparte databaserol, de beheerder van de database.

Dit zijn uitermate eenvoudige maatregelen tegen hacks, maar vele scriptkiddies laten hun applicaties werken met een databaserol die véél te veel rechten heeft op de database. Ieder klein lekje heeft dan direct catastofale gevolgen voor de database. Geen idee waarom men zo graag van dit soort problemen wil hebben, maar hier kiest men wel voor.

Minder rechten = veiliger. Je geeft alleen die rechten die onmisbaar zijn (!!!) voor de absoluut noodzakelijke (!!!) werkzaamheden. Is het niet onmisbaar of niet absoluut noodzakelijk, geef je ook geen rechten uit. En werken met maximale rechten, hoe stom kun je zijn?

Kleine aanvulling: In dit geval zijn dus uitsluitend SELECT-rechten noodzakelijk op de tabel met admin-users. Alle andere mogelijke rechten zijn verboden, kunnen alleen maar voor problemen zorgen.

[ Voor 6% gewijzigd door cariolive23 op 14-08-2009 16:33 ]

[Woy]

Verwijderd schreef op vrijdag 14 augustus 2009 @ 16:17:
[...]
Verder vind ik dat je wel dingen kan aannemen over de inhoud van de database, tenzij je site vol met SQL injecties zit, maar dan is de daar (eventueel) op volgende XSS niet het probleem, maar slechts het gevolg van de brakke beveiliging.

Je kunt wel aannames over je database doen, echter is het onzin om content die naar de database gaat, al van te voren te escapen voor XSS. Misschien wil je de content straks wel gebruiken om een PDF te genereren.

Je moet pas escapen voor XSS op het moment dat je content naar een browser output.

[Verwijderd]

Je kan http://htmlpurifier.org/ gebruiken. Je kan tijdelijk mod_security gebruiken op je apache server.

@cariolive23: Alle userinput is onbetrouwbaar Verder ben ik het met je eens.

Edit: zorg ervoor dat je cookies alleen op de hostname (https?, http-only?) beschikbaar zijn wanneer je ze nodig hebt op die hostname (ivm session hijacking).

[ Voor 30% gewijzigd door Verwijderd op 14-08-2009 16:37 ]

[Verwijderd]

Verwijderd schreef op vrijdag 14 augustus 2009 @ 16:20:
[...]

Dan zijn we het eens: filter altijd vóór een SQL query tegen injecties en altijd vóór HTML output op htmlentities.

Een usersysteem in een webapplicatie kan alleen maar via databases bepalen wie er wel of niet admin is (of het moet hardcoded, maar dat is nog smeriger vind ik), dus ik zie niet hoe je dit kan voorkomen. Feitelijk komt het er toch op neer dat het aan de designer is om door filtering te voorkomen dat userinput hier bij kan komen.

@GuidoH:
Ja.... de XSS is het gevolg van de injectie, en je hebt niet goed tegen injecties beveiligd.... klopt. Maar als ik tevens beveilig tegen XSS bij de output naar de HTML heb ik een dubbele beveiliging, mocht er dan toch nog een injectie plaatsvinden, dan heeft dat niet desastreuze gevolgen.
Als ik bij een stad een slotgracht aanleg en iemand slaagt erin om een brug er overheen te leggen, dan zeg je toch ook niet dat je de slotgracht breder/dieper moet maken? Dan zeg je dat je na de slotgracht ook een vestingmuur moet bouwen.

Als je twijfels hebt of je site veilig is tegen SQL injectie, zou ik de queries nog een keer nalopen. Dan ben je er zeker van dat er niemand "over de slotgracht komt". En waarom zou iemand die in je database kan XSS gebruiken om het verder te exploiten? Ik zou mezelf gewoon even de gewenste rechten geven / wachtwoord van de gewenste gebruiker aanpassen.

Output dat door de gebruikers ingevoerd is ben ik het mee eens; altijd door de htmlentities heen. Output van de admin er doorheen halen en dan zitten te kloten met UBB? Dat nooit. Als je je site beveiligd hebt tegen SQL injecties, kan dat gewoon niet nodig zijn. Als ze er dan toch in komen, dan ben je hoe dan ook fucked.

En als je je site niet goed kan beveiligen tegen SQL injecties, dan moet je dat maar leren..

@Woy: 100% mee eens! Dat zie je me ook nergens zeggen.

[Woy]

Verwijderd schreef op vrijdag 14 augustus 2009 @ 16:37:
[...]
Als je twijfels hebt of je site veilig is tegen SQL injectie, zou ik de queries nog een keer nalopen. Dan ben je er zeker van dat er niemand "over de slotgracht komt". En waarom zou iemand die in je database kan XSS gebruiken om het verder te exploiten? Ik zou mezelf gewoon even de gewenste rechten geven / wachtwoord van de gewenste gebruiker aanpassen.

Output dat door de gebruikers ingevoerd is ben ik het mee eens; altijd door de htmlentities heen. Output van de admin er doorheen halen en dan zitten te kloten met UBB? Dat nooit. Als je je site beveiligd hebt tegen SQL injecties, kan dat gewoon niet nodig zijn. Als ze er dan toch in komen, dan ben je hoe dan ook fucked.

En als je je site niet goed kan beveiligen tegen SQL injecties, dan moet je dat maar leren..

Maar dat maakt de bewering van cariolive23 niet minder waar. Het is een kleine moeite om je database user gewoon de minimaal benodigde rechtenset te geven. Mocht er dan toch een fout insluipen, dan heb je de schade ieder geval al een beetje beperkt.

[Verwijderd]

Woy schreef op vrijdag 14 augustus 2009 @ 16:41:
[...]

Maar dat maakt de bewering van cariolive23 niet minder waar. Het is een kleine moeite om je database user gewoon de minimaal benodigde rechtenset te geven. Mocht er dan toch een fout insluipen, dan heb je de schade ieder geval al een beetje beperkt.

Ook totaal mee eens. Had die reactie nog niet gelezen voordat ik postte.

[cariolive23]

En als je je site niet goed kan beveiligen tegen SQL injecties, dan moet je dat maar leren..

Prepared statements zijn een heel goed begin. Wanneer je MySQL gebruikt, kun je daarvoor de mysqli (i = improved) functies van PHP gebruiken of PDO.

Voor PostgreSQL kun je gewoon met pg_query_params() aan de slag, is nog eenvoudiger.

Zie ook http://wiki.phpfreakz.nl/PreparedStatements