web-dev-qa-db-ja.com

allowscriptaccess = same domainを使用してWebアプリのFlashファイルをペンテストする方法は？

ペンテストの最中に、loadMovieを介して別のFlashムービーをロードするFlashムービーファイル（swf）を見つけました。 HTMLは次のとおりです。

<embed width="388" height="350" src="http://www.domain.com/first_flash.swf?
videoload=http://www.domain.com/videos/second_flash" quality="high" 
pluginspage="http://www.macromedia.com/go/getflashplayer" align="middle" 
play="true" loop="true" scale="showall" wmode="window" devicefont="false" 
bgcolor="#ffffff" name="interior" menu="true" allowfullscreen="false" 
allowscriptaccess="sameDomain" salign="" type="application/x-shockwave-flash">

ご覧のとおり、directive allowscriptaccess="sameDomain"。また、Flashファイルに直接アクセスする場合、最近のFlashプラグインがこの設定をデフォルトとして使用していることを理解しています。

First_flash.swfで、2番目のムービーをロードする次のコードを見つけました。

_root.videourl = _root.videoload + '.swf';
video.loadMovie(_root.videourl);

私は実際にビデオロード変数を変更して他のドメインからswfをロードできることをテストしました。しかし、私が制御しているsecond_flash.swfでgetURLを使用してJavaScriptを実行できないようです。

だから私の質問は、この貧弱なデザインを利用するために私は何ができるでしょうか？それが実際に危険であることをどのように示すことができますか？

web-applicationpenetration-testflash
8
chmeee

元のソース- http://my.safaribooksonline.com/book/networking/security/9780596806309/inside-out-attacks-the-attacker-is-the-insider/content_ownership

2.4.1。 Flashのcrossdomain.xmlの悪用

多くの場合、同じOriginポリシーは制限が厳しすぎると見なされ、アプリケーション開発者は2つの異なるドメインが相互に対話的に機能する能力を要求します。このようなクロスドメインの相互作用をサポートする最初の人気のあるブラウザプラグインの1つは、AdobeのFlashでした。アドビは、任意のクロスドメインアクセスを許可することの危険性を理解し、Flashがクロスドメインの相互作用を許可するかどうかを決定するセキュリティ対策を実装しました。このセキュリティ対策は、クロスドメインポリシーファイルを介して実装されます。

Flashのクロスドメインポリシーファイルは、クロスドメインインタラクションの「ルール」を定義します。クロスドメインポリシーファイルは、単にcrossdomain.xmlという名前のXMLファイルです。次に、crossdomain.xmlファイルの例を示します。

_<?xml version="1.0" encoding="UTF-8" ?>

<cross-domain-policy
    xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
    xsi:noNamespaceSchemaLocation=
    "http://www.Adobe.com/xml/schemas/PolicyFile.xsd">

    <allow-access-from domain="*" /> </cross-domain-policy>
_

このcrossdomain.xmlポリシーファイルは、クロスドメインの相互作用を許可するサーバーでホストする必要があります。 Flashは、クロスドメインインタラクションを許可する前に、ターゲットドメインにクロスドメインポリシーファイルが存在するかどうかを確認します。ポリシーファイルが存在しない場合、Flashはデフォルトで同じ制限のあるOr​​iginポリシーを使用し、クロスドメインの相互作用を禁止します。ターゲットドメインにcrossdomain.xmlファイルが存在する場合、Flashはポリシーファイルに含まれる「ルール」を読み取り、確立されたルールに基づいてクロスドメインの相互作用を許可します。繰り返しになりますが、前提は、クロスドメインポリシーファイルは、クロスドメインの相互作用を許可したいドメインから提供する必要があるという事実に基づいています。デフォルトでは、Flashは、WebアプリケーションのWebルート（http://www.example.com/crossdomain.xml）にcrossdomain.xmlという名前のクロスドメインポリシーファイルが存在するかどうかを確認します。

Flash 7以降では、FlashコンポーネントがURLをパラメーターとして使用してloadPolicyFile()を呼び出すときに、Webドメインのルートだけでなく、任意の場所でcrossdomain.xmlのFlashチェックを実行できます（場所を含むターゲットサーバー上のcrossdomain.xml）。

[〜＃〜]ノート[〜＃〜]

System.Security.loadPolicyFile()の詳細については、次のWebサイトを参照してください。

http://livedocs.Adobe.com/flash/mx2004/main_7_2/wwhelp/wwhimpl/common/html/wwhelp.htm?context=Flash_MX_2004&file=00001098.html

Flashのクロスドメインポリシーの概念は、いくつかの単純な前提に基づいています。ロジックの簡略版は次のとおりです。

Flashからそのサーバーへのクロスドメインアクセスを可能にするには、クロスドメインポリシーファイルをWebサーバーのWebアクセス可能なパスに配置する必要があります。

誰かがWebサーバーのWebアクセス可能なパスに任意のファイルを置くことができる唯一の方法は、Webサーバーへの管理アクセス権がある場合です。

したがって、WebサーバーのWebアクセス可能なパスにクロスドメインポリシーファイルがある場合、管理者がそこに配置する必要があります。

多くのWebアプリケーションでは、ユーザーがコンテンツをWebサーバーにアップロードできるため、このロジックには本質的に欠陥があります。その後、アプリケーションがそのコンテンツをドメイン名で提供する場合、そのWebアプリケーションは、Flashのクロスドメイン機能により、無意識のうちに自身を危険にさらしています。攻撃者がcrossdomain.xmlポリシーファイルをアップロードできる場合、攻撃者はWebサーバー上の悪質なFlashアプレットを使用して脆弱なアプリケーションを攻撃できます。この邪悪なFlashアプレットは、脆弱なWebアプリケーションに対してクロスドメインリクエストを行うことができ、これらのリクエストは、攻撃者のWebサイトに偶然遭遇した不幸なユーザーのセッションCookieを使用して行われます。さらに悪いことに、クロスドメインポリシーファイルに.xml拡張子を付ける必要はありません。 Flashのセキュリティ基準は、すべてのファイル拡張子を尊重します。

[〜＃〜]ノート[〜＃〜]

Adobe Flash 9.0.115.0では、「メタポリシー」を指定できます。これらのポリシーは、サーバー上のどのポリシーファイルを優先するかを定義します。 http://www.Adobe.com/devnet/flashplayer/articles/fplayer9_security_03.html でメタポリシーの詳細を確認できます。

5
atdre

ここでのすべては、Flash Playerのバージョンによって異なります。これは、この.swfファイルで試すべきもののリストです。

最初の推測はCross Site Scriptingだったので、XSSを試してみる必要があります。特に、危険なメソッドの1つであるloadMovieに気づきました。 。

クロスサイトスクリプティング

安全でない関数にはいくつかの種類があります。それぞれに異なるペイロードがあります：

  • getURL-ペイロード：javascript:alert('XSS')
  • _load*_（この場合：loadMovie）-ペイロード：asfunction:getURL,javascript:alert('XSS') [asfunctionは、Flash Player 9がリリースされるまで、このコンテキストで機能しますr48]
  • TextField.htmlText-ペイロード：<img src='javascript:alert("XSS")//.swf'> [ここでは.swfが非常に重要です-他の拡張機能はFlash Playerの内部フィルターをバイパスしません]。

クロスサイトフラッシング

2番目の推測は[〜＃〜] xsf [〜＃〜]になります。最初のフラッシュムービーは、2番目のフラッシュムービーをロードしようとします。サンドボックスの同じ部分にアクセスできるようになると、XSFに対して脆弱になります。これは、外部の邪悪なフラッシュファイルをロードできることを意味します。これにより、XSSまたは偽のフラッシュムービー（偽のフラッシュフォーム、フィッシングの一種など）につながる可能性があります。さて、その欠陥がいつ得られるかしばらく考えてみましょう。

Flash Player 7以降では、同じドメイン間のクロスドメインスクリプティングのみが許可されています。異なるドメインから.swfファイルをロードできますが、そのファイルはデータを交換できません。詳細については、_System.security.allowDomain_を確認してください。

それでは話しましょう：

AllowScriptAccess

このパラメーターはparamまたはembedタグ内にあり、SWFファイル内からアウトバウンドURLアクセスを実行する機能を決定します。可能な値は3つあります。-sameDomain：.swfファイルと埋め込みHTMLページが同じドメインにある場合、通信へのアクセスが許可されます。 -always：sameDomainと同じですが、.swfファイルは異なるドメインの.swfと通信することもできます（埋め込まれているドメインとは異なります）。 -never-.swfファイルはどのページとも通信できません。アプリケーション層プロトコル、ドメイン名、およびポート番号は、オリジンを定義します。 .swfファイルがブラウザから実行するJavaScriptコードを取得すると、埋め込みWebサイトのOrigin内で実行されます。 2つの状況を考えてみましょう[_allowScriptAccess = sameDomain_]：

  • A.comでホストされている.swfは、B.comのHTML Webサイトに埋め込まれています：_Origin: B.com_
  • B.comには、A.comから.swfファイルをロードするiframeがあります：_Origin: A.com_

デフォルト値はsameDomainに設定されています。つまり、AllowScriptAccess属性のない.swfは、sameDomainプロパティのある.swfと見なす必要があります。 2008年には、sameDomainがCross Site Request Forgeryにつながる可能性があることに気付きました。これに関するブログ投稿（ 詳細-ここ ）を読んで PoC を確認することをお勧めします。

フラッシュパラメータ汚染を忘れないでください。

フラッシュパラメータ汚染

すべての.swfファイルが元のHTMLなしでロードできるわけではありません。プログラマがサニタイズを忘れた場合は、グローバル変数をフラッシュに注入できます。

print '<object type= (...) data="'.$_GET['flash'].'"></object>'

_URI: http://example.com/?flash=flash.swf?var=bum_

HTML: <object type= (...) data="flash=flash.swf?var=bum"></object>

4
p____h