thecodest, Author at The Codest

XSS

Nous vivons à l'ère des cadres, et non des langages. Cela implique que les programmeurs devraient pouvoir se préoccuper moins de nombreux aspects du développement, y compris la sécurité. La majorité des cadres actuels de backend mettent en œuvre des modules de sécurité, qui sont testés par des entreprises externes spécialisées et par de grandes sociétés. C'est pourquoi, le déclin de la sensibilisation à la sécurité pourrait se manifester, par exemple, entre les jeunes programmeurs, qui assument davantage de responsabilités pour les produits, notamment en termes de freelancing.

L'une des attaques les plus courantes du côté client de l'application est le XSS (Cross-Site Scripting). Elle est réalisée en injectant des scripts exécutables côté client dans les applications web [1] et utilise des méthodes de rendu HTML implémentées ou des méthodes d'authentification. Javascript code les évaluateurs qui l'exécutent. Le XSS est relativement lucratif car de nombreuses données différentes peuvent être collectées, notamment des cookies de session ou des données utilisateur, et il peut installer une application de suivi telle qu'un enregistreur de frappe, ce qui le rend dangereux à la fois pour les utilisateurs et pour les propriétaires d'entreprises. Parfois, d'autres formes d'attaques sont effectuées pour permettre le XSS sur la page, telles que Injection SQL.

Exemple

Le formulaire de connexion sur la page rend le paramètre loginName envoyé dans la requête GET dans l'entrée du nom de connexion. La valeur n'est traitée ni par le serveur ni par le client de l'application. En faisant une requête : http://localhost:8080/login?name=<script>alert(document.cookies)</script>
le code est exécuté et les données sont exposées

Il s'agit d'un exemple de Attaque XSS réfléchieLes attaques de ce type sont les plus courantes, où des scripts sont injectés par l'intermédiaire d'une adresse URL spécialement préparée, soumise à la victime et reflétée par la réponse du serveur. D'autres formes d'attaques populaires connues sont les suivantes :

XSS stocké L'application client utilise des données injectées stockées sur le serveur, généralement par le biais de formulaires disponibles dans l'application. L'application client rend le code qui est stocké, par exemple, dans une base de données.
DOM XSS réalise une attaque XSS sans utiliser le côté serveur. Dans la suite de l'article, nous nous concentrerons sur cette forme d'attaque.

Vulnérabilités actuelles dans les bibliothèques React et Vue

Pour les versions actuelles React/Vue, deux problèmes majeurs ont été détectés et n'ont pas encore été officiellement corrigés. La première vulnérabilité, de même nature pour tous les frameworks, est liée aux méthodes permettant le rendu de HTML brut dans les modèles : v-html et dangereusementSetInnerHTML, respectivement, pour Vue et React. Chaque documentation [2] informe les lecteurs qu'une utilisation imprudente peut exposer les utilisateurs à une attaque XSS. Si aucune autre option ne permet de résoudre le problème, veillez à ce que les données soient filtré et échappé. Bien qu'elles soient dangereuses, vous ne devez pas vous attendre à ce que ces méthodes soient corrigées. Utilisez-les à vos risques et périls.

Au premier trimestre 2018, un gros bug a été détecté dans React, permettant l'exécution directe de code en définissant la propriété de l'élément de la balise. Le passage d'un exemple de code à l'intérieur d'attributs, tels que javascript:alert(1) et l'exécution d'un lien rendu exécutera le code. Ce problème [4] est toujours ouvert et aucun correctif n'a été préparé et fusionné, assurez-vous donc que votre code est sûr. Les exemples proposés dans la discussion officielle suggèrent quelques moyens de surmonter ce problème.

S'il n'est pas possible de mettre à jour les dernières versions, assurez-vous que les anciens problèmes ne vous posent pas de problèmes en veillant à ce que votre code ne soit pas exposé à des risques :

enfant nœud injection - React, l'utilisation de React.createElement [5]
rendu côté serveur - React/Vue [6]
Injection CSS [8]

Il s'agit toujours de Javascript. Il s'agit toujours de front-end

N'oubliez pas qu'en plus des cadres ou des bibliothèques eux-mêmes, le langage Javascript possède certaines fonctions dangereuses, qui doivent être évitées ou utilisées avec prudence. Elles sont généralement liées à la manipulation du DOM ou à l'exécution de scripts. eval() représente des fonctions phares de ce type et est extrêmement dangereuse car elle exécute directement un code stringifié donné [9]. Aussi, regardez mieux votre code lorsque vous trouvez l'une de ces fonctions :

document.write
document.writeln
(élément).innerHTML
(élément).outerHTML
(élément).insertAdjacentHTML

Dans ce cas, l'utilisation de linters avec des règles appropriées peut être utile pour trouver ces points vulnérables. Il existe également de nombreux analyseurs de code ouverts ou commerciaux qui peuvent vous aider à détecter les failles de sécurité dans le code développé.

Quelle que soit la bibliothèque ou le cadre choisi, nous devons toujours nous rappeler les principes de base liés au développement de l'interface utilisateur. Tout d'abord, assurez-vous toujours que le code externe que vous injectez provient d'une source fiable. Audit vos dépendances, et choisissez-les judicieusement. Certaines peuvent contenir de graves vulnérabilités, exposant votre code même si tout va bien avec le code lui-même. Vous pouvez en savoir plus sur la sécurité des dépendances ici :

https://thecodest.co/blog/security-in-javascript-packages/

Alors... faut-il encore s'inquiéter ?

Oui - et j'encourage vivement tout le monde à ne jamais faire confiance aux bibliothèques externes ou à soi-même en termes de sécurité. Quelle que soit la sécurité que vous attendez de votre logiciel, faites toujours l'effort de le tester autant que possible en termes de formes d'attaques courantes [10].

En savoir plus :

5 erreurs à éviter lors de la maintenance d'un projet dans PHP

Développement PHP. Symfony Console Component - Trucs et astuces

Pourquoi avons-nous besoin de Symfony Polyfill (... et pourquoi nous ne devrions pas)