XSS est-il une vulnérabilité côté serveur ou côté client?
Mes collègues affirment que XSS est une vulnérabilité côté serveur. J'ai toujours pensé qu'il s'agissait d'une vulnérabilité côté client. Lequel d'entre nous a raison et pourquoi?
Dans une attaque de script intersite, le script malveillant est exécuté sur le client, mais la faille réelle se trouve dans l'application. Cela ne signifie pas nécessairement qu'il s'agit d'une vulnérabilité strictement côté serveur, dans la mesure où la faille pourrait être dans le JavaScript de l'application, mais généralement, c'est en effet dans le code côté serveur, et toujours dans le code fourni par le serveur.
Il existe des atténuations côté client, telles que la protection XSS qui est désormais intégrée aux principaux navigateurs, ou des plug-ins qui empêchent l'exécution de JavaScript, mais en fin de compte XSS est une vulnérabilité d'application Web, et doit être corrigé par les développeurs d'applications.
Je dois mentionner qu'il existe une autre forme de XSS qui n'exploite ni les défauts du client (le navigateur) ni les défauts du serveur (l'application) mais les défauts de l'utilisateur. Ceci est souvent appelé Self-XSS et exploite la volonté d'un utilisateur incompétent d'exécuter JavaScript qu'il a copié et collé à partir d'Internet et dans la console des outils de développement de son navigateur, uniquement sur la base de la promesse que, contre tout espoir, cela permettra par magie lui de lire les messages Facebook de son ex-petite amie malgré le fait qu'elle ne soit pas amie et l'a bloqué.
Il se manifeste du côté client, mais c'est parce qu'il est autorisé à le faire par l'application Web. L'application ne valide pas le code qu'elle renvoie au navigateur. Et c'est pourquoi il s'agit d'une vulnérabilité côté serveur. Pensez-y de cette façon. Que feriez-vous pour résoudre le problème de XSS? Réparer le code côté serveur ou réparer le navigateur?
Cross-site Scripting (XSS) les attaques peuvent généralement être classées parmi:
- Attaques XSS stockées
- Attaques XSS réfléchies
- Attaques XSS basées sur DOM
L'attaque elle-même a lieu sur le client. Les trois types d'attaque pourraient se manifester pleinement dans le navigateur lui-même dans le cas d'une seule page ou d'une application hors ligne. Cependant, si les données sont stockées sur le serveur ou réfléchies par le serveur, le serveur contribue à la vulnérabilité.
IE8 a introduit X-XSS-Protection , ce qui a rendu les attaques réfléchies plus difficiles à exploiter.
La terminologie est un peu glissante, mais généralement un "bug XSS" est un exploit côté client d'une vulnérabilité côté serveur.
Le scriptage intersite n'est pas, en soi, un problème de sécurité. Le problème est que cela peut se produire à l'insu de l'utilisateur final. La plupart des sites ne sont pas codés pour que cela se produise, bien sûr: soit ils n'utilisent pas du tout les scripts intersites, soit ils indiquent clairement que c'est ce qu'ils font. Mais si les utilisateurs peuvent publier leur propre contenu, vous devez les empêcher d'ajouter des balises de script arbitraires aux pages. Sinon, ils pourraient glisser des éléments dans la page qui envoie des données à qui sait où.
Pour éviter cela, vous devez analyser le contenu créé par l'utilisateur, puis générer du HTML "propre" pour l'affichage qui n'a pas les balises que vous ne voulez pas (comme les balises de script). Certains les sites utilisent cette opportunité pour que les utilisateurs créent leur contenu dans une langue qui n'est pas HTML: Stack Exchange utilise Markdown. Mais tant que vous analysez toujours le contenu correctement , vous pouvez également utiliser HTML comme langue d'entrée. Il n'y a aucun avantage en termes de performances à faire correctement du HTML vers HTML, car il passe par le même type de cycle d'analyse/génération que les autres langues, mais c'est un langage de moins pour les développeurs (et éventuellement les utilisateurs). Cependant, vous devez résister à la tentation de simplement réutiliser le contenu HTML tel quel ou d'effectuer des substitutions de chaînes légères au lieu d'un cycle d'analyse/génération.
n "bug XSS" est ce qui se passe quand les gens découvrent comment publier du HTML arbitraire sur le site. Habituellement, cela se produit lorsque les développeurs utilisent directement l'entrée HTML sans passer par le cycle d'analyse/génération, mais parfois quelqu'un trouve un moyen d'inciter le générateur du site à leur donner du HTML qu'il n'a pas été conçu pour donner. Quoi qu'il en soit, le résultat final est le même: une fois qu'un utilisateur peut publier du code HTML arbitraire, il peut effectuer des scripts intersites avec, et c'est pourquoi nous l'appelons un bogue XSS. Mais le bogue n'est pas dans le XSS lui-même: c'est dans le code côté serveur qui a permis de publier des scripts arbitraires en premier lieu.
Il est généralement recommandé de filtrer autant de choses que possible du côté serveur et non sur la taille du client pour les raisons suivantes:
- Performance
- Responsabilité (Une fois que vous avez envoyé des données que vous ne devriez pas avoir, vous ne pouvez pas en contrôler les effets)
- Sécurité des utilisateurs (vous ne savez généralement pas de quelle version de votre client les utilisateurs disposent)
Une attaque XSS n'est pas très différente d'une injection SQL. Les deux sont causés par un contrôle incorrect de l'entrée utilisateur. Les attaques XSS sont généralement stockées dans votre base de données et distribuées via votre système à vos clients.
Le filtrage sur les attaques XSS doit être effectué sur l'entrée utilisateur, vous ne devez généralement accepter aucun type d'entrée Javascript. Si vous avez absolument besoin que vos clients puissent saisir Javascript, dans le cas par exemple de sites de programmation, vous devez d'abord y échapper.
J'espère que cela a aidé. Je recommande cette lecture pour plus d'informations: https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
"Fondamentalement, un attaquant, en créant un e-mail spécialement formaté, peut y intégrer JavaScript afin que le script soit exécuté dans le navigateur de la victime lorsque l'e-mail est affiché sur Yahoo Mail", a déclaré Pynnonen dans un e-mail à Threatpost. "L'attaquant n'avait pas besoin d'un accès spécial. En fait, l'attaque peut être effectuée sans même s'inscrire sur Yahoo Mail. Seule l'adresse e-mail Yahoo de la victime est nécessaire. "
Dans une description de la vulnérabilité publiée jeudi, Pynnonen a expliqué comment il pouvait formater un e-mail avec des attributs de données malveillants * qui faufileraient du code JavaScript malveillant au-delà des filtres de Yahoo qui s'exécutent en abusant de la façon dont Yahoo Mail affiche les liens vers des sites en liste blanche tels que YouTube .[enter preformatted text here][1]
J'ai lu des gens qui se soucient de ne pas utiliser l'URL ou autre pour charger différentes informations utilisateur ou autre (comme certains ici dans le didacticiel de Google - https://xss-game.appspot.com/ )
Bien que ce soit agréable à savoir, vous devez vous rappeler que chaque fonction et morceau de code du côté client peut être exécuté arbitrairement. La validation et la protection pour XSS proviennent du serveur. Je veux dire, pensez-y, vous pouvez ouvrir la console elle-même.
L'idée est l'injection de code malveillant du client qui finit par être une vulnérabilité sur le serveur. Cela peut amener les autres clients à recevoir des pages Web avec des scripts de merde intégrés. Pensez à un forum - si vous venez d'enregistrer et de rendre les balises dans ce message, quelqu'un que vous avez créé pourrait être en train d'exécuter arbitrairement du code pour quiconque consulte ce message sur le forum.
Par exemple, si stackoverflow ne s'est pas échappé correctement, vous auriez probablement été redirigé vers google.com w/the below
window.location.href = ' http://google.com ' (imaginez que ce soit entouré de balises de script, SE les formate et trop paresseux pour y échapper)
Il s'agit d'une vulnérabilité côté serveur qui peut être exploitée via des applications côté client.