Comment éviter de “Cross-Site des scripts d'Attaques”

Je suis sûr qu'il peut être fait fx. en PHP par la validation des formulaires

Pas vraiment. L'étage d'entrée est entièrement le mauvais endroit pour répondre à des XSS questions.

Si l'utilisateur tape, dire <script>alert(document.cookie)</script> dans une entrée, il n'y a rien de mal à cela en lui-même. Je l'ai fait dans ce message, et si StackOverflow ne pas le laisser nous aurions beaucoup de difficulté à parler à propos de JavaScript sur le site! Dans la plupart des cas, vous voulez permettre à tous d'entrée(*), de sorte que les utilisateurs peuvent utiliser un < caractère, littéralement, signifie un signe inférieur.

La chose est, lorsque vous écrivez du texte dans une page HTML, vous devez vous échapper correctement pour le contexte, il va dans. Pour PHP, cela signifie que l'aide htmlspecialchars() à la étage de sortie:

<p> Hello, <?php echo htmlspecialchars($name); ?>! </p>

[PHP astuce: vous pouvez définir vous-même une fonction avec un nom plus court pour faire echo htmlspecialchars, puisque c'est assez beaucoup de saisie à faire à chaque fois que vous voulez mettre une variable dans le code HTML.]

C'est nécessaire, quel que soit l'endroit où le texte vient de la, si elle provient d'un utilisateur-formulaire soumis ou non. Tandis que soumis par l'utilisateur des données est l'endroit le plus dangereux d'oublier votre code HTML de codage, le point est vraiment ce que vous êtes en prenant une chaîne de caractères dans un format (texte brut) et en l'insérant dans un contexte dans un autre format (HTML). Toutes les fois que vous jetez un texte dans un contexte différent, vous allez avoir besoin d'un codage/s'échapper régime approprié à ce contexte.

Par exemple, si vous insérez du texte dans un JavaScript littéral de chaîne, vous devez échapper à la citation de caractères, la barre oblique inverse et retours à la ligne. Si vous insérez du texte dans un composant de requête dans l'URL, vous aurez besoin de convertir la plupart des non-caractères alphanumériques dans %xx séquences. Chaque contexte a ses propres règles; vous devez savoir ce qui est le droit de la fonction de chaque contexte dans la langue de votre choix/cadre. Vous ne pouvez pas résoudre ces problèmes par l'amputation des soumissions de formulaire à l'étape d'entrée, même si beaucoup de naïfs programmeurs PHP essayer, qui est la raison pour laquelle de nombreuses applications de gâcher votre entrée en cas de coin et ne sont toujours pas sécurisé.

(*: eh bien, presque tout. Il y a un argument raisonnable pour le filtrage des caractères de contrôle ASCII du texte soumis. Il est très peu probable que de les laisser peut faire du bien.
En Plus des cours, vous aurez l'application validations spécifiques que vous aurez envie de le faire, comme faire en sorte qu'un champ e-mail ressemble à une adresse e-mail ou numéros de vraiment sont numériques. Mais ce n'est pas quelque chose qui peut être la couverture de l'appliquer à toutes les entrées pour vous sortir du pétrin.)

OriginalL'auteur bobince