「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