「4.7 リダイレクト処理にまつわる脆弱性 」の「HTTPヘッダインジェクション」について

[OK]

徳丸様、いつもお世話になっております。

「4.7 リダイレクト処理にまつわる脆弱性 」の「HTTPヘッダインジェクション」について、質問させて頂けますでしょうか。

添付ファイルのP.3に質問を記載しております。

お忙しい所恐れ入りますが、何卒よろしくお願い致します。

[OK]

徳丸様、いつもお世話になっております。

添付致します。

よろしくお願い致します。

2025年8月13日水曜日 16:07:58 UTC+9 OK:

[徳丸浩]

徳丸です。こんにちは。

>【質問1】httpレスポンス内を確認すると利用者のWEBブラウザに右記情報が表示されるように見受けられますが、

> P.242のように何も表示されない理由はなにでしょうか。

このHTMLは301あるいは302ステータスによるリダイレクト処理をした場合に、Apacheが自動的に生成するものです。

ブラウザの設定など何らかの理由によりリダイレクト処理がされない場合にはこのHTMLが表示されます。現代のブラウザ

では、リダイレクトが抑止されることはないため、通常このHTMLが表示されることはありません。

2025年8月13日(水) 16:08 OK <cs00...@gmail.com>:

--
このメールは Google グループのグループ「「体系的に学ぶ 安全なWebアプリケーションの作り方」サポートML」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには wasbook-reade...@googlegroups.com にメールを送信してください。
このディスカッションを表示するには、https://groups.google.com/d/msgid/wasbook-readers/86645502-48b6-46ce-962f-b37883cf85e9n%40googlegroups.com にアクセスしてください。

--

徳丸浩 htok...@gmail.com

[OK]

徳丸様、いつもお世話になっております。

返信が遅れ申し訳ありませんでした。

ご回答ありがとうございます。

追加の質問で恐縮ですが、添付画像について質問させてください。

文字種類チェックのif文の正規表現について黄色の吹き出しで質問しております。

お忙しいところ恐れ入りますが、何卒よろしくお願い致します。

2025年8月13日水曜日 18:10:59 UTC+9 徳丸浩:

[徳丸浩]

徳丸です。こんにちは。

> 【手順1】改行コードがエンコードされた

ここはエンコードではなくデコードが正しいですね。Perlの以下のスクリプトですが、

my $url = $cgi->param('url');

クエリ文字列urlを取得している処理ですが、パーセントエンコードは自動的にデコードされます。これにより、%0D%0Aは改行になります。

> 【質問】【手順1】によって文字種チェックの条件に合致しなくなり不正URLと判定された、という認識で合っておりますでしょうか。

ちょっと違和感のある表現ですね。手順としてはパーセントエンコードがデコードされた結果不正なURLになったというのはその通りですが、

質問文ですと、【手順1】が積極的なセキュリティ対策として行われているように見えてしまいます。実際はそうではなく、パーセントデコード

は自然な処理の流れとして行っています。HTTPヘッダインジェクションはリダイレクトのURL中に改行を含ませることによって行うものなので、

まさにリダイレクトしようとしているURLに改行が含まれているかがチェックのポイントになります。

2025年8月30日(土) 13:17 OK <cs00...@gmail.com>:

このディスカッションを表示するには、https://groups.google.com/d/msgid/wasbook-readers/59a7c805-d51c-4d1a-a854-2d3bdfdeddcan%40googlegroups.com にアクセスしてください。

--

徳丸浩 htok...@gmail.com

[OK]

徳丸様、いつもお世話になっております。

ご回答ありがとうございます。

自然な処理の流れでデコードされているため、httpヘッダインジェクションを防ぐための対策ではない、という意味ですね。

文字種類チェックのif文の正規表現だと、デコードされた改行を判別できないため、httpヘッダインジェクションを防げる、

if文の条件内の正規表現がhttpヘッダインジェクションの対策になっている、理解しました。

今後ともよろしくお願い致します。

2025年8月30日土曜日 14:07:53 UTC+9 徳丸浩:

[徳丸浩]

徳丸です。こんにちは。

以下は違和感があります。

> 文字種類チェックのif文の正規表現だと、デコードされた改行を判別できないため、httpヘッダインジェクションを防げる、

> if文の条件内の正規表現がhttpヘッダインジェクションの対策になっている、理解しました。

該当箇所のソースは以下ですが、

# 正規表現によるURLの検証

if ($url =~ /\Ahttp:\/\/example\.jp\/[-_.!~*'();\/?:@&=+\$,%#a-zA-Z0-9]+\z/) {
# 検証を通ったURLでリダイレクト処理をする

  print $cgi->redirect($url);
  exit 0;
}

処理に使用する値 $url を検証しています。その前でデコードされているか否かは関係ありません。リダイレクト処理に

使用するURLが条件を満たしているかどうかを判断すればそれで問題ありません。

2025年8月30日(土) 17:54 OK <cs00...@gmail.com>:

このディスカッションを表示するには、https://groups.google.com/d/msgid/wasbook-readers/34c80178-7f76-4dbd-9597-6fe605cc2d7en%40googlegroups.com にアクセスしてください。

--

徳丸浩 htok...@gmail.com

[OK]

徳丸様、いつもお世話になっております。

ご指摘ありがとうございます。

恐らく、理解できたかと思います。

ちょっと日本語が微妙ですが、下記の認識です。

今回はデコードされた部分が正規表現とアンマッチのため不正URLと判定できたが、

デコード有無は関係なく、正規表現の結果次第でURLの正常異常を判断できる

本件は一旦解決しました。ありがとうございました。

今後ともよろしくお願い致します。

2025年8月30日土曜日 20:51:52 UTC+9 徳丸浩:

[OK]

徳丸様、いつもお世話になっております。

先ほどの投稿でPDFファイルを誤って添付しましたが、本件はクローズでお願い致します。

ご支援ありがとうございました。

今後ともよろしくお願い致します。

2025年9月2日火曜日 1:09:14 UTC+9 OK:

[OK]

徳丸様、いつもお世話になっております。

添付ファイルの内容について質問させてください。

「3471.png」のhttpレスポンスにて、Set-Cookieヘッダ内の文字列がデコードされないのはなぜでしょうか？

「3470.png」の「⑧HTMLテキスト表示」の画像は誤りで、ブラウザには「クッキー値をセットしました」のみが表示されるのですが、「3470.png」にてCGIのheader関数にてデコードされない、などの仕様があるかと思いました。

書籍p.251〜252がその内容と合致するかと思いましたが、合ってますでしょうか？

お忙しいところ恐れ入りますが何卒よろしくお願い致します。

2025年9月2日火曜日 1:10:28 UTC+9 OK:

[徳丸浩]

徳丸です。こんにちは。

ちょっと質問の内容がうまく理解できないのですが、以下を整理していただけないですか。

1. 試した操作（例: メニューの「47-021:CGIによるクッキーセット（偽画面）」を実行

2. 想定した結果（例: 画面上で以下2行が表示される

○○銀行は破産しました

クッキー値をセットしました

3. 実際の結果: （例: 「クッキー値をセットしました」のみが表示される）

4. 推測した理由: （例は省略）

5. 疑問に思っている内容: （例: 「CGIのheader関数にてデコードされない、などの仕様があるか」）

CGIのheader関数にてデコードされない、などの仕様があるか、についてはheader関数は受け取った内容を

そのままレスポンスヘッダに出力するもので、デコードされません。それはともかく、上記を回答いただけ

るとありがたいです。

2025年9月6日(土) 17:39 OK <cs00...@gmail.com>:

このディスカッションを表示するには、https://groups.google.com/d/msgid/wasbook-readers/0c50fd6f-5064-4b5d-9351-9b2e765c2fecn%40googlegroups.com にアクセスしてください。

--

徳丸浩 htok...@gmail.com

[OK]

徳丸様、いつもお世話になっております。

ご確認ありがとうございます。

下記にて整理致しましたので、再度ご確認頂ければと思います。

1. メニューの「13.CGIによるクッキーセット対策版（偽画面）」を実行

2. 画面上で以下2行が表示されると予想した。

○○銀行は破産しました

クッキー値をセットしました

3. 実際は「クッキー値をセットしました」のみが表示される

4. 2を予想した理由: 

「8.CGIによるクッキーセット（偽画面）」（書籍P.248の内容）と同じように、URLパラメータがデコードされると思ったため。

5. 「13.CGIによるクッキーセット対策版（偽画面）」にて、URLパラメータの内容がデコードされないのがなぜでしょうか？

お忙しいところ恐れ入りますが、何卒よろしくお願い致します。

2025年9月6日土曜日 18:20:37 UTC+9 徳丸浩:

[徳丸浩]

徳丸です。こんにちは。整理をありがとうございます。

> 1. メニューの「13.CGIによるクッキーセット対策版（偽画面）」を実行

承知しました。

> 2. 画面上で以下2行が表示されると予想した。
> ○○銀行は破産しました
> クッキー値をセットしました

このメニューは「対策版」の実行ですが、「○○銀行は破産しました」が表示されると攻撃の成功なので、これは表示されないのが意図した結果です。

> 3. 実際は「クッキー値をセットしました」のみが表示される

前述のように、これは意図した結果です。

> 4. 2を予想した理由:
>「8.CGIによるクッキーセット（偽画面）」（書籍P.248の内容）と同じように、URLパラメータがデコードされると思ったため。
> 5. 「13.CGIによるクッキーセット対策版（偽画面）」にて、URLパラメータの内容がデコードされないのがなぜでしょうか？

徳丸本P252にあるように、CGI::Cookieモジュールがクッキー値をパーセントエンコードします。

> PerlのCGI::Cookieモジュールは、ライブラリ側でクッキー値をパーセントエンコードします

そして、Set-Cookieヘッダを見ると、以下のようにパーセントエンコードされています。

> Set-Cookie: PAGEID=P%0D%0A%0D%0A%E2%97%8B%E2%97%8B%E9%8A%80%E8%A1%8C%E3%81%AF%E7%A0%B4%E7%94%A3%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F; path=/

もしCookieを表示する処理があれば、パーセントデコードしてから表示されますが、このプログラムにはCookieを表示

する機能はないため、デコード処理を実施する箇所がありません。

脆弱なバージョン（8. 47-021:CGIによるクッキーセット（偽画面））だと、以下のようにパーセントエンコードされずに、

改行2個のあとに「○○銀行は破産しました」がHTTPレスポンスとして出力され、これはSet-Cookieではなくレスポンス

ボディとして解釈されるというのが、HTTPヘッダインジェクションの原理です。

```
Set-Cookie: PAGEID=P

○○銀行は破産しました
```

Cookie出力時のHTTPヘッダインジェクション対策は、Cookie値のパーセントエンコードであり、47-021a.cgiではパーセントエンコードがされていために、HTTPヘッダインジェクション脆弱性は解消されています。

2025年9月7日(日) 16:32 OK <cs00...@gmail.com>:

このディスカッションを表示するには、https://groups.google.com/d/msgid/wasbook-readers/19284898-cd59-42ac-a9c3-403a9d9f51a7n%40googlegroups.com にアクセスしてください。

--

徳丸浩 htok...@gmail.com

[OK]

徳丸様、いつもお世話になっております。

ご回答ありがとうございます。

最終的に、CGIのcookieモジュールにてパーセントエンコードされている内容で理解しました。

下記について質問なのですが。。

>もしCookieを表示する処理があれば、

>パーセントデコードしてから表示されますが、

→どこにcookieを表示する前提でしょうか？httpレスポンスのsetcookieヘッダ？またはWEBブラウザ？

>このプログラムにはCookieを表示する機能はないた>め、デコード処理を実施する箇所がありません。

→添付ファイルP.59の手順⑧にてデコードしていると思いましたが、違ってますでしょうか。

お忙しいところ恐れ入りますが、何卒よろしくお願い致します。

2025年9月7日日曜日 18:00:25 UTC+9 徳丸浩:

[徳丸浩]

徳丸です。こんにちは。

> 下記について質問なのですが。。
> >もしCookieを表示する処理があれば、
> >パーセントデコードしてから表示されますが、
> →どこにcookieを表示する前提でしょうか？httpレスポンスのsetcookieヘッダ？またはWEBブラウザ？

ウェブアプリケーションで単に「表示」と書いた場合は、ウェブブラウザの画面に見える形で表示（出力）することを指します。

> >このプログラムにはCookieを表示する機能はないため、デコード処理を実施する箇所がありません。
> →添付ファイルP.59の手順⑧にてデコードしていると思いましたが、違ってますでしょうか。

失礼しました。以下はデコードしますね。

> my $pageid = decode('UTF-8', $cgi->param('pageid'));

しかし、以下の部分で再びパーセントエンコードされます。

> my $cookie = $cgi->cookie(-name => 'PAGEID',

>                         -value => $pageid);

これは、書籍P252の「PerlのCGI::Cookieモジュールは、ライブラリ側でクッキー値をパーセントエンコードします。」に該当します。

もしも、画面上にCookieの値を表示する箇所があれば、パーセントエンコードされずに表示されるはずですが、そのような箇所はありません。

2025年9月8日(月) 15:40 OK <cs00...@gmail.com>:

このディスカッションを表示するには、https://groups.google.com/d/msgid/wasbook-readers/1acc13e7-528e-4d70-9da7-dea9d18b47d4n%40googlegroups.com にアクセスしてください。

--

徳丸浩 htok...@gmail.com

[OK]

徳丸様、いつもお世話になっております。

お返事が遅くなり申し訳ありません。

度々の質問で恐縮ですが、下記にて質問させて頂けますでしょうか。

【質問①】

下記の2項目の違いは「CGI::Cookieモジュールによるパーセントエンコードの有無」という認識でよろしいでしょうか。

7. CGIによるクッキーセット（正常系）

→なし

12.CGIによるクッキー対策版（正常系）

→あり

【質問②】

下記の2項目では、パーセントエンコードによる変換が不要な文字列（P123） がURLパラメータで渡されているので、「CGI::Cookieモジュールによるパーセントエンコードの有無」に関わらず同じ結果になった、という認識でよろしいでしょうか。

7. CGIによるクッキーセット（正常系）

12.CGIによるクッキー対策版（正常系）

→どちらも最終的に、利用者が準備したpageIDとなる文字列（P123）がWEBブラウザのCookieに保存される。

【質問③】

「8.CGIによるクッキーセット（偽画面）」の添付画像「3530.jpeg」の手順⑦についてですが、このプログラムではURLパラメータの文字列をパーセントエンコードするように見受けられますが、認識合ってますでしょうか。（「encode」というプログラムがあるため迷いました。）

本項日では、デコードされた改行が悪さをして、「〇〇銀行は破産しました」という文字列をWEB ブラウザに表示させるという内容ですので、最終的にはパーセントエンコードされないと思いました。

【質問④】

「6.CGIによるリダイレクト（偽画面表示）」の対策版がないように見受けられますが、なしという認識でよろしいでしょうか。ある場合はどの項目になりますでしょうか。

「6」の対策版の内容を考えてみたのですが、下記で問題ないでしょうか。

・「3531.jpeg」記載の正規表現にマッチすること

・PerlのCGI:COOKIEモジュールを使用してパーセントエンコードすること

お忙しい大変所恐れ入りますが、何卒ご回答の程よろしくお願い致します。

2025年9月8日月曜日 16:34:48 UTC+9 徳丸浩:

[徳丸浩]

徳丸です。こんにちは。

>【質問①】下記の2項目の違いは「CGI::Cookieモジュールによるパーセントエンコードの有無」という認識でよろしいでしょうか。

はい、そのとおりです。

> 【質問②】下記の2項目では、パーセントエンコードによる変換が不要な文字列（P123） がURLパラメータで渡されているので、「CGI::Cookieモジュールによるパーセントエンコードの有無」に関わらず同じ結果になった、という認識でよろしいでしょうか。

はい、その通りです。

> 【質問③】「8.CGIによるクッキーセット（偽画面）」の添付画像「3530.jpeg」の手順⑦についてですが、このプログラムではURLパラメータの文字列をパーセントエンコードするように見受けられますが、認識合ってますでしょうか。（「encode」というプログラムがあるため迷いました。）

encode関数は、直前のコメントに「encode関数によりUTF-8符号化で出力する」とあるとおり、文字エンコーディングの指定であり、パーセントエンコードの指定ではありません。

このため、パーセントエンコードはされません。

> 【質問④】「6.CGIによるリダイレクト（偽画面表示）」の対策版がないように見受けられますが、なしという認識でよろしいでしょうか。ある場合はどの項目になりますでしょうか。

対策版は47-021a.cgi で共通です。ないのは、「対策されていることを確認するメニュー」です。以下のURLで確認することが可能です。

http://example.jp/47/47-020a.cgi?url=http://example.jp/%0D%0AStatus:+500%0D%0A%0D%0A%EF%BB%BF%E2%97%8B%E2%97%8B%E9%8A%80%E8%A1%8C%E3%81%AF%E7%A0%B4%E7%94%A3%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F

2025年9月17日(水) 15:10 OK <cs00...@gmail.com>:

このディスカッションを表示するには、https://groups.google.com/d/msgid/wasbook-readers/4d238fb4-112a-4017-84c5-1b26ef4ee27fn%40googlegroups.com にアクセスしてください。

--

徳丸浩 htok...@gmail.com

[OK]

徳丸様、いつもお世話になっております。
【質問①②③】についてご回答ありがとうございます。
【質問④】について、「47-020a.cgi」を使うことで対策になっている理解できました。

追加の質問で恐縮ですが、下記スライドについて質問させてください。
ファイル名：リダイレクト処理にまつわる脆弱性_HTTPヘッダインジェクション.pdf
スライド：12

[セッション管理の不備.pdf]のセッションIDの
固定化攻撃で実現可能か確認したいです。
その際に、条件等自分の認識を記載致しましたので、ご確認頂けますでしょうか。

質問範囲を超えておりましたら、ご指摘頂ければと思います。
お忙しい所恐れ入りますが、何卒よろしくお願い致します。

2025年9月17日水曜日 18:15:18 UTC+9 徳丸浩:

[徳丸浩]

徳丸です。こんにちは。

質問の趣旨は、47/47-901.phpで収集したIDとパスワードは、デモ用のスクリプトでは単に表示されるようになっていますが、

これを保存して、攻撃者が後から確認できるようにする方法だと思います。ご提案の方法は。IDとパスワードをセッション変数に

保存して、これをセッションIDの固定化攻撃により参照するという方法だと理解しました。

しかし、47/47-901.phpは、攻撃者が管理するサーバー（trap.example.com）で動作するので、わざわざ脆弱性に対する攻撃を使わなくても、

収集したIDとパスワードをファイルなどに保存しておけば、攻撃者はそのファイルを自由に参照できます。

なので、「わざわざセッションIDの固定化攻撃を使う合理性がない」というのが回答になります。

2025年9月23日(火) 1:50 OK <cs00...@gmail.com>:

このディスカッションを表示するには、https://groups.google.com/d/msgid/wasbook-readers/1295c4b0-81c2-455f-a662-a3b49478b646n%40googlegroups.com にアクセスしてください。

--

徳丸浩 htok...@gmail.com

[OK]

徳丸様、いつもお世話になっております。
ご回答ありがとうございます。

はい、質問の趣旨はご認識の通りです。
黄色の吹き出しの「これ」とはオレンジの吹き出しの内容を指しておりました。失礼致しました。
確かに[trap.example.com]は攻撃者が管理しているものですので攻撃を仕掛ける必要がないですね。。
ありがとうございます。

似たような質問で恐縮ですが、[5. CGIによるリダイレクト（クッキー設定）]についても質問させて頂きます。
添付ファイルのスライドP.9に黄色の吹き出しを載せております。

お忙しい所恐れ入りますが、何卒よろしくお願い致します。

2025年9月23日火曜日 10:47:49 UTC+9 徳丸浩:

[徳丸浩]

徳丸です。こんにちは。

ご質問に回答する前に、前提となる攻撃の解説記事を書きましたので、いったんこちらを読んでから不明点を再度ご質問ください。

https://qiita.com/ockeghem/items/65c2759033d636e43746

2025年9月24日(水) 0:44 OK <cs00...@gmail.com>:

このディスカッションを表示するには、https://groups.google.com/d/msgid/wasbook-readers/72ea559e-57b0-4a9e-814a-909cd268cf74n%40googlegroups.com にアクセスしてください。

--

徳丸浩 htok...@gmail.com

[OK]

徳丸様、いつもお世話になっております。
「HTTPヘッダインジェクションとセッションIDの固定化攻撃を組み合わせた演習」の記事でのご回答ありがとうございます。
大変わかりやすく理解できました。
さらに、httpリクエストのCookie欄にどうやったら偽セッションIDを仕込めるのかを質問しようとしておりましたが、
これも記事内で解決しました。
→WEBブラウザのCookie欄のセッションIDを手動で修正することで、httpリクエストのCookie欄にセッションIDを仕込める

今回の事象を検証するには、下記のプログラムでは検証不可だったと理解しました。
理由：「47-003.php」が下記の仕様のため、セッションIDに紐づくセッション変数まで見ていないため
・47-020.cgi
→クエリパラメータのURLにそのままリダイレクトする
・47-003.php
→httpリクエストを受け取ったら「ログインしました」を表示するのみ

【質問】
今回の検証では、偽セッションIDに紐づくセッション変数を表示させるために、[463/46-010.php]にリダイレクトさせた、という認識でよろしいでしょうか。
最終的に、[463/46-012.php]にて、偽セッションIDに紐づくセッション変数の値を不正に表示させているので、今回の検証の目的を達成できたと思います。

他に理由があればご教示頂けますでしょうか。

お忙しい所恐れ入りますが、何卒ご回答のほどよろしくお願い致します。

2025年9月24日水曜日 23:39:39 UTC+9 徳丸浩: