Hyperliens d'encodage - quand et comment?

Question

J'ai une question liée à la sécurité. Mon application Web permet aux utilisateurs d'entrer des URL. L'URL est immédiatement stockée dans la base de données (pas de santization à ce stade, est-ce faux?). J'utilise Linq to SQL donc c'est déjà paramétré. Lors de l'affichage du lien hypertexte à l'utilisateur, j'utilise un répéteur. Ai-je besoin d'encoder le texte du lien hypertexte ainsi que la propriété tooltip et href? Ou dois-je seulement encoder le texte (qui est affiché). Aussi, je suppose que l'encodage d'URL est ce dont j'ai besoin ici, mais dois-je aussi utiliser l'encodage HTML?

J'ai essayé Server.UrlEncode sur les trois propriétés où le texte était <script> alert("hello") </script> et il a semblé perturber le href et le texte. Je suppose que cela signifie que ce n'est pas entièrement sécurisé? Editer - Je devrais ajouter, si je code en sortie, comment puis-je faire en sorte qu'un "/" soit affiché à la place de "% 2"? Remerciements

Answer 1

Autorisez-vous des liens/textes http (s) arbitraires?

Le texte (innerHtml de l'étiquette d'ancrage) doit être codé en htmlentity. En ce qui concerne le href:

D'abord en entrée, vérifiez au minimum que l'URL d'entrée est vraiment un lien http ou https avec uniquement des caractères valides dans le nom d'hôte et le chemin (utilisez RFC mais n'hésitez pas à contraindre davantage; utilisé pour les noms de domaine non-ascii, la liste blanche des caractères est courte). Cela empêchera javascript: urls, nom d'utilisateur: password @ hostname urls utilisés pour phishing, ftp: //, kindle: //, et d'autres schémas, utilisation de \ in url (converti en/par IE mais peut confondre votre lecture de domaine) , utilisation d'un espace vide excessif www.good% 20 {N fois} evil.com urls, etc.

Si vous autorisez les paramètres, urlencode les noms individuels et les valeurs, bien qu'ils affectent la cible (ne pas encoder l'entité html) . Bande # et tout ce qui suit puisque ce n'est pas envoyé à la cible de toute façon. Entourez le href entre guillemets.

Il peut être judicieux d'avertir les utilisateurs lorsqu'ils s'éloignent de votre site, le cas échéant. Notez que le site cible recevra l'URL de la page comme référent. L'autre option est de n'autoriser que les liens vers des domaines en liste blanche dont vous savez qu'ils ne sont pas nuisibles (en dehors du comportement responsable, votre site ne sera pas identifié comme étant lié à des sites nuisibles par netcraft, google, etc.).

Answer 2

Est-ce faux? OUI Désinfecter lors de l'entrée, pas de la sortie.

Si vous désinfectez avant de l'enregistrer sur db, inutile de coder lors de la sortie. Règle générale: faites confiance à vos données sur tous les calques ou sur votre application, désinfectez-les rapidement.

Answer 3

Vous devez désinfecter directement à l'entrée (c'est différent de l'échappement). Cela signifie effectuer une sorte de validation que les données sont une URL, ou à tout le moins, ne contient que des caractères autorisés pour une URL. Utilisez Regex pour cela, ou une bibliothèque d'analyse d'URL (Désolé, je ne connais pas trop l'API .NET).

Vous devriez encoder en sortie, sauf si vous voulez l'utiliser comme URL dans un élément HTML (ce que vous faites!), Auquel cas vous ne devriez pas faire d'encodage. Vous aurez certainement besoin d'encoder l'info-bulle et le texte dans le corps de la balise de lien. Je penserais très fort à la façon dont vous désinfectez l'entrée avant qu'elle ne soit entrée dans la base de données. Je suggère parcourir ces attaques fantastic resource of example XSS.

La raison pour laquelle vous encodez en sortie, et non lors de l'enregistrement dans la base de données, est que chaque support de sortie peut avoir des règles d'encodage/d'échappement différentes. par exemple. HTML est différent de JavaScript, ce qui est différent de dire PDF, ou Flash, ou CSS, etc ...

Aussi, je suppose que vous utilisez des instructions préparées lors de l'enregistrement dans la base de données, pour éviter l'injection SQL?