De PHPhulp kroeg
$_SERVER['REQUEST_URI'] waarom gebruiken?
Ik wou net een form maken zoals ik al vele keren gedaan heb en ik zie dikwijls dat ($_SERVER['REQUEST_URI'] of $_SERVER['PHP_SELF'] worden gebruikt.
Nu is mijn vraag, waarom zou je dat gebruiken? Dit moet je filteren omdat je anders vatbaar bent voor een XSS aanval.
Je kan het ook leeg laten maar dan ben je kwetsbaar voor iframe aanval, en het is ook niet geldig voor html5.
Waarom dan niet gewoon de naam hardcoded erin zetten? (file.php)
Opsich kan je je daar met headers al redelijk tegen wapenen.
Je mag die action ook weghalen.
Ruben D op 02/01/2018 21:57:24:
Nu is mijn vraag, waarom zou je dat gebruiken? Dit moet je filteren omdat je anders vatbaar bent voor een XSS aanval.
Kun je dit ook uitleggen aan jezelf of aan een ander wat dit precies inhoudt? Of heb je dit ergens gehoord?
Je kunt $_SERVER parameters altijd escapen in de HTML-context met functies als htmlspecialchars().
Daarnaast zou je ook een link-functie of andere functionaliteit kunnen schrijven die interne applicatie (hyper)links genereert zodat je in het geheel niet afhankelijk bent van $_SERVER (en dit heeft ook andere voordelen, zie hieronder).
Ook zou de action niet de enige beveiliging tegen XSS moeten zijn. Het is altijd beter om op meerdere paarden te wedden als het om veiligheid gaat.
Je zou bijvoorbeeld een token kunnen opslaan in een sessie en deze meeposten met het formulier. Bij verwerking leg je deze twee weer naast elkaar. Zijn deze niet hetzelfde stuur je de gebruiker terug naar het formulier.
Ruben D op 02/01/2018 21:57:24:
Waarom dan niet gewoon de naam hardcoded erin zetten? (file.php)
Hardcoding is niet altijd aan te bevelen.
Maar het hangt er helemaal vanaf waar je het formulier voor gebruikt. Je kunt niet op voorhand een soort universele wetmatigheid opstellen. En als die er zou zijn, zou het action-veld ofwel verplicht zijn ofwel niet bestaan nietwaar? Het beste wat we kunnen doen is op grond van een concreet voorbeeld een advies geven.
Persoonlijk zou ik alles altijd zo expliciet mogelijk maken, zodat er geen ruimte voor interpretatie over blijft. Oftewel, ik zou in de action een volledige (en ge-escapete) URL opgeven die dynamisch wordt gegenereerd op grond van een of andere logica zodat, als je dit formulier (of de site) ooit verplaatst, de URL automatisch meeverandert. Op die manier heb je er verder ook geen omkijken meer naar. Dit is ook altijd compleet ondubbelzinnig.
EDIT: als dit een standalone script is (een contactformulier ofzo): doe je ding. Als dat ding helemaal op zichzelf staat en niet onderdeel is van een dynamisch gegenereerde website kun je prima de action hardcoden. Ik zou je wel als tip geven om de verschillende acties (het tonen van een formulier -al dan niet met foutmeldingen van een vorige submit-, het verwerken van een formulier, het tonen van een bedankpagina) te compartimenteren. Je wilt niet een halve HTML-pagina uitgedraaid hebben terwijl je een formulier aan het verwerken bent. Dat wordt vaak gewoon één grote onoverzichtelijke brei. Maar nogmaals, dit hangt van de toepassing af...
Gewijzigd op 03/01/2018 01:15:24 door Thomas van den Heuvel
In html5 mag je het action attribuut helemaal weglaten.
Dus:
Code (php)
1
<form method="post"> <!-- HTML5 VALID -->
Als ik kijk naar php scripts zie ik veel gebruik de server variabel maar zelf deed ik altijd hardcoded gelijk process.php die het dan in een database zet ofzo.
Heb wat op google zitten zoeken naar kwetsbaarheden met dit variabel en toen begon ik mij dit af te vragen.
Ruben D op 03/01/2018 16:49:33:
een CMS
Maar dan heb je toch wel een functie o.i.d. voor het bouwen van hyperlinks voor (interne) navigatie? Dit lijkt mij een van de pijlers waarop een CMS gebouwd zou moeten zijn (een fatsoenlijke interne structuur).
Daarbij, de REQUEST_URI gebruik je meestal om uit te zoeken waar je je bevindt, en niet zozeer waar je naartoe gaat.
Volgens mij is de REQUEST_URI ook "rauw", dus het kan sowieso geen kwaad om hier een urldecode() overheen te gooien.
Maar nu ik er over nadenk: ik zou in eerste instantie de REQUEST_URI niet gebruiken in een form action.