Je suis sûr que cela peut être fait fx. en PHP en validant des formulaires
Pas vraiment. L'étape d'entrée est entièrement le mauvais endroit pour traiter les problèmes XSS.
Si l'utilisateur tape, disons <script>alert(document.cookie)</script> dans une entrée, il n'y a rien de mal à cela en soi. Je l'ai juste fait dans ce message, et si StackOverflow ne l'autorisait pas, nous aurions beaucoup de mal à parler de JavaScript sur le site! Dans la plupart des cas, vous souhaitez autoriser toute entrée (*), afin que les utilisateurs puissent utiliser un caractère < pour signifier littéralement un signe inférieur. Le fait est que, lorsque vous écrivez du texte dans une page HTML, vous devez l'échapper correctement pour le contexte dans lequel il va. Pour PHP, cela signifie que l'utilisation htmlspecialchars() à l'étage de sortie :
<p> Hello, <?php echo htmlspecialchars($name); ?>! </p>
[indice PHP: vous pouvez vous définir une fonction avec un nom plus facile à faire echo htmlspecialchars, puisque cela est tout à fait beaucoup de taper à faire tous les temps que vous voulez mettre une variable dans du code HTML.]
Ceci est nécessaire, peu importe d'où vient le texte, qu'il provienne d'un formulaire soumis par l'utilisateur ou non. Alors que les données soumises par les utilisateurs sont l'endroit le plus dangereux pour oublier votre encodage HTML, le fait est que vous prenez une chaîne dans un format (texte brut) et l'insérez dans un contexte dans un autre format (HTML).Chaque fois que vous lancez du texte dans un contexte différent, vous aurez besoin d'un schéma d'encodage/d'échappement approprié à ce contexte. Par exemple si vous insérez du texte dans un littéral de chaîne JavaScript, vous devrez échapper le caractère de citation, la barre oblique inverse et les retours à la ligne. Si vous insérez du texte dans un composant de requête dans une URL, vous devrez convertir la plupart des caractères non alphanumériques en séquences %xx. Chaque contexte a ses propres règles; vous devez savoir quelle est la bonne fonction pour chaque contexte dans votre langue/cadre choisi. Vous ne pouvez pas résoudre ces problèmes en mangeant des soumissions de formulaire à l'étape de saisie - bien que de nombreux programmeurs PHP naïfs essaient, ce qui explique pourquoi tant d'applications gâchent votre entrée dans les cas de coin et ne sont toujours pas sécurisées.
(*: bien, presque tous.) Il y a un argument raisonnable pour filtrer les caractères de contrôle ASCII du texte soumis.Il est très peu probable que leur permettre de faire quelque chose.Out Bien sûr, vous aurez des validations spécifiques à l'application vous voulez faire, comme s'assurer qu'un champ e-mail ressemble à une adresse e-mail ou que les chiffres sont vraiment numériques.Mais ce n'est pas quelque chose qui peut être appliqué à toutes les entrées pour vous sortir du pétrin.
Cadre cible? PHP? – Arthur
Il existe des options pour tout langage/framework/etc. Vous obtiendrez des réponses plus spécifiques - comme htmlencode - si vous fournissez plus d'informations sur votre configuration. (Empiler). – Tobiasopdenbrouw
Vous avez raison, Tobiasopdenbrouw, mais c'était en fait plus comme une question générale que d'autres personnes pourraient aussi en tirer :) – Latze