Cross-site cooking
Le cross-site cooking est un type d'exploit permettant à un site Web attaquant de donner au navigateur Web de l'internaute victime un cookie qui sera envoyé au site Web cible de l'attaque. Le nom et le concept ont été présentés par Michal Zalewski en 2006. Les failles de sécurité exploitées résident tant dans les navigateurs Web que dans les spécifications des cookies. Cet exploit permet notamment l'usurpation d'identité par fixation de session.
Origine
Le nom et le concept de cross-site cooking ont été présentés par Michal Zalewski en 2006[1]. Le nom est un mélange entre cookie et cross-site, afin d'exprimer la manipulation des cookies entre sites Web. Dans son article de 2006, Michal Zalewski présente trois faille, et attribue la découverte de la plus ancienne à Benjamin Franz.
Failles de sécurité
Trois failles sont documentées dans l'article.
Sous-domaines publics
Cette attaque consiste Ă Ă©mettre un cookie pour un domaine parent qui est public, et donc partagĂ© avec d'autres sous-domaines appartenant Ă des tiers, qui peuvent ĂȘtre attaquĂ©s par ce cookie malicieusement injectĂ©. La faille vient du fait qu'il n'existe pas d'algorithme permettant aux navigateurs Web de reconnaitre tous les domaines publics ; ils doivent donc se baser sur une heuristique ou une liste compilĂ©e manuellement.
Tous les domaines de premier niveau génériques et nationaux sont publics. Aux niveaux supérieurs la situation est en revanche plus compliquée. Ainsi, un domaine comme .uk
contient de nombreux sous-domaines publics : ac.uk
, co.uk
, org.uk
, etc. La spécification originale des cookies prévoyait que les cookies n'étaient pas valables pour les domaines génériques .com
, .edu
, .net
, .org
, .gov
, .mil
, et .int
, ni pour les domaines de premier niveau national et leurs sous-domaines directs[2]. Cela aurait réglé le cas des sous-domaines publics comme co.uk
, mais pas des sous-domaines comme wa.edu.au
. En outre, cela aurait gĂȘnĂ© tous les pays permettant d'avoir un domaine privĂ© directement sous le domaine de premier niveau, comme wikipedia.fr
. En consĂ©quence, les navigateurs ont mis en Ćuvre des heuristiques au lieu d'appliquer Ă la lettre la rĂšgle simpliste de la spĂ©cification originale. Par exemple Internet Explorer considĂ©rait publics tous les domaines de la forme xx.yy[3] - [4].
Ces spécifications inapplicables et leur application confuse ont eu pour résultat des sous-domaines publics (comme com.fr
) qui n'étaient pas identifiés comme tels par un ou plusieurs navigateurs. Afin de pallier cette faille, une liste de domaines publics est maintenue par le projet Mozilla à http://publicsuffix.org/[5].
Point final de domaine
Il s'agit de la faille découverte par Benjamin Franz en 1998. Dans le Domain Name System, un nom de domaine complÚtement qualifié se termine par un point représentant la racine. Ainsi, fr.wikipedia.org.
avec point final est une notation techniquement moins ambigĂŒe que fr.wikipedia.org
sans point final. Mais il n'est pas d'usage d'utiliser le point final dans le monde du World Wide Web (URL, HTTP, cookie). La faille exploitable de certains navigateurs Web étaient d'accepter les cookies sur tous les domaines de premier niveau, pourvu qu'ils soient notés avec le point final, comme dans .com.
(Ă©quivalent Ă .com
). Cette faille vient d'un cĂŽtĂ© de la spĂ©cification initiale des cookies, qui spĂ©cifiait seulement le nombre de points qu'un domaine devait contenir pour ĂȘtre considĂ©rĂ© comme privĂ© ; et de l'autre de la façon dont les navigateurs rĂ©solvent les noms de domaine.
Fausse résolution de nom
Cette attaque repose sur un site Web dans un quelconque domaine (example.com
) qui devra attirer des internautes victimes, et d'un second domaine apparenté (fake.example.com
) avec un enregistrement DNS frauduleux pointant l'adresse IP du site attaqué. En suivant les liens vers fake.example.com
, le navigateur Web de la victime envoie au site attaqué les cookies émis par example.com
. Or rien dans l'en-tĂȘte HTTP Cookie
n'indique Ă quel domaine le cookie appartient. Ce n'est qu'en consultant Ă©ventuellement d'autres en-tĂȘtes HTTP, comme Host
, que le site attaquĂ© peut se rendre compte qu'il reçoit un cookie d'une requĂȘte qui lui a Ă©tĂ© frauduleusement adressĂ©e.
Références
- (en) Browsers face triple threat, Matthew Broersma, Techworld, 31 janvier 2006
- (en) Persistent Client State HTTP Cookies - Preliminary Specification
- (en) Internet Explorer Cookie Internals (FAQ), IEInternals, Eric Law, 20 août 2009
- (en) Understanding Domain Names in Internet Explorer, IEInternals, Eric Law, 18 septembre 2009
- (en) RFC 6265, chap. 5.3.5
Bibliographie
- (en) Cross-Site Cooking article de Michal Zalewski sur les détails du principe, trois défauts qui permettent le cross-site cooking.
- (en) HTTP cookies, or how not to design protocols, lcamtuf's blog, de Michal Zalewski, .
- (en) Browser Security Handbook, part 2, chap. Same-origin policy for cookies, Michal Zalewski, Copyright 2008, 2009 Google Inc.