Résumé

  • L’en-tête X-Frame-Options: SAMEORIGIN permettait à une page de refuser l’encadrement par un site étranger. Le RFC de 2013 décrit une faiblesse des navigateurs qui ne comparaient la page protégée qu’avec la fenêtre tout en haut.
  • Une page A accueille une page B, qui encadre à son tour une page protégée de A. Une vérification limitée aux deux extrémités voit A face à A et oublie B. La directive frame-ancestors du W3C impose en 2016 l’examen de chaque parent.

La fenêtre rouge au milieu

Une page d’un site A ouvre un cadre contenant une page du site B. B tente ensuite d’afficher dans son propre cadre une page sensible de A. Cette dernière envoie X-Frame-Options: SAMEORIGIN : elle demande au navigateur de n’autoriser que l’encadrement par son origine. Si le logiciel compare seulement la page sensible avec la page tout en haut, le contrôle passe. Les deux sont sur A. La page de B se trouve pourtant juste entre elles, à l’endroit où elle peut manipuler la présentation.

Ce montage figure dans le RFC 7034 publié en octobre 2013. Le document, de catégorie Informational, consignait le comportement des navigateurs de l’époque. Il expliquait la menace du détournement de clic : des couches visuelles peuvent conduire une personne à actionner un bouton d’une autre page. Son exemple de confirmation d’achat sert à illustrer une défense. La chaîne A/B/A décrit un mécanisme possible, sans attribuer une attaque à une boutique réelle.

Une règle simple, un contrôle trop court

Le serveur de la page à protéger envoyait l’en-tête. DENY interdisait tout cadre; SAMEORIGIN gardait ceux de la même origine; ALLOW-FROM désignait une origine autorisée. Le navigateur était chargé de faire respecter cette décision. Le partage des rôles paraît net jusqu’au moment où plusieurs sites s’emboîtent. Qui compte comme « même origine » lorsque la première page est amie et la page intermédiaire ne l’est pas ?

Le RFC indiquait que les mises en œuvre variaient. Plusieurs navigateurs comparaient l’origine de la page protégée avec celle de la page supérieure et ne parcouraient pas tous les cadres parents. La politique du propriétaire existait bien. Le logiciel posait une question incomplète. Le problème se trouvait dans la traversée de l’arbre des pages, pas dans la typographie du nom SAMEORIGIN.

Le niveau supérieur n’est qu’une extrémité. Un autre exploitant peut contrôler le cadre immédiatement autour du contenu protégé. Ignorer ce parent revient à autoriser une chaîne parce que ses deux bouts portent la même couleur.

Le W3C fait regarder chaque parent

La recommandation Content Security Policy Level 2 du 15 décembre 2016 définit frame-ancestors autrement. Avant de charger la ressource dans un cadre, le navigateur construit la liste de tous les contextes qui l’entourent. Il confronte chaque URL à la liste des origines autorisées. Un seul parent refusé arrête le chargement. Dans la chaîne A/B/A, B échoue même si le sommet A correspond.

Le W3C compare explicitement cette méthode au contrôle limité au sommet que pratiquaient de nombreuses implémentations de X-Frame-Options. Le texte dit que frame-ancestors remplace cet en-tête et devrait l’emporter lorsque les deux politiques sont envoyées. Il permet aussi plusieurs origines autorisées là où ALLOW-FROM n’en admettait qu’une. La réparation principale tient à la question posée : examiner le chemin complet.

Il fallait également livrer la règle au bon endroit. Le RFC précise que X-Frame-Options placé dans une balise meta http-equiv était ignoré. Le W3C refuse lui aussi frame-ancestors dans une politique portée par une balise meta. Un default-src 'none' général ne crée pas automatiquement l’interdiction d’encadrement. Le propriétaire doit envoyer l’instruction que le navigateur saura appliquer.

La page A peut déclarer sa frontière. Seul le navigateur voit la totalité de la pile de cadres chez le visiteur. La valeur d’une frontière écrite dépend donc de la profondeur du contrôle réellement exécuté.