csrf.md

CSRF

aka Cross-Site Request Forgery

Principe

• affecte toute ressource disponible directement
  • sans étape intermédiaire
    • avec authentification
      • usurpation de session
    • ou pas
      • redirection arbitraire

Principe

• le but est de rediriger un utilisateur vers une url

  • à l'insu de son plein gré

• pour qu'il clique tous les coups sont permis

Que peut on faire?

• exécuter des opérations avec les permissions d'un autre utilisateur
• clickjacking
• spam

Note:

• l'action avec privilège
  • urls connues (CMS, ...)
    • on espère que l'utilisateur est logué
• spam de commentaire
  • urls connues (CMS, ...)

Mode opératoire

Note:

• rappel ici mail, mais aussi
  • XSS
  • lien déguisé
  • url shortner

Différentes techniques

• Url ou formulaires forgés relayés via XSS

• redirection arbitraire via XSS

• Social engineering

  • initulé de lien malicieux
  • url shortner
  • le lien image déguisé

• Phishing

  • par mail par exemple
    • approche probabiliste

Différentes techniques

• Modficiation de l'overlay en css
  • likejacking ou +1jacking
    • Arrêtez de vous faire avoir sur Facebook !!!

a#malice {
  display: block;
  width: 100%;
  height: 100%;
  position: absolute;
  top: 0;
  bottom: 0;
  opacity: 0.001;
}

Note:

• XSS réfléchi ou stocké ca marche
  • ya toujours un con qui clique
• insolvable click jacking insolvable
  • aucun moyen de distinguer les like légitimes
    • ils proviennet tous d'un serveur externe à facebook
      • possibilité de blacklist pour des sites réputés frauduleux

CSRF stored - security low

url vulnérable

http://dv.wa/vulnerabilities/csrf/?password_new=password&password_conf=password&Change=Change

passage de paramètres via GET en injectant

<iframe
  src="javascript:window.location='http://dv.wa/vulnerabilities/csrf/?password_new=1337&password_conf=1337&Change=Change';"
  height="0" width="0" style="border:0;">
</iframe>

via POST avec en scriptant

<form action="http://dv.wa/vulnerabilities/csrf/admin.php" method="post" id="formid"
  onload="document.getElementById('formid').submit();">
  <input type="hidden" name="password_new" value="1337"/>
  <input type="hidden" name="password_conf" value="1337"/>
</form>

Note:

• analyser la requête de changement de mot de passe avec burp
• forger une url
• forger un form
  • injecter via XSS stored par exemple
• problème de l'action silencieuse et aveugle
  • on ne sait pas sur qui ca marche
  • si on a une liste des utilisateurs du site le brute force est un option

Se préserver

• Fausses Bonnes Idées
  • utiliser la méthode POST
  • vérifier le referer (ou n'importe quelle autre en-tête)
    • CSRF stored - security medium
• Double Submit Pattern
  • CSRF stored - security high

Synchronizer Token Pattern

Synchronizer Token Pattern

• token de session
  • jeton dans un formulaire OU dans l'url ET dans la session utilisateur
    • avec éventuellement une salaison propre à l'utilisateur comme l'IP par exemple
      • on préserve ainsi le token et on cache un manque d'entropie éventuel

<input type="hidden" name="csrftoken" value="KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt">

Synchronizer Token Pattern

• compliqué avec une utilisation massive de XMLHttpRequest
• possibilité de jetons malins via fixation de session via le referer ou de brute force
  • utiliser des nonces pourrait être une solution

Cookie-To-Header Token

• adapté à une utilisation massive de JS

• basé sur la Same Origin Policy

• A l'authentification le serveur envoie un cookie contenant un jeton aléatoire valable pendant toute la session de l'utilisateur

Set-Cookie: Csrf-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; expires=Thu, 23-Jul-2015 10:25:33 GMT; Max-Age=31449600; Path=/

Cookie-To-Header Token

• JavaScript lit le jeton et le renvoie dans un header HTTP spécifique à chaque requête

X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql

• Le serveur vérifie la validité du token

reCAPTCHA - Google

http://dvwa.com/vulnerabilities/captcha

• Security level: low
  • action configurée en 2 étapes
    • Etape 1
      • validation du captcha
    • Etape 2
      • exécution de l'action
  • en modifiant le paramètre step à 2 on bypass le captcha

reCAPTCHA - Google

• Security level: medium
  • action configurée en 3 étapes
    • Etape 1
      • validation du captcha
    • Etape 2
      • Confirmation de l'action
    • Etape 3
      • exécution de l'action
  • en modifiant le paramètre step à 2 et en ajoutant Change=Change on bypass le captcha

Se préserver

• Côté client
  • RequestPolicy protège mais peut empêcher certains sites de fonctionner
  • CsFire protège un peu en enlevant toute information d'authentification pour les requêtes cross-site
  • NoScript va prémunir des scripts en provenance de sites non sûrs
  • Self-Destructing Cookies permet de réduire la fenêtre d'attaque en supprimant les cookies dès qu'ils ne sont plus associé à un onglet actif