XSS nom chinois est appelé cross-site scripting, la vulnérabilité WEB est la forme la plus commune, fonction est le malveillant code HTML / JavaScript dans le navigateur web de la victime, de manière à atteindre les sessions afin de détournement des utilisateurs. Le mode de transfert XSS script malveillant peut être divisé en trois types, à savoir un type de réflexion, de type magasin, type DOM, passe par les deux premiers script malveillant retourne alors le serveur au client, le modèle DOM est relativement meilleure détection et à la prévention, le modèle DOM sans script malveillant est transféré sur le serveur retourné au client, qui est la différence entre les DOM et de réflexion, le type de stockage, donc je suis ici pour parler d'un seul type DOM XSS.
DOM document
Pour mieux comprendre le type DOM XSS, premier regard sur DOM, après tout, est un type XSS basé DOM-modèle d'objet DOM document. Pour les navigateurs, document DOM est un document XML, lorsque cette technologie standard, grâce à JavaScript, vous pouvez facilement y accéder.
Voici des exemples d'une structure d'arborescence DOM est converti en code HTML:
<html>
<head>
<meta charset="gbk" />
<title> TEST </title>
</head>
<body>
<p>The is p.<p>
<h1>Product:</h1>
<ul>
<li>Apple</li>
<li>Pear</li>
<li>Corn</li>
</ul>
</body>
</html>
converti figure au modèle est la suivante:
L'avantage est que, par cette simple structure d'arbre, la relation entre les éléments seront en mesure d'effacer aussi simple que cela out et pratique de script JavaScript côté client en examinant et en modifiant DOM contenu de la page dynamique, indépendante du côté serveur de données.
En utilisant le principe de
JavaScript peut accéder à l'objet DOM Document navigateur modèle côté client est l'utilisation de la prémisse, lorsque le code client de confirmation est de type de vulnérabilité DOM XSS, et peut induire (la pêche) ont construit une URL d'accès utilisateur, il peut être expliqué victimes côté client d'injection de scripts malveillants. Et l'étape d'utilisation du type de réflexion est très similaire, mais la seule différence est, des paramètres d'URL configurés non envoyés au serveur peuvent être obtenus sans passer par le WAF, Evade les résultats de la détection du serveur.
Afin de faciliter la compréhension, ici je vous donne quelques scénarios à comprendre.
Scène un: innerHTML
<html>
<head>
<title> DOM-XSS TEST </title>
<style>
#box{width:250px;height:200px;border:1px solid #e5e5e5;background:#f1f1f1;}
</style>
</head>
<body>
<script>
window.onload= function(){
var oBox=document.getElementById("box");
var oSpan=document.getElementById("span1");
var oText=document.getElementById("text1");
var oBtn=document.getElementById("Btn");
oBtn.onclick = function(){
oBox.innerHTML = oBox.innerHTML + oSpan.innerHTML + oText.value + "<br/>";
// oBox.innerHTML += oSpan.innerHTML + oText.value + "<br/>";//这是简便的写法，在js中 a=a+b ,那么也等同于 a+=b
oText.value=""
};
}
</script>
<div id="box"></div>
<span id="span1">小明：</span>
<input type="text" id="text1"/>
<input id="Btn" type="button" value="发送消息" name=""/>
</body>
</html>
La première était une visite normale:
hellow
Le deuxième paramètre est le code JavaScript est écrit comme valeur:
<svg/onload=alert(1)>
Ici, je n'utilise que le succès de Firefox, l'échec dans l'utilisation du chrome, chrome Je suppose que pour la sécurité sont en train de faire mieux, ne pas poursuivre ici chaque numéro de version du navigateur.
Utilisez innerHTML, à l'attention de outerHTML, l'étiquette processus n'a pas besoin d'encoder, pourrait conduire à XSS. La protection est de remplacer innerText, il analysera automatiquement les balises HTML sous forme de texte, de sorte que les balises HTML ne seront pas exécutées, pour éviter les attaques XSS.
oBox.innerText = oBox.innerHTML + oSpan.innerHTML + oText.value + "<br/>";
Scène 2: Jump
<html>
<head>
<title> DOM-XSS TEST </title>
</head>
<body>
<script>
var hash = location.hash;
if(hash){
var url = hash.substring(1);
location.href = url;
}
</script>
</body>
</html>
L' accès est normalement utilisé #pour réaliser le saut de page, sauter , mais parce que certains des paramètres contrôlés, pourrait conduire à Dom XSS.
Location.hash par la manière, les paramètres écrits après la #, à la fois pour permettre JS lire les paramètres, mais aussi pour empêcher le paramètre passé au serveur, évitant ainsi la détection WAF.
Comme une partie de hachage de variable contrôlable, et dans l'URL, la partie variable de hachage après que le contrôle est #, pseudo-protocole peut être utilisé #javascript: alerte (1). Il y a plusieurs pseudo-protocole commun javascript:, vbscript:, data:et ainsi de suite. Et maintenant , le terminal mobile (Android et iOS), peut personnaliser cet accord pour ouvrir une application locale à partir du navigateur, vous pouvez regarder spécifique https://www.cnblogs.com/WuXiaolong/p/8735226.html
#javascript:alert(1)
Troisième scène: eval
#';alert(1);//
Directement raccordées à l'aide du code de données d'entrée d'utilisateur.
eval("var x = '" + location.hash + "'");
Quatrième scène: biscuits, referrer
Extraire les données de localStorage, SessionStorage, cookies source magasin, ces valeurs sont souvent ignorées par les développeurs, que ces valeurs sont acquises dans un navigateur qui est sûr, il n'est pas traitée.
var cookies = document.cookie;
document.write(cookies);
场景 五: document.write, document.URL.indexOf ( "id =")
var ids = document.URL;
document.writeln(ids.substring(ids.indexOf("id=")+3,ids.length));
indexOf get intérieur du paramètre url, puis sortie au format HTML en fonction writeln () ou write (), ce qui XSS, mais je maintenant (2020,3) en chrome et de test firefox navigateur, écriture () est difficile à utiliser, à moins que combiné avec certaines scènes spéciales .
politique de protection
Il y a quelques défauts réguliers des allumettes, des défauts de type logique métier, avec le côté mobile sauts, etc., en utilisant le cadre tiers frontal (comme la boîte d'édition multimédia) et d'autres scènes n'expliquait un par un (l'énergie est limitée ...), post-libre nous pouvons continuer à remplir ces scènes.
Le processus de détection est de savoir s'il document.write, eval, fenêtre comme lieu qui peut causer des dommages en regardant le code, puis à travers les variables de processus d'appel et les fonctions, voir si l'utilisateur peut contrôler l'entrée. Si vous pouvez contrôler l'entrée, l'examiner pour voir si elle peut réviser montre la présence de DOM XSS, besoin de coder les données d'entrée.
Vérification des points caractéristiques du code (y compris mais sans s'y limiter):
var elements = location.hash;
elements.indexOf
var oBtn=document.getElementById("Btn");
oBtn.innerHTML
oBtn.outerHTML
document.createElement
oBtn.setAttribute
oBtn.appendChild
document.write
document.writeln
eval("var x = '" + location.hash + "'");
setTimeout("alert('xss')", 1000)
window.setTimeout
document.setTimeout
window.setInterval
document.execCommand('ForeColor',false,'#BBDDCC');
document.createElement
document.createElementNS
document.createEvent
document.createXxx
syntaxe js est très flexible, mais aussi de nombreuses fonctions de bibliothèque, listées ici ne peut pas complètement plein, je ressens le besoin d'avoir une certaine connaissance du système de grammaire, vous pouvez trouver toutes ces fonctionnalités supplémentaires.
Lorsque le besoin de l'entreprise pour obtenir les données saisies par l'utilisateur en html, il faudrait essayer d'utiliser une méthode sécurisée, comme innerText (), testContent () et ainsi de suite. Essayez d'utiliser le haut-fonction-cadre de sécurité lors de l'utilisation des cadres.
Documents de référence
"XSS Cross Site Scripting - attaque et analyse de la défense"
"Web Vulnerability Protection"
https://xz.aliyun.com/t/5181
https://domgo.at/cxss/example
https://www.secpulse.com/ archives / 92286.html