javascript - problème de vulnérabilité XSS

Question

Je voudrais demander comment gérer la vulnérabilité XSS dans le front-end ?

迷茫 · Answer

L'attaque XSS (Cross-Site Script) est également appelée attaque de type cross-site scripting. Il s'agit essentiellement d'une attaque par injection. Son principe est simplement d'utiliser divers moyens pour ajouter du code malveillant. la page Web et laissez la victime exécuter ce script. XSS peut faire tout ce que l'utilisateur peut faire en utilisant le navigateur. Une bonne politique de même origine ne peut pas garantir contre les attaques XSS, car l'attaquant se trouve actuellement dans la même origine.

Méthode d'attaque XSS

XSS (Cross-Site Script) 攻击又叫跨站脚本攻击, 本质是一种注入攻击. 其原理, 简单的说就是利用各种手段把恶意代码添加到网页中, 并让受害者执行这段脚本. XSS能做用户使用浏览器能做的一切事情. 伟大的同源策略也无法保证不受XSS攻击，因为此时攻击者就在同源之内.

xss攻击方式

从攻击的方式可以分为

反射型
存储型
文档型

这种分类方式有些过时, 长久以来, 人们认为XSS分类有以上三种, 但实际情况中经常无法区分, 所以更明确的分类方式可以分为以下两类:

client(客户端型)
server(服务端型)

当一端xss代码是在服务端被插入的, 那么这就是服务端型xss, 同理, 如果代码在客户端插入, 就是客户端型xss.

防止xss攻击

转义

无论是服务端型还是客户端型xss，攻击达成都需要两个条件

代码被注入
代码被执行

其实只要做好无论任何情况下保证代码不被执行就能完全杜绝xss攻击.

总之, 任何时候都不要把不受信任的数据直接插入到dom中的任何位置, 一定要做转义。

对于某些位置,不受信任的数据做转义就可以保证安全

一般的标签属性值
p body 的内部html

对于某些位置，即使做了转义依然不安全

script标签中
注释中
表签的属性名名
标签名
css标签中

使用JSON.parse 而不是eval, request 的content-type要指定是Content-Type: application/json;

如果链接的URL中部分是动态生成的, 一定要做转义.

使用浏览器自带的xss-filter

可以通过http头控制是否打开 xss-filter, 默认为开启.

通常情况下, 在http header中加入以下字段表示启用xss-filter.

X-XSS-Protection:1 (默认)
X-XSS-Protection:1;mode=block (强制不渲染, chrome跳空白页,IE展示一个#号)

如需禁用xss-filter, 将 X-XSS-ProtectionSelon la méthode d'attaque, il peut être divisé en

Réfléchissant
Type de stockage
Type de document

Cette méthode de classification est quelque peu dépassée. Pendant longtemps, les gens ont cru qu'il existe trois types de classifications XSS, mais dans les situations réelles, elles ne peuvent souvent pas être distinguées. Par conséquent, une méthode de classification plus claire peut être divisée en deux catégories suivantes. :

🎜client (type de client)🎜
🎜serveur(type de serveur)🎜

🎜Lorsque le code XSS à une extrémité est inséré côté serveur, il s'agit alors de XSS côté serveur. De même, si le code est inséré côté client, il s'agit de XSS côté client.🎜

Empêcher les attaques XSS

🎜évasion🎜 🎜Qu'il s'agisse de XSS côté serveur ou côté client, deux conditions sont requises pour réaliser l'attaque🎜

🎜Le code est injecté🎜
🎜Code exécuté🎜

🎜En fait, tant que vous vous assurez que le code n'est exécuté en aucun cas, vous pouvez éliminer complètement les attaques XSS.🎜 🎜En bref, n'insérez à aucun moment des données non fiables directement dans n'importe quel emplacement du DOM, assurez-vous d'y échapper. 🎜 🎜🎜Pour certains emplacements, l'échappement de données non fiables peut garantir la sécurité🎜

🎜Valeurs générales des attributs de balise🎜
🎜p HTML interne du corps🎜

🎜🎜Pour certains postes, même s'ils sont échappés, ils restent dangereux🎜

🎜balise de script🎜
🎜Annotation🎜
🎜Nom d'attribut de la balise de table🎜
🎜Nom du tag🎜
🎜dans la balise CSS🎜

🎜Utilisez JSON.parse au lieu de eval, le type de contenu de la requête doit être spécifié comme Content-Type : application/json;🎜 🎜Si une partie de l'URL liée est générée dynamiquement, elle doit être échappée.🎜 🎜Utilisez le filtre XSS fourni avec le navigateur🎜 🎜

🎜

🎜Vous pouvez contrôler si vous souhaitez activer le filtre XSS via l'en-tête http, la valeur par défaut est activée.🎜

🎜Normalement, ajouter les champs suivants à l'en-tête http signifie activer xss-filter.🎜

Content-Security-Policy-Report-Only: script-src 'self'; report-uri http://cspReport/

🎜Si vous devez désactiver le filtre XSS, définissez X-XSS-Protection sur 0.🎜 🎜Comme mentionné ci-dessus, les navigateurs modernes disposent d'un certain degré de défense contre la porte réfléchissante : page de test XSS.🎜 🎜De plus, les navigateurs ne résistent pas aux contenus stockés 🎜Politique de sécurité du contenu🎜 🎜Politique de sécurité du contenu, à savoir politique de sécurité du contenu, appelée csp.🎜

Afin d'atténuer une grande partie des problèmes potentiels de cross-site scripting, le système d'extension du navigateur introduit CSP. CSP gère le contenu que le site Web est autorisé à charger et utilise un mécanisme de liste blanche pour agir sur les ressources chargées ou exécutées par le site Web. site Web. Dans la page Web, une telle politique est définie via des informations d'en-tête HTTP ou des éléments méta.

CSP n'est pas utilisé pour empêcher les attaques XSS, mais pour minimiser les dommages causés par XSS. En fait, à part les développeurs qui échappent à XSS eux-mêmes, il n'y a aucun autre moyen d'empêcher XSS de se produire. C'est la chose la plus abordable. que HTML5 apporte à la sécurité Web Alors comment introduire CSP ?

via l'en-tête de réponse

Autoriser uniquement les scripts à charger la politique de sécurité du contenu à partir de la source : script-src 'self'

via la balise META du HTML

Identique à ci-dessus

Donc, à part restreindre script-src, que peut restreindre CSP ?

base-uri : limite l'uri de ce document

child-src : Limiter la source des fenêtres enfants (iframe, fenêtres pop-up, etc.), en remplaçant frame-src

connect-src : Limiter les sources auxquelles le script peut accéder

font-src : limiter la source de la police

form-action : Limiter les sources auxquelles le formulaire peut être soumis

frame-ancestors : limite les pages sur lesquelles la page actuelle peut être chargée par iframe, frame, objet, etc.

frame-src : obsolète avec child-src, qui limite les sources que la page actuelle peut charger, correspondant aux frame-ancêtres

img-src : Limiter les sources à partir desquelles les images peuvent être chargées

media-src : limite les sources vidéo, audio, source et piste pouvant être chargées

object-src : Restreindre les sources à partir desquelles les plugins peuvent être chargés

bac à sable : Forcer l'ouverture du mode bac à sable

On peut voir que CSP est une stratégie puissante qui peut limiter les sources de presque toutes les ressources pouvant être utilisées. Une bonne utilisation de CSP peut réduire considérablement les risques causés par XSS.

De plus, CSP fournit également un champ d'en-tête de rapport Content-Security-Policy-Report-Only En utilisant ce champ d'en-tête, le navigateur signalera l'état du CSP au serveur.

.

{ 
  "csp-report":
      { 
      "document-uri": "http://cspReport/test.php",
      "referrer": "",
      "violated-directive": "script-src 'self'",
      "original-policy": "script-src 'self'; report-uri http://cspReport/",
      "blocked-uri": ""
    }
}

En utilisant les paramètres ci-dessus, s'il y a du js en ligne sur la page, il sera toujours exécuté, mais le navigateur enverra une demande de publication contenant les informations suivantes.

response.addHeader("x-frame-options","SAMEORIGIN");

CSP a actuellement deux versions, CSP1 et CSP2. L'état de support des deux versions peut être trouvé sur http://caniuse.com/#search=csp comme suit :

.

Support CSP1

Support CSP2

Bien que CSP offre une protection de sécurité puissante, il entraîne également les problèmes suivants : l'évaluation et les fonctions associées sont désactivées, le code JavaScript intégré ne sera pas exécuté et les scripts distants ne peuvent être chargés que via la liste blanche.

Options X-Frame

L'en-tête de réponse

X-Frame-Options est une balise utilisée pour indiquer au navigateur si une page peut être affichée dans des balises telles que frame, iframe 或者 object. Les sites Web peuvent utiliser cette fonction pour garantir que le contenu de leur propre site Web n'est pas intégré dans celui d'autres personnes. Cela évite également les attaques de détournement de clics. Mais il pourrait être remplacé par des ancêtres de trame CSP à l'avenir. L'état actuel du support est meilleur que celui des ancêtres du cadre CSP.

X-Frame-Options a trois valeurs :

DENY signifie que cette page ne peut pas être chargée dans le cadre
SAMEORIGIN signifie que cette page ne peut être chargée que par des pages provenant de la même source
ALLOW-FROM uri indique que cette page ne peut être chargée que par un domaine spécifique

Configuration du serveur

code Java :

addheader X-Frame-Options SAMEORIGIN

Configuration Nginx :

Header always append X-Frame-Options SAMEORIGIN

Configuration Apache :

Compatibilité des navigateurs

Caractéristiques	Chrome	Firefox (Gecko)	Internet Explorer	Opéra	Safari
Support de base	4.1.249.1042	3.6.9 (1.9.2.9)	8.0	10.5	4.0
Support AUTORISER	Non pris en charge	18.0	8.0?	?	Non pris en charge

Http uniquement

Après avoir utilisé http uniquement, il peut être interdit à js de lire et d'écrire des cookies, ce qui garantit que même si xss se produit, les cookies de l'utilisateur sont en sécurité.

environnement sandbox iframe

HTML5 fournit l'attribut de sécurité sandbox pour iframe, limitant ainsi les capacités d'iframe comme suit :

application/ecmascript  
application/javascript  
application/x-javascript  
text/ecmascript  
text/javascript  
text/jscript  
text/x-javascript  
text/vbs  
text/vbscript

Autres en-têtes HTTP liés à la sécurité

Options de type de contenu X

X-Content-Type-Options empêche le navigateur de renifler le type de contenu, ce qui peut empêcher les attaques par reniflage de type.

Cet en-tête est principalement utilisé pour empêcher les attaques de confusion de type MIME dans IE9, Chrome et Safari. Habituellement, le navigateur peut déterminer de quel type il s'agit en reniflant le contenu lui-même, plutôt qu'en examinant la valeur du type de contenu dans la réponse. -Content-Type-Options : si le type de contenu correspond au type attendu, aucun reniflage n'est requis et seules les ressources d'un certain type peuvent être chargées de l'extérieur. Par exemple, si une feuille de style est chargée, alors le type MIME peut. être uniquement du texte/css. Pour les ressources de script dans IE, les types de contenu suivants sont valides :

text/javascript  
text/ecmascript  
application/javascript  
application/ecmascript  
application/x-javascript  
text/javascript1.1  
text/javascript1.2  
text/javascript1.3  
text/jscript  
text/live script

Pour Chrome, les types MIME suivants sont pris en charge :

nosniff – 这个是唯一正确的设置.

Paramètres corrects

‘nosniff’ – 引号是不允许的
: nosniff – 冒号也是错误的

Paramètres souvent incorrects

Public-Key-Pins: pin-sha256="base64=="; max-age=expireTime [; includeSubdomains][; report-uri="reportURI"]

Comment détecter

Ouvrez les outils de développement dans IE et Chrome et observez la différence de sortie entre nosniff configuré et aucun nosniff configuré dans la console.

HPKP (épinglage de clé publique)

HPKP est un en-tête de réponse, utilisé pour détecter si la clé publique d'un certificat a changé afin d'empêcher les attaques de l'homme du milieu.

Nous savons qu'il existe des centaines d'autorités de certification (autorités de certification) de confiance et qu'elles sont devenues une surface d'attaque importante dans l'ensemble du processus d'authentification de l'identité du site Web. Le plus gros problème avec le mécanisme de chaîne de confiance des certificats existant est que n'importe qui peut faire confiance à toutes les autorités de certification. délivrez des certificats de site pour n'importe quel site Web, et ces certificats sont légaux aux yeux des navigateurs.

La technologie HPKP nous donne le droit de choisir de manière proactive de faire confiance à l'autorité de certification. Son principe de fonctionnement est d'indiquer au navigateur l'empreinte digitale du certificat du site Web actuel via l'en-tête de réponse ou la balise À l'avenir, le navigateur accédant à ce site Web devra vérifier l'empreinte digitale du certificat dans la chaîne de certificat. Si elle ne correspond pas à la valeur spécifiée précédemment, même si le certificat lui-même est légitime, la connexion doit être déconnectée.

Le document officiel HPKP se trouve dans la RFC7469, qui est actuellement prise en charge par Firefox 35+ et Chrome 38+. Son format de base est le suivant :

.

function xssCheck(str,reg){
  return str ? str.replace(reg || /[&<">'](?:(amp|lt|quot|gt|#39|nbsp|#\d+);)?/g, function (a, b) {
    if(b){
      return a;
    }else{
      return {
        '<':'<',
        '&':'&',
        '"':'"',
        '>':'>',
        "'":''',
      }[a]
    }
  }) : '';
}

HSTS (HTTP Strict-Transport-Security)

HSTS est un nouveau protocole de sécurité Web promu par l'Organisation internationale d'ingénierie Internet IETE, qui peut être utilisé pour résister aux attaques de l'homme du milieu. Il oblige le navigateur à utiliser TSL comme canal de données, c'est-à-dire qu'il force le navigateur à utiliser TSL comme canal de données. l'utilisation de HTTPS pour créer une connexion avec le serveur.

La façon pour le serveur d'activer HSTS est que lorsque le client fait une demande via HTTPS, le champ Strict-Transport-Security est inclus dans l'en-tête de réponse Hypertext Transfer Protocol renvoyé par le serveur. Le champ HSTS défini lors d'une transmission non cryptée. n'est pas valide.

Par exemple, l'en-tête de réponse de https://xxx contient Strict-Transport-Security : max-age=31536000 ; includeSubDomains :

L'année suivante (soit 3 153 6000 secondes), chaque fois que le navigateur envoie une requête HTTP à xxx ou à son nom de sous-domaine, il doit utiliser HTTPS pour initier la connexion. Par exemple, l'utilisateur clique sur un lien hypertexte ou saisit http://. dans la barre d'adresse. xxx/, le navigateur devrait automatiquement convertir http en https, puis envoyer la demande directement à https://xxx/.

L'année suivante, si le certificat TLS envoyé par le serveur xxx n'est pas valide, l'utilisateur ne peut pas ignorer l'avertissement du navigateur et continuer à visiter le site Web.

L'inconvénient est que la première visite de l'utilisateur sur le site Web n'est pas protégée par HSTS. En effet, le HSTS n'a pas été reçu pour la première fois. La première consiste à prédéfinir la liste des noms de domaine HSTS dans le navigateur. qui est implémenté par Google Chrome, Firefox et Internet Explorer. La seconde solution consiste à ajouter des informations HSTS à l'enregistrement du système de noms de domaine.

.

Filtrage XSS frontal

Enfin, nous proposons une méthode de filtrage XSS frontale

rrreee

Vous pouvez lire directement le texte original de mon blog pour une meilleure expérience. Une brève discussion sur l'attaque et la défense XSS

曾经蜡笔没有小新 · Answer

Quel langage est utilisé pour implémenter le côté serveur ? Il s'agit de remplacer les chaînes liées au

PHP中文网 · Answer

-.- Cela doit être traité par le backend. Il semble que ce soit la fonction htmlspecialchars dans le frontend si elle est écrite en js. Il est préférable de le mettre entre guillemets. Empêcher l'exécution du code js.

De plus, lors du passage des paramètres, vous devez être tolérant aux pannes et donner une valeur par défaut.

PHPz · Answer

La vulnérabilité XSS est en fait que le backend est injecté ou piraté, et le frontend fait exécuter le code malveillant.

La clé reste le problème du back-end. Le front-end peut effectuer un travail limité.

N'évaluez pas les choses avec désinvolture, surtout lorsque vous utilisez jsonp sur plusieurs domaines.
Filtrez et ajustez les balises pour les entrées de l'utilisateur. Bien sûr, il est préférable de filtrer ce backend deux fois.
Vérifiez les données demandées pour éviter toute falsification.
Si vous pouvez utiliser https, utilisez-le. Cela garantit essentiellement que les données ne seront pas falsifiées.