Maison > Article > interface Web > Failles de sécurité courantes JavaScript et technologie de détection automatisée_compétences Javascript

Failles de sécurité courantes JavaScript et technologie de détection automatisée_compétences Javascript

WBOYoriginal: 2016-05-16 15:43:341750parcourir

Avant-propos

Avec le développement du Web2.0 et la popularité du framework Ajax, les applications Web clientes riches (Rich Internet Applications, RIA) augmentent de jour en jour, et de plus en plus de logique a commencé à être transférée du côté serveur vers le client. Ces logiques sont généralement toutes écrites en langage JavaScript. Mais malheureusement, les développeurs ne prêtent généralement pas beaucoup d’attention à la sécurité du code JavaScript. Selon le rapport sur les tendances à mi-parcours 2011 d'IBM X-Force, 40 % des sites Web Fortune 500 et des sites Web connus présentent des vulnérabilités de sécurité JavaScript. Cet article montrera aux lecteurs les vulnérabilités de sécurité JavaScript courantes en combinaison avec le code, dans le but d'aider les lecteurs à éviter ces vulnérabilités de sécurité dans le travail de codage quotidien. De plus, les principes des vulnérabilités de sécurité JavaScript côté client sont légèrement différents de ceux des vulnérabilités de sécurité côté serveur. Il existe actuellement des difficultés techniques majeures dans la détection automatique des vulnérabilités de sécurité JavsScript. Cet article utilisera des cas pour partager avec les lecteurs comment utiliser le. nouvelles fonctionnalités d'IBM Rational AppScan Standard Edition V8.0 (la technologie JavaScript Security Analyzer (JSA) détecte automatiquement les vulnérabilités de sécurité JavaScript.

Fulnérabilités de sécurité JavaScript courantes

En décembre 2010, IBM a publié un livre blanc sur les vulnérabilités de sécurité JavaScript côté client dans les applications Web, qui présentait l'enquête sur l'état de la sécurité JavaScript menée par IBM Security Research Institute. L'échantillon de données comprend 675 sites Web, dont des sites Web de sociétés Fortune 500 et 175 autres sites Web bien connus, notamment des sociétés informatiques, des sociétés de services de sécurité d'applications Web, des sites de réseaux sociaux, etc. Afin de ne pas affecter le fonctionnement normal de ces sites Web, les chercheurs ont utilisé un robot d'exploration non intrusif qui analysait uniquement un sous-ensemble de pages accessibles sans connexion, pas plus de 200 pages par site. Ces pages ont été enregistrées et les chercheurs ont utilisé la technologie d'analyse de sécurité JavaScript d'IBM pour analyser ces pages hors ligne, en se concentrant sur les vulnérabilités de script intersite et de redirection basées sur DOM.

Les résultats des tests sont étonnants. 14 % de ces sites Web bien connus présentent de graves problèmes de sécurité JavaScript. Les pirates peuvent utiliser ces vulnérabilités pour implanter des logiciels malveillants, implanter des sites de phishing et détourner des sessions utilisateur. Ce qui est encore plus étonnant, c'est qu'avec la maturité de la technologie d'analyse de sécurité JavaScript d'IBM, le rapport X-Force de mi-2011 a montré qu'IBM avait retesté les sites Web bien connus mentionnés ci-dessus et découvert davantage de vulnérabilités de sécurité. Environ 40 % des sites Web disposent d'une sécurité JavaScript. vulnérabilités.

Code source du cadre de sécurité des autorisations universelles Java au niveau de l'entreprise SpringMVC mybatis ou hibernate ehcache shiro druid bootstrap HTML5

L'article suivant montrera aux lecteurs ces vulnérabilités de sécurité JavaScript courantes en combinaison avec le code, afin que les lecteurs puissent remarquer ces problèmes de sécurité pendant le processus de codage lui-même et éviter ces risques le plus tôt possible.

Scripts intersites basés sur DOM

Nous avons tous entendu parler du XSS (Cross Site Script, également connu sous le nom d'attaque par script intersite), qui fait référence à un attaquant insérant du code de script malveillant (généralement du code HTML et JavaScript) dans le code de pages Web légitimes), puis soumet le requête au serveur, puis la page de réponse du serveur est implantée avec le code de script malveillant de l'attaquant. L'attaquant peut utiliser ces codes de script malveillants pour mener des attaques telles que le piratage de session. Les scripts cross-site sont généralement divisés en types réfléchissants et persistants : les scripts cross-site réfléchissants se produisent lorsque les données de la demande sont rendues non codées et non filtrées dans la page de réponse du serveur. Les données persistantes font référence à des données de demande contenant du code malveillant. Elles sont stockées sur le serveur du serveur ; Application Web. Chaque fois que l'utilisateur visite une certaine page, le code malveillant sera automatiquement exécuté. Ce type d'attaque est particulièrement courant pour les sites de réseaux sociaux de type Web2.0, et la menace est également plus grande. Il existe deux manières principales de gérer les scripts intersites : premièrement, ne faites confiance à aucune entrée de l'utilisateur et essayez d'utiliser la technologie de liste blanche pour vérifier les paramètres d'entrée. Deuxièmement, échappez au contenu fourni par l'utilisateur lors de la sortie.

Mais on sait peu de choses qu'il existe un troisième type de vulnérabilité de script intersite. En 2005, Amit Klein a publié le livre blanc « DOM Based Cross Site Scripting ou XSS of the Third Kind » (« DOM Based Cross Site Scripting ou XSS of the Third Kind »), qui a révélé la compilation de scripts intersites basés sur DOM. du contenu n'a pas besoin de s'appuyer sur des réponses côté serveur. Si certaines pages HTML utilisent des attributs d'éléments DOM tels que document.location, document.URL ou document.referer, les attaquants peuvent utiliser ces attributs pour implanter des scripts malveillants afin d'implémenter DOM-. basées sur des références croisées.

Ci-dessous, nous démontrerons le principe du cross-site scripting basé sur DOM à travers une page HTML très simple. Supposons qu'il existe une page HTML statique (affichée dans le listing 1) qui affiche un message invitant l'utilisateur à se connecter avec succès.

Liste 1. Code HTML avec XSS basé sur DOM

<HTML>
<TITLE>Welcome!</TITLE>
Hi
<SCRIPT>
 var pos=document.URL.indexOf("name=")+5;
 document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<BR>
Welcome to our system
…
</HTML>

按照该页面 JavaScript 代码逻辑，它会接受 URL 中传入的 name 参数并展示欢迎信息，如清单 2 所示：

清单 2. 正常情况下的访问 URL

http://www.vulnerable.site/welcome.html?name=Jeremy

但如果恶意攻击者输入类似如下的脚本，见清单 3，该页面则会执行被注入的 JavaScript 脚本。

清单 3. 访问 URL 中注入脚本

http://www.vulnerable.site/welcome.html?name=3f1c4e4b6b16bbbd69b2ee476dc4f83aalert(document.cookie)df15d2bd3a0797a114d79c25e114807b

很明显，受害者的浏览器访问以上 URL 的时候，服务器端会跟正常情况下一样返回清单 1 中所示 HTML 页面，然后浏览器会继续将这个 HTML 解析成 DOM，DOM 中包含的 document 对象的 URL 属性将包含清单 3 中注入的脚本内容，当浏览器解析到 JavaScript 的时候会执行这段被注入的脚本，跨站点脚本编制攻击即成功实现。

值得关注的是，通过以上示例可以看出，恶意代码不需要嵌入服务器的响应中，基于 DOM 的跨站点脚本编制攻击也能成功。可能某些读者会认为：目前主流浏览器会自动转义 URL 中的 '0b0d3c1d0eac9ad57b06cc87ca4baf9e' 符号，转义后的注入脚本就不会被执行了，基于 DOM 的跨站点脚本编制也就不再有什么威胁了。这句话前半段是对的，但后半段就不准确了。我们要意识到攻击者可以很轻松地绕过浏览器对 URL 的转义，譬如攻击者可以利用锚点 '#' 来欺骗浏览器，如清单 4 所示。浏览器会认为 '#' 后面的都是片段信息，将不会做任何处理。

清单 4. 访问 URL 中结合锚点注入脚本

http://www.vulnerable.site/welcome.html#?name=3f1c4e4b6b16bbbd69b2ee476dc4f83aalert(document.cookie)df15d2bd3a0797a114d79c25e114807b

通过 URL 重定向钓鱼

网络钓鱼是一个通称，代表试图欺骗用户交出私人信息，以便电子欺骗身份。通过 URL 重定向钓鱼指的是 Web 页面会采用 HTTP 参数来保存 URL 值，且 Web 页面的脚本会将请求重定向到该保存的 URL 上，攻击者可以将 HTTP 参数里的 URL 值改为指向恶意站点，从而顺利启用网络钓鱼欺骗当前用户并窃取用户凭证。清单 5 给出了较为常见的含有通过 URL 重定向钓鱼漏洞的代码片段。

清单 5. 执行重定向的 JavaScript 代码片段

<SCRIPT>
…
 var sData = document.location.search.substring(1);
 var sPos = sData.indexOf("url=") + 4;
 var ePos = sData.indexOf("&", sPos);
 var newURL;
 if (ePos< 0) {
 newURL = sData.substring(sPos);
 } else {
 newURL = sData.substring(sPos, ePos);
 }
 window.location.href = newURL;
…
</SCRIPT>

On peut voir que ces scripts JavaScript sont responsables de l'exécution de la redirection et que la nouvelle adresse est interceptée à partir de la valeur d'attribut des éléments DOM tels que document.location, document.URL ou document.referer, comme indiqué dans la saisie de l'utilisateur. Inscription 6.

Listing 6. URL pour effectuer la redirection

http://www.vulnerable.site/redirect.html?url=http://www.phishing.site

Apparemment, une fois que l'utilisateur exécute l'URL indiquée dans le listing 6, il sera redirigé vers le site Web de phishing. Le principe de cette vulnérabilité est simple et plus facile à comprendre que la vulnérabilité de redirection côté serveur. Cependant, dans le cas du phishing via la redirection d'URL, l'URL du site de phishing ne sera pas interceptée et filtrée par le serveur. Cette vulnérabilité est donc souvent plus dissimulée que la vulnérabilité de redirection côté serveur.

Référence des cookies JavaScript du client

Les cookies sont généralement créés par le serveur Web et stockés dans le navigateur du client. Ils sont utilisés pour enregistrer l'identité de l'utilisateur, les informations de session et même les informations d'autorisation sur le client. Le code JavaScript côté client peut manipuler les données des cookies. Si JavaScript est utilisé côté client pour créer ou modifier les cookies d'un site, un attaquant peut visualiser le code, comprendre sa logique en lisant le code et même utiliser ces connaissances pour modifier les cookies. Une fois que le cookie contient des informations importantes, telles que des informations d'autorisation, les attaquants peuvent facilement exploiter ces vulnérabilités pour mener une élévation de privilèges et d'autres attaques.

Détournement de JavaScript

De nombreuses applications Web utilisent JSON comme mécanisme de transfert de données pour Ajax, qui est généralement vulnérable aux attaques de piratage JavaScript, tandis que les applications Web traditionnelles sont moins vulnérables. JSON est en fait un morceau de JavaScript, généralement sous forme de tableau. L'attaquant appelle une interface de données dynamique JSON du site attaqué via la balise 03c6714b8e3ee3238fc596020c4901e1 dans la page de son site malveillant, et obtient les données JSON via des technologies telles que JavaScript Function Hook. Si l'utilisateur se connecte au site Web attaqué (en supposant que les informations d'authentification d'identité sont enregistrées sur la base du cookie de session) et est incité par l'attaquant à visiter la page du site malveillant, alors, en raison du