「パスワードの送信にURLクエリパラメータを使ってはいけない」のは何故か？

Question

「パスワードの送信にURLクエリパラメータを使ってはいけない」のは何故か？

「パスワード等の機密情報をWebサーバーに送信する際は，URLクエリパラメータではなくPOSTのリクエストボディを使うべきである」
という主張を複数の書籍・サイトで見かけたことがありますが，この理由はなんでしょうか？

SSL/TLSを使わないhttp通信の場合は通信路でパケットを盗聴されるとリクエストの中身がすべて丸見えですから
POSTで送ったところで機密情報の保護には役に立ちません。

一方SSL/TLSを使った場合はクエリパラメータまで暗号化されるため，クエリパラメータで送ったところで
機密情報が盗み見られることはありません。(SSL/TLSに脆弱性が無い限り)

したがって個人的にはパスワードをクエリパラメータで送っても何の問題もないと思っているのですが，
表題の主張には何か理由があるものなのでしょうか？
よろしくお願いします。

Answer 1

ショルダーハッキングとか。

あと、他人にURLを伝えるときにコピペだけではだめ。パスワードとか消して伝えないといけない。
そういうことをITエンジニアでない一般ユーザーに伝えるのは困難。絶対に徹底できない。
まあ、他人にURLを伝えることが絶対に無いような種類のサイトだと良いかもですが、ちょっと想像つかないです。

Answer 2

一番わかり易いのは、bookmark を見ることで、id/pass がバレてしまうとか。
もう少し踏み込むと、アクセスログに id/pass が残るのもまずい。
等々。考慮しなければならない点が増えてしまいます。

Comments

[退会済みユーザー]

アクセスログに関しては、post でも残せちゃうけどそれはそれで＾＾；

Answer 3

質問者の主張は十分な時間や知識があれば、結局のところ見れてしまうから同じだろう？という主張だと理解した前提で回答します。

実際問題としては、URLに載っかってる情報というのは、HTTPリクエストのボディにあるデータより断然、覗き見やすいです。

例を上げて言うなら、ブラウザの履歴やアクセスログ等など、ハッキングの知識がない人であっても、容易に知ることができます。

また、人間というのは、普段、悪いことをしない人であっても、チャンスがあると誘惑にかられることもあります。（例えば、今まで一度たりとも物を盗んだことがない人であっても、金庫の暗証番号のヒントが書かれてる紙を偶然見つけてしまったら、人によっては誘惑に負けてしまう人だっているでしょう。本当に開けれるかどうかは別としても）

そういった相手に付け入る隙をなるべく与えないことは、意味はあるのです。

また、セキュリティは結局のところ、ここまでやれば、絶対に大丈夫なんてものはないので、コスト（労力）とエフェクティブ（効果）の兼ね合いなのです。今回のことでいえば、GETを使わずにPOSTを使うようにするのは、それほど労力はかからないと思うので、やるだけの意味はあるように思えます。

Answer 4

SSL/TLSストリームとして通信を見ると、そのどこにパスワードを含めても同じ(はず)ですが、HTTPプロトコル的にURLは他のヘッダやペイロードに比べて人に近いデータで、色々な所にさらされることが多いからじゃないでしょうか。

ログとかブラウザのアドレスバーとかリファラーとか。ユーザーが自分の見ている画面をほかの人にシェアしたくてURLをメールで送ったらパスワードがそこに含まれていたとか。

パスワードは相対的にさらされる頻度の低いペイロードに含めようって解釈もできるなぁと思います。

Answer 5

まだ質問を受け付けているようなのでお答えします。

他の方がおっしゃっているブラウザの履歴の問題はクライアント側でID/PWの組み合わせが漏洩してしまう問題ですよね。
サーバ側で漏洩を幇助してしまう理由としてはブラウザがリクエストを生成する際にRefererヘッダに遷移元のURLを付与してしまうことが原因です。
例えばGETパラメータでID/PWを認証するサービスでは、認証時のサービスからのリクエストは以下のようなURLになります。

https://hoge.com/login.html?id=uid001&passwd=pw12345

認証をした後のlogin.htmlのページから送信されるリクエストのRefererヘッダにはログイン時に送信したリクエストURLがGETパラメータごと付与されてしまいます。

GET / HTTP 1.1
~
Referer:https://hoge.com/login.html?id=uid001&passwd=pw12345
~

このRefererヘッダはリクエストヘッダに自動で付与されるため
認証後に別ドメインのURLへ遷移するような処理を行なっている場合、遷移先のサーバで有効なID/PWの組み合わせが漏洩します。

このRefererヘッダはchormeなどのデペロッパーツールを使うと容易に確認できます。

[Network]タブからURLを選択し、Headersの項目を参照する。

[補足]
ハッシュ化してから送信するという答えもありましたが、その場合クライアント側でハッシュ化を行うのであれば攻撃者にもハッシュアルゴリズムが漏洩します。

Answer 6

SSLで暗号化されていたとしても、サーバ側のアクセスログには平文で書かれてしまいます。

また、その参考にされた書籍がそもそも SSL が一般的ではない（技術はともかく、証明書発行が高かったり面倒だったりで普及していない）頃に書かれたものというのもあるかも知れません。
実際のところ、何でもかんでも SSL にしようというのは、Let's Encrypt などで手軽にオレオレでない証明書が発行できるようになったからではないでしょうか。

Answer 7

本気でハッキングしようと思ったらどちらにしろ同じですし、送信データをSSLの他に暗号化させてないのでどちらも不十分だと思います。ただ、セキュリティの概念(セキュリティとはハッキングしようとしている人が少しでも手間だと思うことをすること)に基づいたら、URLで記述するよりリクエストボディで送る方が手間だと感じます。
理由として、URLは自然と目につく部分のため、「なにかしている」というヒントを与えているのに対して、リクエストボディは見ようと思わなければ見ないですし、リクエストボディの方が解析するのは手間なためです。

Answer 8

getとpostはhtttp通信におけるメソッドであって、役割が全く異なります。
getは必要な情報をURLに記載することで情報を受け渡すものであり、postはヘッダーに情報を追記することで情報を渡します。
前者は情報量をURLだけに絞ることで、早く処理を行うとともに、同じURLを叩いたら同じ動的情報を取得することが可能ですが、文字数制限があるため多くの情報を送信することができません。
またパスワードは、送信された後、ハッシュ化されて DB に保存されます。ブラウザ上で入力した値とDBに保存される値が異なり、DBに登録されるのはhash化されたパスワードになります。hash化されたパスワードの正式な値を知る方法はソースコード上で復元される時のみなので、見られたからと言ってすぐに影響はでません。つまり、送信されたパスワードから対応するDBのレコードを探しても、どれがそれに該当するのかわからないようになっております。
あくまでも高速処理や大規模データ処理等、getメソッドである必要がある時のみgetメソッドを用いるのであり、それ以外の時はpostメソッドで送信するのが慣習です。

余談ですが、知人と話している時、知人の友人がガスコンロの上に衣服を干す人がいるという話を聞きました。知人の友人の言い分はガスの元栓閉めているから問題ないとのことでしたが、知人はもの凄く違和感を抱いたようです。いくら物理的に発火しないといっても、発火物の上に可燃物の衣服を置くのは多くの人に取って不快感を与えます。それと同じように、いくらセキュリティを強化してあるからと言って、getメソッドでパスワードを送信しようとするのは、多くのプログラマーに取って違和感を与えます。

何かしらgetを使いたい強い理由があればいいと思いますが、そのような理由は誰も思いつかないので、やらないほうがいいです。

Comments

[退会済みユーザー]

> 最近のコーディング規約ではパスワードはhash化してから送信を行います。

大変気になる情報なのですが、どのような仕組みで実装されているのでしょうか？

[zigutabi]

難しくないです、ハッシュ関数で検索すればすぐ出てきます。Javaはどうだか覚えておりませんが、PHPでは標準でついております。自分が勉強した時のものはもう非推奨ですが、パスワードハッシュ関数の引数にパスワード原文を入れれば簡単にできます。
http://php.net/manual/ja/function.password-hash.php

良くも悪くもハッシュ関数が具体的にどんな動きをしているのか、使用者本人が全く知らなくても実装できるのは、ソースコード上から逆算することができないので、メリットとも言えます。

[退会済みユーザー]

ブラウザでのハッシュ化の話だと思ったのですが、サーバサイドのハッシュ化の話のようですね＾＾；

回答として、表現が間違っているので訂正しておいてください。

> 最近のコーディング規約ではパスワードはhash化してから送信を行います。
→パスワードは、送信された後、ハッシュ化されて DB に保存されます。

> ブラウザ上で入力した値と送信される値が異なり
→ブラウザ上で入力された値と DB に保存される値は異なり

[zigutabi]

修正しました。勉強になりました。ありがとうございます。

Answer 9

urlにid/pwを引数として渡すと、webサーバのアクセスログにそれが記録されますし、ブラウザのアドレスバーにも表示され、履歴にも残り、ブックマークした際やurlをメールやlineなどで共有した際にid/pwも含まれてしまいます。

オンラインバンキングのサイトにログインしたらアドレスバーにid/pwが表示さるようなサイトは使いたくないですよね？