 Moderator |
|
Dit hangt van een aantal zaken af:
1. De navigatie door je formulier-pagina('s)
Dit bepaalt mede hoe je informatie bewaart en overdraagt. Als je bijvoorbeeld een script formulier.php naar zichzelf laat POSTen, zou je ook meteen het formulier weer kunnen vullen indien er een fout is opgetreden. Dit heeft het voordeel dat je dat direct kunt doen via $_POST (met de nodige escaping uiteraard, zie hieronder). Een nadeel is dat als iemand de pagina dan probeert te verversen je een (lelijk) bericht krijgt met de vraag of je de informatie opnieuw wilt versturen.
Een alternatief is dat je je formulier-functionaliteit meer uit elkaar trekt. Je stopt het (vullen en) afdrukken en het verwerken in aparte acties. Voordeel is meer overzicht door het scheiden van deze acties. Een mogelijk nadeel is dat je je POST informatie na het verwerken in principe kwijt bent. Als er dan een fout is opgetreden, dan moet je er op een of andere manier voor zorgen dat je deze onthoudt, bijvoorbeeld door deze informatie tijdelijk in een sessie te zetten.
2. De character encoding die je gebruikt
Je kunt een formulier "veilig" initialiseren met gebruikersdata door het escapen van deze uitvoer. Dit doe je doorgaans met htmlspecialchars(). Maar hierbij moet je wel aangeven welke character encoding je document gebruikt, anders werkt je escaping mogelijk niet goed. Het is sowieso een goede zaak om overal dezelfde character encoding te gebruiken, en als het kan bij voorkeur UTF-8.
EDIT: Daarnaast zou je ook met de volgende zaken rekening moeten houden:
Input filtering
Bij het verwerken van je formulier zou je ook je invoer moeten valideren voordat je deze opslaat / verder verwerkt. Hiervoor kun je de filter_ functies van PHP gebruiken.
Output escaping
Dit geldt voor informatie die je opnieuw afdrukt omdat deze onvolledig of fout is, maar dit zou je ook moeten doen als je deze uit je database haalt. Enkel omdat informatie was gevalideerd voor het opslaan wil niet zeggen dat deze informatie veilig is om af te drukken! Eigenlijk zou je ALTIJD output moeten escapen, tenzij je een special reden hebt om dit niet te doen.
Gebruik tokens
Als je van formulieren gebruik maakt kan het ook verstandig zijn om van tokens gebruik te maken. Dit voorkomt dat iemand (eenvoudig) vanaf een externe site data kan POSTen (dit wordt ook wel Cross Site Request Forgery (CSRF) genoemd). Het principe is simpel: bij het laden van het formulier genereer je een random string (het token). Deze geef je enerzijds mee via een hidden veld, en anderzijds via een sessie-variabele. Wanneer je het formulier verwerkt vergelijk je deze twee waarden. Indien deze hetzelfde zijn zet je de verwerking voort, anders breek je deze af. Het token in de sessie moet na de controle ook meteen ongeldig gemaakt worden (is dus slechts voor één submit geldig).
addslashes en magic_quotes_gpc (met name in combinatie met database-gebruik)
Vertrouw hier niet op (magic_quotes_gpc is deprecated in PHP 5.3.0 en is verdwenen in 5.4.0) en als je hier nog (onbewust) gebruik van maakt (controleer dit met phpinfo()) dan ooooh boy, dan heb je misschien nog wat opschoonwerk te doen voordat je PHP-versie geupgrade wordt en je applicaties veranderen in een gatenkaas  . Zie ook mijn MySQLi tutorial.
Als je een voorbeeld wilt waarbij deze principes worden toegepast hoor ik het wel. |
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
Gesponsorde links
Actiefste leden van de maand
