Scribble at 2026-10-20 09:34:24 Last modified: unmodified

弊社のコーポレート・サイトでは HTML ファイルを PHP としてパースしているし、問い合わせフォームではガチでプログラムを使っているので、このところの情報漏洩事件の続発に鑑みてコードを Gemini に検証させてみた。

POST の値を捏造して /submit.php へと直にアクセスしてくる馬鹿どもを斥けるために、たいていはセッションを使っていることだろう。index.html で発行し Cookie に格納した値と、submit.php へ送られてくる POST の値を比較して、合致しなければリクエストを破棄するという仕掛けである。もちろん、リプライ攻撃などの標的にもなるから、セッションの扱いそのものも厳格にする必要があるため、設定を調整しておくのが望ましい。これは既にやっていることだ。

次に、弊社のサイトでは問い合わせ内容を全くサーバに保管しておらず、送信された情報はただちにメールで ML のアカウントに送信されるか、Google Chat の専用スペースへ Webhook で送出される。出版・取材・番組出演を勧める詐欺師ども（一律に断定している。こんな営業について擬陽性を疑う必要はない）や、20年前のアダルト・サイトみたいに相互リンクを求めてくる馬鹿の問い合わせは、ドメインや本文の文言などを条件として、こちらで勝手に破棄している。このとき、Webhook の URL はプライベートなスペースへのアクセス・キーでもあるため、PHP ファイルにハード・コーディングしていると危険である。なんらかの事情で PHP が動かなくなったときや Apache の動画に問題があったときなどに、PHP ファイルのソースがパースされずに丸見えになることもあるからだ。

こういう場合、WordPress の wp-config.php のように、DocumentRoot の上の階層に秘密情報を記載したファイルを置いて require() などで読み込むという方法もあるが、それ以外にも幾つかやり方はあって、僕が採用しているのは Apache の環境変数としてロードするという手法だ。/etc/httpd/conf.d/virtual.conf などの <VirtualHost> ディレクティブに Webhook の URL を特殊な環境変数として定義しておき、PHP において $_SERVER の値として呼び出すというわけである。これなら、別の PHP ファイルなどを require() するときにパスを記載して、どのみち場所がバレてしまうという心配がない。

といったことをやっているので、いまのところ Gemini に検査させても明白な脆弱性はないようだ。