Prévention des scripts intersites supprimée & lt and & gt


2

Je suis en train de tester une application qui ignore uniquement les symboles < et >. L'entrée d'utilisateur en cours de validation est toujours insérée entre les balises html comme <b>, <span>, <div>, etc. et n'est jamais passée à la page en tant qu'attribut. Est-ce une protection suffisante ou existe-t-il un moyen de contourner ce type de filtre?

Exemple:

<a href="http://www.site.com" style="color:white"> 
    UserInput 
</a> 

Cordialement.

+2

Ne pas décaper les caractères, les coder. Ou mieux encore, demandez à votre infrastructure web de les encoder automatiquement. 13 août. 132013-08-13 14:54:18

  0

Je suis d'accord avec CodesInChaos ... pour le coût du développement, vous pouvez aussi bien encoder la sortie que nécessaire pour le contexte plutôt que d'avoir un faible processus de désinfection des entrées comme une forme de sécurité. Que se passe-t-il à l'avenir lorsque l'entrée de l'utilisateur se termine en tant que variable JavaScript ou en tant que champ dans une balise <input>? 14 août. 132013-08-14 15:26:17

  0

Je ne suis pas certain de comprendre correctement le problème, mais que se passe-t-il si le message $ UserInput = &lt;script&gt; (1); &lt;/script & gt'? 09 déc.. 132013-12-09 18:59:53

5

Ce n'est pas une protection suffisante

Il y a plusieurs façons un attaquant pourrait être en mesure de se faufiler dans une séquence d'octets qui sera interprété par le navigateur de quelqu'un comme le balisage.

Dans votre cas, il est même possible d'utiliser ampersand encoding pour passer les caractères < et >.

A défaut, double encoding pourrait être utilisé pour contourner vos filtres, ou même overlong utf-8 sequences (cependant, ce dernier est un peu désuet et la plupart des piles logicielles ne le sont pas).

Ce ne sont que quelques exemples, mais il existe many more façons de contourner les filtres de balisage simple comme le vôtre. This bit en particulier est pertinente.

  0

J'ai essayé toutes ces méthodes mais personne n'a travaillé. Aussi j'ai réalisé que < and > ne sont pas filtrés seulement les étiquettes html réelles. 13 août. 132013-08-13 13:53:27

+1

@Nucklear Si vous avez tout jeté de cette page OWASP à votre filtre, alors vous êtes probablement assez bon. La liste blanche est toujours l'approche préférée. par exemple 'msg.matches (" [\ w \ s] * ")' 13 août. 132013-08-13 13:59:05


1

Oh, où commencer ...

S'il y a un principe de sécurité qui se prouve est encore et encore et encore que les listes noires échouent. Jouez le long jeu - assurez-vous que votre application web résiste au nombre limité d'attaques que vous avez lancées aujourd'hui, mais Internet va pouvoir essayer des milliers de choses avec des milliers de variables supplémentaires (nouveau code, différents navigateurs, différents jeux de langues, etc, etc.).

"L'entrée de l'utilisateur en cours de validation est toujours" - vous dit aujourd'hui. Que se passe-t-il lorsque vous passez à autre chose et qu'un autre développeur hérite de ce code? Vont-ils comprendre et honorer les engagements que vous vous êtes faits dans votre tête? Si vous faites la validation d'entrée et l'encodage de sortie, vous donnez une chance au prochain gars.

Allez-y et dépouilleront "" < scénario >", ce qui se passe quand quelqu'un soumet "" < scr < scénario > IPT > ""?


0

Qui fournit l'HREF dans l'URL que vous avez fournie ici:

<a href="http://www.site.com" style="color:white"> 
    UserInput 
</a> 

Si le href est tiré d'une étiquette d'entrée. Alors c'est juste un autre cas de filtrage insuffisant ou d'échappement de l'entrée de l'utilisateur. Toutes les entrées de l'utilisateur doivent être considérées comme mauvaises.

Par exemple, si elle est l'utilisateur fournissant l'URL pour cette balise d'ancrage dans votre exemple les cas, il est tout à fait possible que cette sXSS fonctionnera et la charge sur chaque souris sur:

URL: http://www.site.com" onmouseover="javascript:alert(1)" 

Alternativement, vous pourrait changer le onmousover to onload et maintenant vous avez votre javascript s'exécutant sur chaque chargement de page. La désactivation des événements DOM à partir des balises HTML est une autre méthode pour empêcher ce type d'attaque sXSS.