web-dev-qa-db-ja.com

CookieベースのXSSは悪用可能ですか?

今日、あなたのCookie値をページに直接出力する興味深いサイトを見つけました。Cookie値を変更すれば、自分でXSSを実行できます。

例:<span id=statistics>Last visit: Cookie_Value_Of_Something</span>

だから私の質問は、これは脆弱であると思いますか、それとも私はこれを悪用できますか?

今のところ私には役に立たないようです。

5
daisy

この欠陥を悪用するには、攻撃者はユーザーのCookieを操作する必要があります。そして、これは、彼がXSSペイロードでCookieを設定できる別の脆弱性を悪用できる場合にのみ可能です ドメイン内のCookieを設定できるのはSet-Cookieの起源は

ユーザー属性は、ドメイン属性がオリジンサーバーを含むCookieのスコープを指定しない限り、Cookieを拒否します。たとえば、ユーザーエージェントは、foo.example.comのドメイン属性が「example.com」または「foo.example.com」のCookieを受け入れますが、ユーザーエージェントは、ドメイン属性のCookieを受け入れません。 「bar.example.com」または「baz.foo.example.com」。

そして、サーバーを危険にさらす以外に、Cookie値を操作するための2つの可能な攻撃ベクトルがあります。 cookie値。または、攻撃者はサブドメインにアクセスでき、Cookieの値を出力する脆弱なスクリプトが存在するスーパードメインにCookieを設定できます。 Cross-Site Request Forgery を使用して、両方のベクターを実行できます。

8
Gumbo

かつてフラッシュはCRLFインジェクションに対して脆弱でした (IEも脆弱でした)、これを使用してCookie: CookieベースのXSSを利用するためのHTTPリクエストヘッダー。しかし、これはもはやそうではありません。別のドメインにCookieを設定することはできません。他のドメインにCookieを設定できると、 セッションの固定 を防ぐことが非常に困難になります(不可能ではないにしても)。

3
rook

それ自体は悪用可能ではありませんが、攻撃者がCookieの固定から完全なXSSに移行するための潜在的なエスカレーションパスです。

特に:

  1. サイトが近隣ドメインのあるホスト名で実行されている場合、それらの近隣へのXSS攻撃は、Cookieが共有親ドメインに書き込まれ、サイトのXSS攻撃にエスカレートすることを意味します。例えば。 untrusted-uploads.example.comからexample.comが読み取るドメインtrusted-www.example.comでCookieを書き込むことができます。

  2. サイトがhttps://www.example.com/で実行されている場合でも、攻撃者はhttp://www.example.com/のサイトを偽装できます。そこから設定されたCookieはhttpsから読み取ることができます-httpsのスクリプトは、Cookieがsecureで作成されなかったことを検出しません。したがって、cookie-XSSはHTTPSを無効にします(厳密なトランスポートセキュリティによって失敗した場合を除きますが、それは完全な防御ではありません)。

スクリプト(サーバー側またはクライアント側のいずれか)がdomainpathsecureまたはhttponlyフラグがオンであることを検出することは、実際には不可能です(*)。 Cookieは期待される値と一致します。つまり、サイトの外部からのCookieの挿入を確実に検出することはできません。

(*:必要なフラグを使用して新しいCookieを設定することでCookieをオーバーライドしようとするハッキングが発生する可能性がありますが、攻撃者のスクリプトが同時に実行される可能性があるため、最終的には完全に信頼できません。)

3
bobince

無駄だ。同じ生成元のポリシーにより、Cookieと同様に、ページ上のテキストを他のサイトで読み取ることはできません。

is MITM攻撃を実行している攻撃者が読み取ることができますが、Cookieも読み取り可能です(接続がHTTPSでない場合)。

1
Manishearth

唯一の実際の攻撃ベクトルは、別の脆弱性がある状況に存在します。たとえば、いくつかのPHPコードなどの実行可能スクリプトをアップロードできた場合、そのスクリプトを使用してCookieを操作し、JavaScriptをユーザーセッションに挿入できます。通常のソーシャルエンジニアリングも実行する必要があります。ユーザーにアップロードされたスクリプトにアクセスしてもらいます。

0
Mark S.

出力されるCookieによって異なります。

一部のサイトでは、サードパーティのデータをCookieの値に書き込みます(Facebookのreg_ext_ref匿名ユーザー用のCookie、完全な参照元です)。一部のサイトは、ユーザーが入力した最後の検索クエリなどを保存していると信じることができます(また、最後のクエリをGET-paramsで偽造できる場合もあります)。そのため、そのようなcookieの少なくとも1つが出力されている場合は、これを利用してみてください。

あなたのケースが良い攻撃経路であると言っているのではなく、調査するだけの価値があります。

0
НЛО