[HTML + SQL] Input field naar DB beveiligen

[Damian]

Hallo daar.

Ik ben glad vergeten hoe ik het inputfield van een formulier beveilig tegen shit zoals <img src="blabl"> enz..

Als ik nu dus html of java derin plak, dan parsed ie dat verhaal, terwijl hij het eigenlijk moet weergeven of er niets mee moet doen

tia!

[MueR]

Het lijkt mij dat zoeken naar form validation erg veel informatie oplevert die je zoekt.

[hamsteg]

htmlentities (en misschien addslashes)

[JHS]

Voor het weergeven kan je inderdaad htmlentities gebruiken, maar ik denk dat je eerder naar iets op zoek bent in de trand van http://nl2.php.net/manual...ql-real-escape-string.php . Wat overigens hier ruim te vinden is. Betergezegd: het staat in de FAQ: Programming FAQ - Hoe beveilig ik een website? Van een ander subforum, dat wel .

[hamsteg]

quote: http://nl2.php.net/manual...ql-real-escape-string.php

mysql_real_escape_string() calls MySQL's library function mysql_real_escape_string, which prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a.

Bij opbouwen is het dus nogsteeds mogelijk om html codes in te voeren en runtime door PHP te laten outputten ... je moet dus beiden gebruiken:

mysql_real_escape_string() om veilig dingen in de database te zetten
EN
htmlentities() om te voorkomen dat texten als <img ... > door de browser worden ge"intepreteerd.

Mijn gouden regel is om htmlentities() te doen voor opslaan in combinatie met mysql_real_escape_string(). Hoef je je daarna nooit meer druk te maken bij weergave er wordt namelijk nog wel makkelijk even een printje bij gehacked en dan wordt de security snel vergeten.

[ Voor 8% gewijzigd door hamsteg op 27-12-2006 23:23 ]

[JHS]

Persoonlijk ben ik eerder geneigd om alleen de escaping te gebruiken voor opslag, aangezien er niet altijd een noodzaak voor htmlentities is . Ik beschouw dat eerder als een specifieke eis voor weergave, en niet voor opslag. Dat gooi ik er dan ook eigenlijk pas bij het weergeven overheen..

[eghie]

JHS schreef op donderdag 28 december 2006 @ 10:02:
Persoonlijk ben ik eerder geneigd om alleen de escaping te gebruiken voor opslag, aangezien er niet altijd een noodzaak voor htmlentities is . Ik beschouw dat eerder als een specifieke eis voor weergave, en niet voor opslag. Dat gooi ik er dan ook eigenlijk pas bij het weergeven overheen..

Zowieso is dat inderdaad het handigst. Als je bijvoorbeeld HTML op wil slaan in de database, om dat later weer te geven als echte HTML, dan wil je niet dat er htmlentities() eroverheen is gehaald. Ik gebruik die functie ook alleen bij het weergeven. Zo gebruik ik ook geen addslashes of magic_quotes bij het opvragen van een GET/POST variable, maar ik escape hem wanneer dat nodig is. Zo hoef ik de boel niet te hele tijd te gaan converteren, omdat ik de variable in de tussentijd nog nodig heb.

Lees trouwens ook deze guides over veilig PHP programmeren:
http://www.ilovejackdaniels.com/php/writing-secure-php
http://www.ilovejackdaniels.com/php/writing-secure-php-2
http://www.ilovejackdaniels.com/php/writing-secure-php-3

[hamsteg]

JHS schreef op donderdag 28 december 2006 @ 10:02:
Persoonlijk ben ik eerder geneigd om alleen de escaping te gebruiken voor opslag, aangezien er niet altijd een noodzaak voor htmlentities is . Ik beschouw dat eerder als een specifieke eis voor weergave, en niet voor opslag. Dat gooi ik er dan ook eigenlijk pas bij het weergeven overheen..

Eerlijk is eerlijk, ik misbruik een display functie inderdaad. De functie zou alleen gebruikt moeten worden als je iets output. Echter ik heb behoorlijk wat PHP/MySQL code gezien en het is mijn negatieve ervaring dat men bij eerste implementatie dit nog netjes doet, todat er iets fout is. Dan wordt er gezocht naar de fout, hackje/debugje hier (doe ik later wel helemaal goed), kackje/debugje daar (doe ik later ook wel helemaal goed) ... ha fout gevonden ... klaar. Oeps twee grote fouten laten zitten door de opluchting.

Als je het meteen doet bij opslaan doe je het op 1 plek en weet je zeker dat waar je de resultaten ook output in je script, het netjes "beveiligd" wordt geschreven. Alleen bij gebruik van input fields moet je alles even terugzetten, als je goed programmeert zij de input/verander velden het zelfde script. Dit zijn (2) duidelijk gedefinieerde punten tegen weet ik hoeveel andere output mogelijkheden ... 't is helaas mijn ervaring dat dit uiteindelijk toch beter is. Ik werk veel in teams met zeer ervaren en ook minder ervaren programmeurs, bij werken in teams zijn dit soort gedefinieerde punten vaak de beste oplossing. Maar nogmaals, je hebt gelijk, zo hoort het niet.

Een andere oplossing is het verbieden van print(f) en echo statements en daar eigen output voor te maken ... ik ben daar zelf geen voorstander van.

[crisp]

In HTML hoef je in principe enkel de < te encoden en de & indien deze gevolgd wordt door een name-character en zelf geen entity definieerd. Verder dient binnen attributen ook het voorkomen van " encoded te worden indien de attribuut-waarde ook tussen dubbele quotes staat (en vice versa voor de single quote).
Kortom: voor het correct encoden van speciale karakters is htmlentities() onnodig en kan je volstaan met htmlspecialchars(), de rest is afhankelijk van de gebruikte character-encoding van je document maar de meeste speciale karakters zitten al gewoon in de extended latin-sets. Bij UTF8/16 is het helemaal overbodig en bij XML-output kan je niets eens andere named entities gebruiken dan die voor < > & en "

[ Voor 24% gewijzigd door crisp op 28-12-2006 12:53 ]