0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

DOM-based XSSについてまとめてみた!

Last updated at Posted at 2025-12-02

脆弱性についてまとめてみるぼっちアドベントカレンダーの三日目の記事です。バグバウンティやCTFへの応用がしやすいようなまとめ方をしています。またアドカレを追っていない人向けに過去記事からのコピペも一部含まれます。

XSSについて

まずはXSSについて簡単の説明ですがXSSとはCross-site Scriptingの略で悪意のあるスクリプトをWebサイトに注入する攻撃の一種です。

XSSは大きく分けて3つの種類があります。

  • Reflected XSS
  • Stored XSS
  • DOM-Base XSS

それぞれXSSの1種とはいえすこし攻撃方法が異なってくるため今回はそれぞれ分けてまとめていきたいと思います。

DOM-based XSSについて

DOM-based XSSでわかりやすいものは#のあとをそのままHTML内で利用している例です。

<div id="msg"></div>
<script>document.getElementById("msg").innerHTML = location.hash.substring(1);</script>

このようなHTMLがあったとします。1行目は単純なdivで二行目のScriptタグの中で1行目の内容をURLの#以降の文字列にするようなコードが書いてあります。

この場合http://example.com/#<svg/onload=alert(1)>など#以降にXSSのペイロードを挿入されたらそのまま実行されてしまいます。

このようにクライアントサイドでHTMLの組み立てを行っていることが特徴でサーバーサイドのXSS保護機能などが聞かないことがほとんどです。またサーバーサイドにログが残ることも殆どありません。

悪用方法について

これは基本的に他のXSSと同じように任意のスクリプトを実行できるためセッションハイジャックや情報漏洩などです。

DOM-based XSSの場合はほとんどの場合クライアントサイドで処理が完結されるため運営者に気づかれず攻撃することができてしまいます。

Webサイト側の対策について

まず基本的なXSSの対策で言えばエスケープ処理を施すことです。
エスケープ処理を行うことで<&lt;のように置換され記号等が無効化されます。

DOM-based XSSに限った話ではDOMの操作に十分に気をつけることです。

DOMの中でも自由度が高い分危険なものがあり有名なもので言えばinnerHTMLです。
innerHTMLではHTML要素を作成してしまうためスクリプトを埋め込めてしまいます。
テキストを出力するのであればテキストノードを使うようにしましょう。

HackerOneレポート

1. Cross-site Scripting (XSS) on HackerOne careers page

リンク: https://hackerone.com/reports/474656

このレポートはHakerOne自体の脆弱性についてのレポートです。
HackerOneのキャリアページにDOM-based XSSの脆弱性がありました。影響範囲は限定的とは言え$500の報奨金が出ています。
パラメーターの内容をサニタイズやエンコードをせず本文中に出力していたためDOM-based XSSが成功してしまいました。
しかしソースがクエリパラメーターのためfirefoxやchromeなどではURLがエンコードされてしまうため今回はXSSできません。CSPは設定されていましたがscript-srcにhttps:が設定されているためhttpsで公開されているjsであれば実行できてしまいます。またunsafe-inlineも設定されていたためインラインJavaScriptは実行できてしまいました。
利便性を優先してunsafe-inlineを設定することも今回のようにあるのでしょうがやっぱり不安に少し思いますね。セキュリティに関する項目はしっかり精査しているでしょうけどこのようなことが起きているのでよく考える必要がありそうです。

2. XSS via Direct Message deeplinks

リンク: https://hackerone.com/reports/341908
リンク: https://www.virtuesecurity.com/tale-of-a-wormable-twitter-xss/

このレポートはTwitterに存在していたDOM-based XSS脆弱性レポートです。
すごい複雑なことをしていてこれぞバグバウンティって感じのレポートですが難しくて初心者の自分だとなんとなくしか理解できなかったです。
まず脆弱性が存在していたのはダイレクトメッセージをクリックしただけで作成するデープリンクという機能です。
作成するメッセージ内にペイロードをうまく紛れ込ませました。
このペイロード自体はサニタイズされていたのですがこの処理が不十分で結果的にXSSを実行を許してしまいました。
またCSPが設定されていて悪用が困難だと考えられましたがその範囲が大きくsyndication.twimg.comも許可されていたためその中のコールバック関数を利用しました。
もちろんコールバック関数には対策として__twttrというプレフィックスをつけなければなりませんでした。このままだと__twttrが未定義のためエラーになってしまいますがデープリンクの脆弱性と併せiframeのidに__twttrを指定することで未定義エラーを回避しました。
またさっきのコールバック関数の対策では/が許容されていたため_twttr/alert(1)とすることで割り算して扱い計算するため右辺の値を計算するためにalert関数を実行するため無事CSPを回避しつつXSSに成功しました。
この連なった脆弱性の悪用としてワームを指摘していたのが面白いとおもいました。
ツイートを閲覧するだけで好きな処理を実行できてしまうため勝手に閲覧したユーザーがリツイートをしその連鎖で大きなリーチを手に入れることができます。
流石に一人だと理解しきれなかったのでGeminiちゃんと色々話し合ってみましたがほんとすごいですね。
HackerOneの方には報奨金非公開となってましたがレポーターの人が公開したブログには$2,940と書いてありました。ATOも可能だと思うのでかなり低い部類じゃないでしょうかね?

参考文献

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?