a-blog cms PHP API Reference

信頼プロキシ一覧（TRUSTED_PROXY_LIST）に一致する接続元、または INTERNAL_RANGES （プライベート／ループバック／リンクローカル）からの接続だけを信頼する（案 1）。

Why not: この判定に渡す $server は、ソケットの接続元をそのまま伝える $_SERVER でなければならない。setTrustedProxyConstants() が XFF 由来の値を REMOTE_ADDR 定数へ反映した後の値を使うと、信頼境界の判定基準そのものが攻撃者の送信値に 依存することになり、 「信頼されていないクライアントが、自分自身を信頼済みプロキシや内部アドレスだと 名乗るだけで転送ヘッダの信頼を得る」という循環が成立してしまう。これは呼び出し 順序（setTrustedProxyConstants() が先か後か）に依存しない不変条件であり、将来 REMOTE_ADDR 定数が先に定義されるよう変更されても、この理由がある限り置き換えてはならない。

Why not: 単純な fail closed（TRUSTED_PROXY_LIST 未設定なら常に信頼しない）は 採用しない。配布既定は空文字で、設定 UI も無いため、TLS 終端 LB／CDN 配下で これを設定していない既存サイトの HTTPS 判定が恒久 false になり、常時 SSL リダイレクトのループや Secure Cookie の喪失という運用事故に直結する。 実運用の LB・リバースプロキシはほぼ内部アドレスから接続するため、 接続元が INTERNAL_RANGES に含まれるかどうかで代替の安全網を張る。

Why not: CGNAT（100.64.0.0/10）は INTERNAL_RANGES に含まれないためこの判定では 救えない（TRUSTED_PROXY_LIST の設定が必要）。案 1 に残る既知の穴として受け入れる。

ヘッダ名が RFC 7239 の Forwarded（$_SERVER のキーで HTTP_FORWARDED）のときだけ RFC 7239 の文法で解釈し、それ以外は X-Forwarded-For 系としてカンマ区切りで分割する。

Why not: 値の中身で形式を判定（for= を含むかで振り分ける等）しない。X-Forwarded-For に for= を含む文字列を送るだけで解釈方法を切り替えられてしまい、攻撃者が パーサを選べる状態になる。どちらで読むかは運用者の設定（PROXY_IP_HEADER）だけで決める。

Why not: HTTPS 定数は「信頼できる情報だけを見て false のまま」という結果が 正しいことがある（このメソッドが true を返すケースはまさにそれ）。しかし main.php の常時 SSL リダイレクトは !HTTPS だけを見て https へ 301 する。 接続元が実際には https で届いているのに、信頼していないという理由だけで !HTTPS を通してリダイレクトすると、クライアントは既に https で来ているため 何も変わらず再度リダイレクトを踏み、301 の無限ループになる。この判定は ヘッダを信頼する（信頼済みとして扱う）わけではなく、あくまで「リダイレクトを 止めるべきかどうか」だけを見るための別の軸で、HTTPS 定数・Secure Cookie の 判定には一切影響しない。

Why not: Forwarded 側は「採用要素」まで絞らず、値に proto=https を含む要素が どこにあっても検知対象にする。この判定はそもそも信頼できない前提（呼び出し ガードで既に未信頼と分かっている）のループガードであり、「どの要素が正しい クライアントか」を厳密に決める必要が無い。むしろ偽装要素であっても https を 主張していればループを止めるべきなので、resolveHttpsFlag() 側の「採用要素だけ」 という絞り込みとは意図的に非対称にしている。

Why not: $addr は normalizeAddr で正規化してから比較するため、IPv4-mapped IPv6 （::ffff:10.0.0.1 等）は 4 バイトの IPv4 として扱われる。そのため CIDR 側 （$cidr）も正規化後のファミリに合わせて書く必要がある。::ffff:0:0/96 のように IPv6 のまま書いた CIDR は、正規化後の $addr（4 バイト）と長さが噛み合わず 常に false になる（fail closed だが無警告なので、設定例には注意が必要）。

$_SERVER のキー（HTTP_FORWARDED）とヘッダ名そのまま（FORWARDED）の両方を受ける。 PROXY_IP_HEADER は運用者が手で書く設定値なので、大文字小文字は問わない。

Why not: 旧実装（$_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https'）は非数値文字列 同士の比較のため実質 === と同じで、'https, http'・'http,https'・前後空白 付き・末尾セミコロン付きの値は実測でもすべて false だった。ここで変えたのは 大文字小文字を無視するようにした点だけで、複数値やカンマ区切りを拒否する挙動 自体は旧実装からそのまま継続している。新たに何かを弾くようになったわけではなく、 HTTPS/Https のような表記ゆれを受け入れる方向への互換性拡大である。

Why not: isTrusted() と同一視しない。TRUST_DIRECT_PEER（'*'）は「接続してきた 相手をプロキシとして信頼する」意味なので、接続元の判定でだけ真になり、XFF の 各ホップの判定（isTrusted）では偽のままでなければならない。両方で真にすると 全ホップが信頼扱いになり、pickClientAddr が null を返して接続元へ縮退する （クライアント IP が常に直近プロキシの IP に潰れる）。

Why not: デュアルスタック構成のロードバランサーは同一クライアントに対して ::ffff:10.0.0.1 と 10.0.0.1 のどちらの表記も付与し得る。正規化せずに 比較・返却すると、信頼判定がすり抜けてロックアウトを起こしたり、 lock_address のバケットが表記違いで 2 つに分裂して試行回数上限が 実質倍になったりする。

文法（RFC 7239 §4）は次のとおり。要素はカンマ区切り、要素内のパラメータはセミコロン 区切りで、値は token または quoted-string を取る。

Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43
Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]:4711"

for の値（node、RFC 7239 §6）は IPv4 / [IPv6] / unknown / _ 始まりの難読化 識別子のいずれかで、任意でポートが付く。IP として解釈できない値（unknown や _hidden）は pickClientAddr() が既に「不正なホップは読み飛ばす」扱いにしているため、 ここでは値をそのまま返して判定を任せる。

for の無い要素も戻り値から除かず for => '' のまま残す。呼び出し元 （resolveHttpsFlag() 等）は「クライアント IP の決定に採用した要素と同じ位置」の proto / host を読む必要があり、要素を間引くと配列のインデックスが pickClientAddr() の走査結果とずれてしまう。

Why not: preg_split('/,/') で単純に分割しない。quoted-string の内部にカンマや セミコロンを含められる（難読化識別子は quoted-string で送られうる）ため、引用の 内外を区別しない分割ではホップ境界を誤り、1 つのホップが 2 つに割れて信頼境界の 判定がずれる。

Why not: proto / host は for と違いポート表記を持たず、IP アドレスでもない （host は Host ヘッダ相当でポートを含みうる文字列そのもの）。そのため unquote() （内部で stripPort() を呼ぶ）ではなく、引用符の除去だけを行う unquoteRaw() を使う。

parseForwardedElements() の薄い射影で、クライアント IP の決定にしか使わない 呼び出し元（extractHops() 経由の pickClientAddr()）向けに for の値だけを返す。 proto / host も必要な場合は parseForwardedElements() を直接使う。

Why not: for が無い要素を空文字として残さない。pickClientAddr() の走査は 「ホップ列＝クライアント IP の候補」を前提にしており、for の無い要素を空文字で 混ぜるとそれ自体が「不正なホップ」として読み飛ばされ、信頼境界の判定がずれる （parseForwardedElements() 側は要素の対応関係を保つためあえて空文字を残す）。

Application はこの戻り値を定数へ反映するだけにし、クライアント IP・HTTPS・ サーバー名の信頼境界が別々に実装されないようにする。

Why not: 素の IPv6（コロンを複数含む）に対して末尾の :\d+ を単純に取り除くと、 2001:db8::1 の末尾 :1 がポート表記と誤認され 2001:db8: に破壊される。 そのため IPv4:port・[IPv6]:port・[IPv6]・コロン 1 個の IPv4:port のみを 明示的な形で判定し、それ以外（素の IPv6 含む）はそのまま返す。