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[modifier | modifier le code]
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é[modifier | modifier le code]
Trois failles sont documentées dans l'article.
Sous-domaines publics[modifier | modifier le code]
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[modifier | modifier le code]
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[modifier | modifier le code]
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[modifier | modifier le code]
- (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[modifier | modifier le code]
- (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.
