水無月ばけらのえび日記

ユーザが確認したソースとブラウザが解釈しているソースが同一でなければならないので、ソースの確認方法に注意が必要かもしれません。

yuuさんのところで出ていたこれですか?

http://www.web-standards.jp/apply/form_cm.html

送り先は思いっきりASPのような気がしますが(私が攻撃を受けて送り先を差し替えられているのでなければ)。

https://www.mshonin.com/

たとえスクリプトをオフにしていたとしても、ブラウザの謎の仕様や不具合によってform要素のaction属性で指定されているURLとは別のURLにPOSTされることは否定できません。安全性を重視するのならば、信頼できないリソースはどこまでも信頼できないと考るべきでしょう。

要するに自分と自分が信頼した相手以外の第三者が関わっていることを否定できなければ危険というわけで、相手側がその手段を提供してくれないのならば、自らがそれを用意すれば解決できるはずです。用意できるものであれば。

今回の場合、その可能性が否定できないのは送信フォームだけなので、それを信頼できるものに、つまり自分でそのフォームが送るはずのクエリーと同様のクエリーを意図したURLに送信するHTMLを自らの手で記述し、それを使用すれば解決できるような気がします。

>yuuさんのところで出ていたこれですか?

　元々はその話です。

　しかし、いろいろ考えて条件を追加していったら、既にそのフォームでは絶対無理という結論になっています。

　ので、もはや単なる思考実験と化しています。

>たとえスクリプトをオフにしていたとしても、ブラウザの謎の仕様や不具合によってform要素のaction属性で指定されているURLとは別のURLにPOSTされることは否定できません。

　そんなブラウザの不具合があれば、フォームが https でも駄目だと思いますが。

>今回の場合、その可能性が否定できないのは送信フォームだけなので、それを信頼できるものに、つまり自分でそのフォームが送るはずのクエリーと同様のクエリーを意図したURLに送信するHTMLを自らの手で記述し、それを使用すれば解決できるような気がします。

　まあ、スクリプト無効だと使えない系のフォームを使わなければいけない場合は、そういうことを良くやるわけですが。

　ただ、その HTML を何処に置くかという問題はありますね。受け側が Referer を見たりしていると駄目だったり。

>ユーザが確認したソースとブラウザが解釈しているソースが同一でなければならないので、ソースの確認方法に注意が必要かもしれません。

　ですね。微妙に invalid になっている場合とか……。

>>たとえスクリプトをオフにしていたとしても、ブラウザの謎の仕様や不具合によってform要素のaction属性で指定されているURLとは別のURLにPOSTされることは否定できません。

>

>　そんなブラウザの不具合があれば、フォームが https でも駄目だと思いますが。

結果としては駄目ではありますが、それは自分が信頼したサイトと自分が信頼したユーザーエージェントがもたらした結果であって、信頼していない第三者が介入してセキュアでない結果をもたらした訳ではありません。

なので信頼したサイトが提供しているフォームがアレな動作をしたとしても、それはサイト自体がやられてしまっているとか、管理が杜撰で個人情報が漏れまくりというのと同じであって、通信経路に第三者が割り込んで改竄しているという問題とは別のものです。

で、その第三者による改竄の内容としてブラウザの謎の仕様や不具合を突くものというものも十分に考えられますし、安全を考えるならばその可能性すらも考える必要があるはずです。

>　まあ、スクリプト無効だと使えない系のフォームを使わなければいけない場合は、そういうことを良くやるわけですが。

>　ただ、その HTML を何処に置くかという問題はありますね。受け側が Referer を見たりしていると駄目だったり。

ブラウザを使ってクエリーを送信しなければならない決まりは無いので、そういう場合は人間ユーザーエージェントで対応するとか。まあ、そこまでして利用したいと思うようなサービスというのは無いとは思いますが。