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

Reflected XSSについてまとてみた!

Last updated at Posted at 2025-11-30

XSSについて

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

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

  • Reflected XSS
  • Stored XSS
  • DOM-Base XSS

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

Reflected XSSについて

Reflected XSSはわかりやすいものではURLのQueryパラメータをそのまま表示している例です。

 <?php echo "メッセージ:".$_GET['message']; ?>

こんな感じのphpが書かれていたしてhttp://example.com?message=<script>alert('xss')</script>などとしてあげればscriptタグがそのままhtml上に放たれるので脆弱と言えます。

悪用方法について

XSSはかなり強力です。任意のスクリプトを実行できてしまうためうまくいけばセッションハイジャックすることが可能になりアカウント乗っ取りまで行けてしまいます。

しかもGETパラメータだった場合攻撃対象がURLを開くだけで攻撃が成功してしまいます。

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

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

またContent-Security-Policyヘッダーによるスクリプトの制限でもある程度対策することが可能です。
下記のようにscript-srcをselfにすることでスクリプトを同じオリジンのものに限定することができます。またscript-srcを指定することでインラインJavaScriptが無効化されXSSに対する対策に大いに役立ちます。

Content-Security-Policy: script-src 'self'

ただ同じオリジンであれば良いのでファイルアップロードの脆弱性があればXSSに成功する場合があります。そのため様々な対策を併用するようにしましょう。

間違った対策について

XSSの代表的な間違った対策として'script'という文字を消す実装がありますがこれは脆弱です。

<scrscriptipt>print()</scrscriptipt>

このようなスクリプトが挿入された場合'script'という文字が削除された場合に正しいスクリプトになってしまいます。'script'という文字を削除するだけでは対策としては足りませんがもしこのような実装をしたい場合'script-replaced'などと別の文字に置換するようにしましょう。

また下記のようなHTMLを挿入することでもスクリプトを実行することが可能です。

<img src=x onerror=javascript:print()>
<body onload=javascript:print()>

このようにscriptタグ以外でもいくらでもスクリプトを書けてしまうのでscriptタグを置換するのではなく入力文字をエスケープし万が一エスケーブがバイパスされた際でもインラインのjavascriptをSCPヘッダーで無効化しておきましょう。

Reflected XSSに関するHackerOneレポート

Reflected XSSが実際どのように発見されているのかを確認するためHackerOneのレポートをいくつか見てみました。かなり主観的で憶測が多いので間違ったこと言っていたらごめんなさい。

1. Reflected Cross site Scripting (XSS) on www.starbucks.com

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

こちらはStarbucksのWebサイトに存在したReflected XSSに関するレポートです。
アカウントにログイン後の行き先を表すReturnUrlにjavascriptを指定しています。
ただここで指定されているjavascriptはふんだんに細工されていてうまく検知を回避しています。
自分が調べて理解できる範囲では文字列中にタブを入れ単語の検知回避、スキームのhttps:をjavascriptのラベルとして扱う、スキームの//をコメントとして扱いホストを文字列中に入れ改行文字でコメント終了、%250Aは多重でURLエンコードで2回デコードされた際に改行文字として扱うってところですかね。
よく考えられていてすごく参考になります。なんと言うかこう見るとjavascriptとurl構成の相性めっちゃいいですね。

2. XSS Reflected on reddit.com via url path

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

これはredditの認証コードの確認用のエンドポイントにXSSの脆弱性がありました。
こちらは見た感じ認証コードを確認する関数の第二引数にjavascriptを渡すと実行されるような実装になっていたようです。なので比較的PoCは単純です。レポートの会話を見ているとここ以外のエンドポイントにも同じような脆弱性がありそちらではユーザー操作も不要なため高額な報奨金がでたようです。報奨金の金額自体は公開されていませんが本人が高額と言っているのでなんかモチベーション上がりますね。
このユーザーのhacktivityを見てみましたがこの問題を報告したのはアカウント作成から8ヶ月, 4個めのレポートなのでだいぶ初期だと思います。もちろんこの人の実力なのはわかりますがバグバウンティの可能性をすごく感じますね!

PoC動画

よりReflected XSSを具体的に知るためYoutubeに公開されているPoC動画をいくつか見てみました。
PoC動画は実際の脆弱性をどのようにして利用するのかわかりやすいのでXSSに関わらずおすすめです。

1. $50 Reflected XSS | Bug Bounty PoC

リンク:https://www.youtube.com/watch?v=CSzJKB9kaK0

この動画ではatmail.comのreturn_toクエリーがbody内のform内のhiddenフィールドの一つに挿入されているため">でタグを閉じimgタグのonerrorでjavascriptを実行しています。
動画ではクエリーに入っている文字列を本文中にあるかどうかを探しているように見えますね。クエリーがある場合検索かけるとXSSを見つけやすいと思います。

最後にひとりごと

最後まで見ていただいてありがとうございます!
初めてのひとりアドベントカレンダーをしていますが無事達成できるんですかね?
この人記事だけでも4時間近くかかってるよぉXSSなのにぃ最後の方はあまり理解していなものについても書かなきゃだろうからもっと時間かかるんだろうなぁ
逆にXSSが色々強すぎるってのはあるかも書きたいことありすぎる。
あとは25個も脆弱性思いつくかな??一応Web系で聞いたことある脆弱性せめていきたいけどなんかあんま思いつかない。。。
あとどんな情報を載せたほうがいいよとか自分はこの脆弱性探すときここ注目してるよとかあったらマジで教えて欲しいです。バグバウンティ始めたっばでなんもわからん...

参考文献

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