web-dev-qa-db-fra.com

HTML: Devrais-je encoder plus grand que ou pas? (> & gt;)

Lors du codage de données potentiellement dangereuses, existe-t-il une raison de coder >?

  • Il valide de toute façon.
  • Le navigateur interprète la même chose dans les deux cas, (dans les cas de attr="data", attr='data', <tag>data</tag>)

Je pense que les raisons pour lesquelles quelqu'un ferait cela sont

  • Pour simplifier la suppression des balises basées sur regex. <[^>]+>? (rare)
  • Chaînes non citées attr=data. : -o (ne se passe pas!)
  • Esthétique dans le code. (et alors?)

Est-ce que je manque quelque chose?

39
George Bailey

À proprement parler, pour empêcher l’injection HTML, vous devez uniquement coder < en tant que &lt;.

Si les entrées de l'utilisateur doivent être placées dans un attribut, encodez également " en tant que &quot;.

Si vous faites les choses correctement et utilisez les attributs correctement cités, vous n'avez pas à vous soucier de >. Cependant, si vous n'êtes pas sûr de cela, vous devriez l'encoder juste pour avoir l'esprit tranquille - cela ne fera aucun mal.

35
Niet the Dark Absol

La spécification HTML4 de la section 5.3.2 indique que 

les auteurs doivent utiliser "&gt;" (décimal ASCII 62) dans le texte au lieu de ">"

donc je crois que vous devriez encoder le plus grand signe > en tant que &gt; (car vous devez obéir aux normes).

15

Les analyseurs HTML des navigateurs actuels n'ont aucun problème avec > ucoté

Cependant, malheureusement, l'utilisation d'expressions régulières pour "analyser" HTML dans JS est assez commune. (exemple: Ext.util.Format.stripTags ). De même, des outils de ligne de commande, des IDE, des classes Java, etc. mal écrits peuvent ne pas être assez sophistiqués pour déterminer le limiteur d'une balise d'ouverture.

Donc, vous pouvez avoir des problèmes avec du code comme ceci:

<script data-usercontent=">malicious();//"></script>

(Notez comment le surligneur de syntaxe traite cet extrait!)

4
user123444555621

Oui, car si les signes n'étaient pas codés, cela permet à xss d'utiliser des formulaires sur les médias sociaux, entre autres, car un attaquant peut utiliser la balise <script>. Si vous analysez les signes, le navigateur ne l'exécutera pas mais affichera le signe.

0
coder

Toujours

Ceci permet d'éviter les injections de XSS (par le biais d'utilisateurs utilisant l'un de vos formulaires pour soumettre du HTML brut ou du javascript). En échappant votre sortie, le navigateur sait ne pas analyser ou exécuter une partie de celle-ci, mais seulement l’afficher sous forme de texte.

Cela peut sembler moins problématique si vous ne traitez pas une sortie dynamique basée sur les entrées de l'utilisateur, mais il est important de comprendre au moins, sinon de prendre une bonne habitude.

0
mrlee