タイトルの内容を思ったきっかけは社内勉強会で体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践を読んだことでした
改めてなぜダメなのかと言われるとしっかり根拠を持って説明できないなと思い調べてみました
Getでもいいのかなと思ったパターンは以下のようなケースです
例えば、会員登録機能などで確認画面から戻るボタンで入力フォームに遷移する場合に、入力した内容をそのまま保持したままにしたい。その際にはHTTPSの場合であればGetで戻っても大丈夫なのかな？
GetとPostの使い分けはどういう場合？
GetとPostの使い分けは以下のようなケースの場合で考えればいいようです
- Getメソッドは参照（リソースの取得）のみに用いる
- Getメソッドは副作用がないことが期待される
- 秘密情報の送信にはPOSTメソッドを用いること
引用：安全なWebアプリケーションのつくり方 p.35
HTTPSでもRefererから秘密情報は漏れる
https: から http: へのリンクでは、 Referer: は送らないことになっています。これを利用して、漏らしたくない URL を含むホスト全体を https で提供すれば、 http: URL への参照があっても Referer: の送信を抑制できます。
引用：Referrer を制御するただし、 https: のページへの Referer: は送信されてしまいます。 https: 化することで Referer: が送信されなくなったと安心してしまいがちですが、実際には対策として不完全で、危険です。
引用：Referrer を制御する
そのページに外部リンクがある場合、上記理由からReferrerで個人情報が流出してしまう問題からPOSTで遷移するのがよいみたいです
以下は検索機能がある画面で画像が表示されている箇所があったので、chromeディベロッパーツールから見てみると外部リンクの画像へのアクセスでReferrerから検索パラメータが付加されて送られていました
個人情報がアクセスログに残る
Getの場合には、パラメータに付加した個人情報がログに書き込まれてしまう為に、アクセスログの漏洩にも気を使わないといけなくなってしまうというところでリスクが更に高くなってしまう問題があるようです
以下は実際の Web サーバー(Apache)のアクセスログですが、GET メソッドのためパラメーターがアクセスログに残ってしまっていることが分かります。
192.168.11.2 - - [24/Feb/2013:07:16:48 +0900] "GET /hello.php?id=yamada&password=password HTTP/1.1" 200 105 "http://192.168.11.9/login.php" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17"
引用：Webセキュリティの小部屋