質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.93%

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

受付中

回答 9

投稿

  • 評価
  • クリップ 9
  • VIEW 23K+

TYouichi

score 6

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

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

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

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

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

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 9

+11

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/01/31 22:35

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

    キャンセル

+11

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+7

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+7

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

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

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+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の項目を参照する。

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

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+4

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+3

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+2

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

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

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

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/02/06 19:03

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

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

    キャンセル

  • 2018/02/06 20:18

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

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

    キャンセル

  • 2018/02/06 20:46

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

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

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

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

    キャンセル

  • 2018/02/06 22:51

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

    キャンセル

0

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.93%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る