AccueilđŸ‡«đŸ‡·Chercher

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.

cross-side cooking

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

  1. (en) Browsers face triple threat, Matthew Broersma, Techworld, 31 janvier 2006
  2. (en) Persistent Client State HTTP Cookies - Preliminary Specification
  3. (en) Internet Explorer Cookie Internals (FAQ), IEInternals, Eric Law, 20 août 2009
  4. (en) Understanding Domain Names in Internet Explorer, IEInternals, Eric Law, 18 septembre 2009
  5. (en) RFC 6265, chap. 5.3.5

Bibliographie

Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplĂ©mentaires peuvent s’appliquer aux fichiers multimĂ©dias.