Voer nooit een stukje data uit naar de HTML-stream die niet door htmlspecialchars() is gegaan en je bent klaar. Eenvoudige regel, gemakkelijk te volgen, elimineert elk XSS-risico volledig.
Als programmeur is het uw werk om het te doen.
U kunt definiëren
function h(s) { return htmlspecialchars(s); }
if htmlspecialchars() is te lang om 100 keer per PHP-bestand te schrijven. Aan de andere kant, met behulp van htmlentities() is helemaal niet nodig.
Het belangrijkste punt is:er is code en er zijn gegevens. Als je de twee vermengt, ontstaan er slechte dingen.
In het geval van HTML is code elementen, attribuutnamen, entiteiten, opmerkingen. Gegevens zijn al het andere. Gegevens moeten ontsnappen om te voorkomen dat ze voor code worden aangezien.
In het geval van URL's is code het schema, de hostnaam, het pad, het mechanisme van de querystring (? , & , = , # ). Gegevens zijn alles in de queryreeks:parameternamen en waarden. Ze moeten ontsnappen om te voorkomen dat ze voor code worden aangezien.
URL's die zijn ingesloten in HTML moeten worden dubbel ontsnapt (door URL-escaping en HTML-escaping) om te zorgen voor een goede scheiding van code en gegevens.
Moderne browsers zijn in staat om verbazingwekkend kapotte en onjuiste opmaak om te zetten in iets bruikbaars. Dit vermogen moet echter niet worden benadrukt. Het feit dat iets toevallig werkt (zoals URL's in <a href> zonder de juiste HTML-escaping toegepast) betekent niet dat het goed of correct is om het te doen. XSS is een probleem dat wortelt in a) mensen die zich niet bewust zijn van gegevens-/codescheiding (d.w.z. "ontsnappen") of die slordig zijn en b) mensen die slim proberen te zijn over welk deel van de gegevens ze niet hoeven te ontsnappen.
XSS is eenvoudig te vermijden als u ervoor zorgt dat u niet in de categorieën a) en b) valt.