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

HTTPSを使用する安全なWebベースのAPIを作成しています。ただし、クエリ文字列を使用してユーザーにパスワードの送信を含めるように構成することを許可する場合、これも安全ですか、それともPOSTを介して実行する必要がありますか？

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

• 主にHTTPリファラーのリーク（ターゲットページの外部画像がパスワードをリークする可能性があります[1]）
• パスワードはサーバーログに保存されます（これは明らかに悪いです）
• ブラウザの履歴キャッシュ

したがって、Querystringは保護されていますが、機密データをquerystring経由で転送することはお勧めしません。

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

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

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

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

背後にある理由は、クエリ文字列はアプリケーション層プロトコルである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セッションで認証情報を送信することは、最善の方法ではありません。別のアプローチをとるべきです。

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

メソッドのセキュリティについては、適切な検査なしでは言うことはできません。

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

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

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

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

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

結論：セキュリティに関しては、常に人道に頼ってください。あなたが知らない、考えられない、そしてあなたの首を骨折するものが多すぎる。

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

Sloughの応答における[...] HTTPリファラーの漏洩（ターゲットページの外部画像がパスワードを漏洩する可能性がある）に関する記述に同意しません。

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

参照ページがセキュアなプロトコルで転送された場合、クライアントは（非セキュアな）HTTPリクエストにリファラーヘッダーフィールドを含めないでください。

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

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

パスワードをMD5ハッシュパラメータとして送信し、ソルトを追加できます。サーバー側で認証を比較します。