web-dev-qa-db-ja.com

HTTPSクエリ文字列は安全ですか?

HTTPSを使用する安全なWebベースのAPIを作成しています。ただし、クエリ文字列を使用してユーザーにパスワードの送信を含む設定を許可すると、これも安全になりますか、POSTを介して強制する必要がありますか?

320
John

はい、そうです。 ただし、機密データにGETを使用するのは悪い考えですいくつかの理由:

  • ほとんどの場合、HTTPリファラーの漏洩(ターゲットページの外部イメージがパスワードを漏洩する可能性があります[1])
  • パスワードはサーバーログに保存されます(明らかに悪いです)
  • ブラウザの履歴キャッシュ

したがって、クエリ文字列が保護されていても、クエリ文字列を介して機密データを転送することはお勧めしません。

[1] RFCでは、ブラウザがリファラーをHTTPSからHTTPに送信すべきでないと述べていることに注意する必要があります。しかし、それは悪いサードパーティのブラウザツールバーやHTTPSサイトからの外部画像/フラッシュがリークしないことを意味するものではありません。

418
dr. evil

「ネットワークパケットを盗聴する」という観点からは、ブラウザは最初にセキュアな接続を確立し、次にGETパラメータを含むリクエストを送信するため、GETリクエストは安全です。ただし、GET URLはユーザーのブラウザー履歴/オートコンプリートに保存されます。これは、たとえばもちろん、これはブラウザからサービスにアクセスする可能性のあるより広い「Webサービス」定義を使用する場合にのみ適用されます。カスタムアプリケーションからのみアクセスする場合、これは問題になりません。

したがって、少なくともパスワードダイアログには投稿を使用することをお勧めします。また、リンクで指摘されているように、littlegeekがGET URLを投稿すると、サーバーログに書き込まれる可能性が高くなります。

69
VolkA

はい、クエリ文字列は暗号化されます。

背後にある理由は、クエリ文字列がアプリケーション層プロトコルであるHTTPプロトコルの一部であり、セキュリティ(SSL/TLS)部分がトランスポート層から来ているためです。 SSL接続が最初に確立され、次にクエリパラメータ(HTTPプロトコルに属する)がサーバーに送信されます。

SSL接続を確立すると、クライアントは次の手順を順番に実行します。 example.comという名前のサイトにログインしようとして、クエリパラメータを使用して資格情報を送信するとします。完全なURLは次のようになります。

https://example.com/login?username=alice&password=12345)
  1. クライアント(ブラウザ/モバイルアプリなど)は、最初にDNS要求を使用してドメイン名example.comをIPアドレス(124.21.12.31)に解決します。その情報を照会する場合、ドメイン固有の情報のみが使用されます。つまり、example.comのみが使用されます。
  2. これで、クライアントはIPアドレス124.21.12.31を使用してサーバーに接続しようとし、ポート443(デフォルトのHTTPポート80ではなくSSLサービスポート)に接続しようとします。
  3. これで、example.comにあるサーバーがその証明書をクライアントに送信します。
  4. クライアントは証明書を検証し、セッションの共有秘密鍵の交換を開始します。
  5. 安全な接続が正常に確立された後、クエリパラメータが安全な接続経由で送信されます。

したがって、機密データは公開されません。ただし、この方法を使用してHTTPSセッションで資格情報を送信するのは最善の方法ではありません。別のアプローチをお勧めします。

37
Ruchira Randana

はい。 HTTPSセッションのテキスト全体がSSLで保護されています。これには、クエリとヘッダーが含まれます。その点で、POSTとGETはまったく同じです。

メソッドのセキュリティに関しては、適切な検査なしで言う本当の方法はありません。

25
shoosh

SSLは最初にホストに接続するため、ホスト名とポート番号はクリアテキストとして転送されます。ホストが応答し、チャレンジが成功すると、クライアントはHTTPリクエストを実際のURL(3番目のスラッシュ以降のもの)で暗号化し、サーバーに送信します。

このセキュリティを破る方法はいくつかあります。

「中間者」として動作するようにプロキシを構成することができます。基本的に、ブラウザはプロキシに実サーバーに接続する要求を送信します。プロキシがこのように構成されている場合、SSLを介して実サーバーに接続しますが、ブラウザーは引き続きプロキシと通信します。そのため、攻撃者がプロキシにアクセスできる場合、攻撃者はプロキシを流れるすべてのデータをクリアテキストで見ることができます。

リクエストはブラウザの履歴にも表示されます。ユーザーはサイトをブックマークしたいと思うかもしれません。一部のユーザーにはブックマーク同期ツールがインストールされているため、パスワードはdeli.ci.usまたは他の場所に置かれる可能性があります。

最後に、誰かがコンピューターをハッキングし、キーボードロガーまたはスクリーンスクレーパーをインストールした可能性があります(そして、多くのトロイの木馬型ウイルスがインストールします)。パスワードは画面に直接表示されるため(パスワードダイアログの「*」とは対照的に)、これは別のセキュリティホールです。

結論:セキュリティに関しては、常にalways地に頼ってください。あなたが知らない、考えない、そしてあなたの首を壊すものが多すぎます。

22
Aaron Digulla

はい、モニターを見ている人がいない限り。

10
Ali Afshar

[...] HTTPリファラーの漏洩(ターゲットページの外部イメージがパスワードを漏洩する可能性がある)に関するステートメントに同意しませんin Slough's response

HTTP 1.1 RFC 明示的に述べています

参照ページがセキュアなプロトコルで転送された場合、クライアントは(非セキュアな)HTTPリクエストにRefererヘッダーフィールドを含めるべきではありません。

とにかく、サーバーログとブラウザーの履歴は、クエリ文字列に機密データを入れない十分な理由です。

9
Arnout

はい、HTTPS接続を確立した瞬間からすべてが安全です。 POSTとしてのクエリ文字列(GET)がSSL経由で送信されます。

8
Drejc