リバース プロキシで TLS を終端する構成で、X-Forwarded-Proto が見られていない

[OsscJpDevInfra]

何をしたいか

リバース プロキシで TLS を終端する構成でも、X-Forwarded-Proto を見て
「HTTPS で来ている」と判断できるようにする。

#548（コンテナ化）を検討する中で見つかった。
コンテナや Kubernetes では前段で TLS を終端し、アプリへは HTTP で転送するのが定石だが、
現状のフレームワークはその構成を想定していない。

なぜ必要か

#536 で入れた Cookie の Secure 属性が、この構成では立たない。

#536 は「HTTPS のときだけ Secure を立てる」という形にした。
ところが TLS を前段で終端すると、アプリから見た接続は HTTP なので
利用者のブラウザは HTTPS で繋いでいるのに、Secure が付かない。

セキュリティ対応を入れたつもりで、最も本番らしい構成でだけ効かない、という状態になっている。

現象（実測）

MVC_Sample (net10.0) に X-Forwarded-Proto: https を付けて要求しても、
応答の Cookie に secure は付かない。

[素の HTTP]                  .AspNetCore.Cookies=<値>; path=/; samesite=strict; httponly
[X-Forwarded-Proto: https]   .AspNetCore.Cookies=<値>; path=/; samesite=strict; httponly

調べたこと

該当箇所は 4 つ（FxCmnFunction.cs のみ）

スキームで分岐しているのはこの 4 か所だけで、いずれも
セッション タイムアウト検出用 Cookie の生成・削除である。

行	対象	実装
Framework/Util/FxCmnFunction.cs:971	net10.0	cookieOptions.Secure = MyHttpContext.Current.Request.IsHttps;
Framework/Util/FxCmnFunction.cs:1010	net10.0	同上
Framework/Util/FxCmnFunction.cs:1049	net48	newCookie.Secure = HttpContext.Current.Request.IsSecureConnection;
Framework/Util/FxCmnFunction.cs:1088	net48	同上

net48 / net10.0 の両方が対象。 条件コンパイル（#if (NETSTD || NETCOREAPP)）で
実装は分かれているが、どちらもプロキシの転送を見ていない点は同じ。

UseForwardedHeaders はリポジトリのどこにも無い

$ grep -rn 'UseForwardedHeaders' --include=*.cs .
（該当なし）

X-Forwarded-For は Framework/Util/GetClientIpAddress.cs と
Business/Presentation/MyBaseAsyncApiController.cs がヘッダを直読みしているため、
クライアント IP の取得は動く。X-Forwarded-Proto だけが誰にも見られていない。

帰結は 3 つ

1. #536 の Secure 自動設定が効かない（上記）
2. appSettings__CookieSecurePolicy=always（#541）が、この構成では実質必須になる。
   あちらは IsHttps を見ずに明示的に立てるため、迂回策として機能する
3. UseHttpsRedirection を on にすると無限リダイレクトになる。
   アプリが「HTTP で来た」と判断して HTTPS へ 307 → プロキシが HTTP で転送 → 繰り返し。
   #541 で「前段で終端するなら off」と書いた根拠がこれ

案

net10.0 側 : UseForwardedHeaders

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedProto | ForwardedHeaders.XForwardedFor
});

パイプラインの先頭近く（UseHttpsRedirection より前）に置く必要がある。

踏みやすい罠 : KnownProxies / KnownNetworks を設定しないと黙って無視される。
既定ではループバックからの転送しか信用しない。
コンテナや Kubernetes では前段が別アドレスになるため、設定しないと何も起きない。
逆に無条件に信用すると、クライアントがヘッダを詐称できる（Secure の判断を
外から操作されることになる）ので、どちらにも倒せない。ここは慎重に決めたい。

置き場所も選択肢がある。

	利点	欠点
サンプル（Startup.cs）に置く	フレームワークの挙動を変えない	利用者が自分で書く必要がある
フレームワーク側で面倒を見る	何もしなくても正しく動く	**既定の挙動が変わる。**下位互換の検討が要る

**まずはサンプル側で、設定で on/off できる形（#541 と同じ流儀）**が穏当だと思う。

net48 側 : IIS の設定

net48 は HttpContext.Current.Request.IsSecureConnection で、
コードからは変えられない（読み取り専用）。
IIS + ARR なら URL Rewrite で HTTP_X_FORWARDED_PROTO を見て
サーバ変数 HTTPS を立てる、という定番の対処がある。

コードではなく Web.config と手順書の話になるので、
Samples/WebApp_sample/MVC_Sample の Web.config にコメントを置く形を想定している
（#541 で machineKey について同じことをした）。

影響

• 利用者への影響: 案（サンプル側・既定 off）なら無し。
  フレームワーク側で面倒を見る案を採る場合は、既定の挙動が変わるため
  下位互換の検討が要る
• net48 / net10.0: 両方。ただし対処が異なる
  （net10.0 はコード、net48 は IIS の設定）
• 深刻度は高くない。 Secure が付かない対象はセッション タイムアウト検出用 Cookie で、
  値は Environment.TickCount である（資格情報ではない）。
  認証 Cookie 自体は ASP.NET Core の Cookie 認証 / FormsAuthentication 側の管轄で、
  そちらは #541 の CookieSecurePolicy と requireSSL（#536）で立てられる
• 検証: 3_SmokeTest.ps1 は素の HTTP で回るため、既定 off なら影響を受けない

関連

• #536 — Cookie の Secure を IsHttps で立てる形にした（本件の前提）
• #541 — CookieSecurePolicy / UseHttpsRedirection を設定で切り替える形にした
• #548 — コンテナ化。この構成を検討する中で見つかった

[OsscJpDevInfra]

対応しました（netcore は実測済み、net48 は未検証）

先に訂正から。これは「デグレ」ではなかった。
#536 の FxCmnFunction.cs への差分は 0 削除 / 17 追加で、それ以前は Secure を
一切設定していない。リバプロ配下の挙動は #536 以前と同じである。

ただし性質は悪い。 CodeQL は満たされ、コードも「Secure を立てている」ように読めるのに、
最も本番らしい構成でだけ効かない。「入れたつもりの対策が無い」状態は、
最初から無いより気付きにくい。

実装

① netcore : UseForwardedHeaders（サンプル側・既定 off）

Samples4NetCore/Backend/MVC_Sample/MVC_Sample/Startup.cs のパイプライン先頭に置いた
（UseHttpsRedirection より前）。切り替えは #541 と同じ流儀。

キー（appSettings）	既定	効果
UseForwardedHeaders	off	X-Forwarded-Proto / -For を取り込む
ForwardedHeadersKnownProxies	(空)	信用する前段のアドレス（空＝範囲を制限しない）

KnownNetworks は .NET 10 で非推奨（ASPDEPR005）のため KnownIPNetworks を使っている。

② net48 : IIS の URL Rewrite（コメントのみ）

Request.IsSecureConnection はコードから変えられないため、
Samples/WebApp_sample/MVC_Sample/MVC_Sample/Web.config に、
IIS + ARR で HTTPS サーバ変数を立てる設定例をコメントで置いた。

③ フレームワーク : コメントの追記のみ（挙動は変えない）

Framework/Util/FxCmnFunction.cs の 4 箇所（netcore 2・net48 2）に、
リバプロ配下では false になることと対処を書いた。追加 30 行・削除 0。

判断ロジック自体は変えていない。この行は壊れていない（下の実測のとおり、
環境を整えれば FxCmnFunction.cs を 1 行も変えずに Secure が付く）。
足りなかったのは「前段を信用する」というアプリ側の宣言である。

④ 文書

Samples4NetCore/ANALYSIS.md（5-1 の表 ＋ 5-2 に④を新設）、
Samples4NetCore/Docker/README.md（本番の表）。

実測（対照つき）

平文 HTTP でログインし、X-Forwarded-Proto: https を付けたときの Set-Cookie。

設定	secure が付いた Cookie
既定（off）	0 / 1 件 ← 本件の症状
UseForwardedHeaders=on	3 / 4 件（SessionTimeOut / .AspNetCore.Cookies / mvc_session）
on ＋ ForwardedHeadersKnownProxies=10.0.0.1	0 / 1 件（範囲外なので捨てられる）
on ＋ ヘッダ無し	0 / 1 件（素の HTTP のまま。正しい）

SessionTimeOut は #536 でフレームワークが立てる Cookie そのもの。
これに secure が付いたことが、Request.IsHttps が正しくなった直接の証拠である。

★ 未検証 — net48 の IIS URL Rewrite は一度も動かしていない

Web.config に書いたのは広く使われている手順であって、
この環境で Request.IsSecureConnection が実際に true になることは確認していない。
allowedServerVariables への登録が要る、IIS のパイプライン モードで効き方が違う、
といった報告もある。「書いてあるから動く」と受け取らないでほしい。

netcore 側との非対称を、そのまま残す。

残る例外（対象外／要別途確認）

	内容
プロキシが 2 段以上	X-Forwarded-Proto は https, http と積み上がる。ASP.NET Core は既定で右から 1 つ（ForwardLimit=1）しか見ないため、内側の値を拾って http と判断し得る。段数に応じた調整が要る
RFC 7239 の Forwarded:	ForwardedHeadersMiddleware は X-Forwarded-* しか読まない。 前段が RFC 準拠のヘッダしか出さないなら自前のミドルウェアが要る
サブパス配置	前段が /app の下にマウントするなら X-Forwarded-Prefix も要る。FxCmnFunction は Request.PathBase を Cookie の Path に使っているため、ずれると Cookie のパスが狂う。今回は取り込んでいない（app.UsePathBase() で宣言する手もある）
X-Forwarded-Host	今回は Proto と For だけ。有効にするとホスト ヘッダ インジェクションの面が出るので、AllowedHosts（現状 "*"）とセットで考える必要がある
直接到達できる状態	ヘッダを詐称され、HTTP なのに HTTPS と判断させられる。KnownProxies を空にする運用では必須の前提
削除用 Cookie	Framework/StdMigration/CookieExtensions.cs が responseCookies.Delete(key) をオプション無しで呼ぶため、転送ヘッダ経由では secure が付かない（3/4 の残り 1 件がこれ）。後述の CookiePolicy なら塞がる

設計上の整理（次に踏む人のために）

成立には 3 点が要る。伝播だけでは足りない

	内容	欠けると
① 前段が伝播する	X-Forwarded-Proto: https を付ける	何も起きない
② アプリが受け取る設定になっている	UseForwardedHeaders	付いていても捨てられる ＝ 本件
③ そのヘッダを付けられるのが前段だけ	ネットワークで閉じる／KnownProxies	クライアントが詐称できる

「検知」より「宣言」の方が確実

CookieSecurePolicy=always（#541）だけを入れ、IsHttps は false のままで測った。

方針	手段	secure が付いた Cookie
検知（実態を知らせる）	UseForwardedHeaders	4 件中 3 件
宣言（そう決め打つ）	CookieSecurePolicy=always	4 件中 4 件（削除用 Cookie も含む）

CookiePolicy はすべての Set-Cookie を後段で上書きするため、
フレームワークが個々の箇所で何を判断しているかに依存しない。
net48 の対応物は forms の requireSSL="true"。

分かれ目は「リクエストごとに変わるか」

情報	性質	内部パラメタで矯正できるか
スキーム（HTTPS か）	環境ごとに固定	できる（CookieSecurePolicy / requireSSL）
配置パス（サブパス）	環境ごとに固定	できる（app.UsePathBase）
外部から見た URL	環境ごとに固定	できる（設定に絶対 URL を書く。SpRp_RedirectUri が実例）
クライアント IP	リクエストごとに変わる	できない（伝播が必須）
クライアント証明書	リクエストごとに変わる	できない（伝播が必須）

クライアント IP は既に動く。 Framework/Util/GetClientIpAddress.cs と
Business/Presentation/MyBaseAsyncApiController.cs が X-Forwarded-For を
ヘッダから直読みしており、UseForwardedHeaders の設定に依存しない。

宣言のトレードオフ

宣言は環境の実態と食い違うと壊れる（実測：本当に平文 HTTP で always にすると
ログイン POST が 400。Antiforgery の Cookie が返らないため）。

ただしこれは利点でもある。

	間違えたときの現れ方
検知（伝播に依存）	静かに効かない。 画面は正常に動き、Secure だけが付かない ＝ 本件
宣言	はっきり壊れる。 すぐ気付いて直せる

検証

	結果
1_BuildAll.ps1（CS）	全ステップ OK（既知の MSB3482 を 1 件除外）
2_RunAllTests.ps1	8-8、差分 0、全テスト OK
3_SmokeTest.ps1（CS / Windows PowerShell 5.1）	23/23 OK
0_RunAll.ps1 -Lang VB	全ステップ OK（ビルド 10/10、疎通 6/6）
dotnet build MVC_Sample.csproj	0 警告 0 エラー

FxCmnFunction.cs は net48 / net10.0 の両方でコンパイルされるため、VB まで回した。
既定は off なので従来の動作は変わらない。 疎通が通ることがその確認である。

利用者への影響

無し。 追加した設定はいずれも既定 off / (空) で、既定の挙動は変えていない。
フレームワークへの変更はコメントのみ（追加 30 行・削除 0）。
公開 API・ビルド時の警告も変わらない。

リバース プロキシ配下で運用している利用者にとっては、設定を入れれば直せるようになる。

残していること

• VB 側の Web.config に同じコメントを入れていない（#541 の machineKey も CS 側だけ）。
  揃えるなら両方まとめてが良いと考え、今回は触っていない
• フレームワーク側で面倒を見る案は採らなかった。CookiePolicy と二重の仕組みになるうえ、
  既定の挙動が変わるため

[OsscJpDevInfra]

net48 側も実測しました（前のコメントの「未検証」を解消）

前のコメントで **「net48 の IIS URL Rewrite は一度も動かしていない」**と書いた件。
動かして確かめた。効く。

ARR は要らなかった

最初は「ARR を立てないと確かめられない」と考えていたが、それは違った。

ARR	IIS 自身をリバース プロキシにする機能
URL Rewrite	サーバ変数を書き換える機能。今回必要なのはこちらだけ

確かめたいのは「X-Forwarded-Proto を見て HTTPS サーバ変数を立てたとき、
Request.IsSecureConnection が true になるか」の一点である。
前段は要らない。ヘッダはテスト側から送れる。

そして IIS Express には URL Rewrite が既に入っていた（rewrite.dll / rewrite_schema.xml /
applicationhost.config の RewriteModule 登録）。
このため IIS 本体のインストールも管理者権限も無しで検証できた。

参考: ARR 自体は Windows 11 Pro でも構築できる（クライアント SKU で動く）。
「Windows の機能で IIS を有効化 → URL Rewrite の MSI → ARR の MSI」。
Web Platform Installer は提供終了しているので、MSI を個別に取得する。

結果（対照 3 ケース）

Samples/WebApp_sample/MVC_Sample（net48）を IIS Express で動かし、
ログインまでの Set-Cookie を見た。

	secure が付いた Cookie
規則あり ＋ X-Forwarded-Proto: https	6 件中 2 件 — SessionTimeOut の生成・削除の両方
規則あり ＋ ヘッダ無し	0 件
規則あり ＋ X-Forwarded-Proto: http	0 件（条件の ^https$ が正しく弾いている）

[https] SessionTimeOut=;          path=/; secure; HttpOnly
        SessionTimeOut=391778750; path=/; secure; HttpOnly
[なし]  SessionTimeOut=;          path=/; HttpOnly
        SessionTimeOut=391794156; path=/; HttpOnly

SessionTimeOut は #536 でフレームワークが立てる Cookie そのもの。
これに secure が付いたことが、Request.IsSecureConnection が true になった直接の証拠である。

netcore との違い — net48 は削除用 Cookie にも付く

netcore 側は 4 件中 3 件止まりだった。残る 1 件は削除用 Cookieで、
Framework/StdMigration/CookieExtensions.cs の responseCookies.Delete(key)
（オプション無し）を通るため。

net48 の DeleteCookieForSessionTimeoutDetection は newCookie.Secure を明示しているので、
生成・削除の両方に付く。前のコメントで挙げた「削除用 Cookie の穴」は
netcore 側だけの話だった、と訂正する。

踏んだこと（2 つとも文書に残した）

① allowedServerVariables への登録が要る。忘れると全要求が 500.50

HTTP Error 500.50 - URL Rewrite Module Error.
The server variable "HTTPS" is not allowed to be set.
Add the server variable name to the allowed server variable list.

Web.config からは設定できない（overrideModeDefault="Deny"。セキュリティ上の関門）。
applicationHost.config に書く。

<rewrite>
  <allowedServerVariables>
    <add name="HTTPS" />
  </allowedServerVariables>
</rewrite>

② /path: 起動の IIS Express は、別の applicationhost.config を読む

利用者レベルの %USERPROFILE%\Documents\IISExpress\config\applicationhost.config ではなく、
%ProgramFiles%\IIS Express\AppServer\applicationhost.config を読む。

最初にこれを取り違えて、設定したのに 500.50 が続いた。
また /config: は /path: と併用できない（/site: が要る）。

検証では AppServer の設定を複製して /config: ＋ /site: で渡したので、
Program Files 側も利用者側も変更していない。

環境の後片付け

利用者の applicationhost.config	バックアップと同一（cmp で確認）。結局触る必要が無かったので完全復元
Program Files のテンプレート	無変更（複製して使用）
IIS Express プロセス	残存なし
検証用の複製サイト	削除済み（リポジトリのサイトは触っていない）

変更

ファイル	内容
Samples/WebApp_sample/MVC_Sample/MVC_Sample/Web.config	「※ 未検証」を実測結果に差し替え。allowedServerVariables の必要性と 500.50 を追記
CONFIGURATION.md 8 節	検知／宣言の表を net10.0 と net48 の両方の実測値に更新。netcore が 3/4 止まりの理由も明記

コメント・文書のみで、設定値もコードも変えていない。
#549 の実装は前のコメントの時点から変わっていないため、検証の再実行は行っていない。

これで残るもの

• VB 側の Web.config に同種のコメントが無い（#541 の machineKey も CS 側だけ）。
  揃えるなら両方まとめてが良いと考えている
• 削除用 Cookie の穴（netcore 側のみ）。CookiePolicy の
  CookieSecurePolicy.Always なら塞がることは実測済み