HTTPSクエリ文字列は安全ですか？
HTTPSを使用する安全なWebベースのAPIを作成しています。ただし、クエリ文字列を使用してユーザーにパスワードの送信を含む設定を許可すると、これも安全になりますか、POSTを介して強制する必要がありますか？
はい、そうです。 ただし、機密データにGETを使用するのは悪い考えですいくつかの理由：
- ほとんどの場合、HTTPリファラーの漏洩（ターゲットページの外部イメージがパスワードを漏洩する可能性があります[1]）
- パスワードはサーバーログに保存されます（明らかに悪いです）
- ブラウザの履歴キャッシュ
したがって、クエリ文字列が保護されていても、クエリ文字列を介して機密データを転送することはお勧めしません。
[1] RFCでは、ブラウザがリファラーをHTTPSからHTTPに送信すべきでないと述べていることに注意する必要があります。しかし、それは悪いサードパーティのブラウザツールバーやHTTPSサイトからの外部画像/フラッシュがリークしないことを意味するものではありません。
「ネットワークパケットを盗聴する」という観点からは、ブラウザは最初にセキュアな接続を確立し、次にGETパラメータを含むリクエストを送信するため、GETリクエストは安全です。ただし、GET URLはユーザーのブラウザー履歴/オートコンプリートに保存されます。これは、たとえばもちろん、これはブラウザからサービスにアクセスする可能性のあるより広い「Webサービス」定義を使用する場合にのみ適用されます。カスタムアプリケーションからのみアクセスする場合、これは問題になりません。
したがって、少なくともパスワードダイアログには投稿を使用することをお勧めします。また、リンクで指摘されているように、littlegeekがGET URLを投稿すると、サーバーログに書き込まれる可能性が高くなります。
はい、クエリ文字列は暗号化されます。
背後にある理由は、クエリ文字列がアプリケーション層プロトコルであるHTTPプロトコルの一部であり、セキュリティ（SSL/TLS）部分がトランスポート層から来ているためです。 SSL接続が最初に確立され、次にクエリパラメータ（HTTPプロトコルに属する）がサーバーに送信されます。
SSL接続を確立すると、クライアントは次の手順を順番に実行します。 example.comという名前のサイトにログインしようとして、クエリパラメータを使用して資格情報を送信するとします。完全なURLは次のようになります。
https://example.com/login?username=alice&password=12345)
- クライアント（ブラウザ/モバイルアプリなど）は、最初にDNS要求を使用してドメイン名
example.comをIPアドレス(124.21.12.31)に解決します。その情報を照会する場合、ドメイン固有の情報のみが使用されます。つまり、example.comのみが使用されます。 - これで、クライアントはIPアドレス
124.21.12.31を使用してサーバーに接続しようとし、ポート443（デフォルトのHTTPポート80ではなくSSLサービスポート）に接続しようとします。 - これで、
example.comにあるサーバーがその証明書をクライアントに送信します。 - クライアントは証明書を検証し、セッションの共有秘密鍵の交換を開始します。
- 安全な接続が正常に確立された後、クエリパラメータが安全な接続経由で送信されます。
したがって、機密データは公開されません。ただし、この方法を使用してHTTPSセッションで資格情報を送信するのは最善の方法ではありません。別のアプローチをお勧めします。
はい。 HTTPSセッションのテキスト全体がSSLで保護されています。これには、クエリとヘッダーが含まれます。その点で、POSTとGETはまったく同じです。
メソッドのセキュリティに関しては、適切な検査なしで言う本当の方法はありません。
SSLは最初にホストに接続するため、ホスト名とポート番号はクリアテキストとして転送されます。ホストが応答し、チャレンジが成功すると、クライアントはHTTPリクエストを実際のURL（3番目のスラッシュ以降のもの）で暗号化し、サーバーに送信します。
このセキュリティを破る方法はいくつかあります。
「中間者」として動作するようにプロキシを構成することができます。基本的に、ブラウザはプロキシに実サーバーに接続する要求を送信します。プロキシがこのように構成されている場合、SSLを介して実サーバーに接続しますが、ブラウザーは引き続きプロキシと通信します。そのため、攻撃者がプロキシにアクセスできる場合、攻撃者はプロキシを流れるすべてのデータをクリアテキストで見ることができます。
リクエストはブラウザの履歴にも表示されます。ユーザーはサイトをブックマークしたいと思うかもしれません。一部のユーザーにはブックマーク同期ツールがインストールされているため、パスワードはdeli.ci.usまたは他の場所に置かれる可能性があります。
最後に、誰かがコンピューターをハッキングし、キーボードロガーまたはスクリーンスクレーパーをインストールした可能性があります（そして、多くのトロイの木馬型ウイルスがインストールします）。パスワードは画面に直接表示されるため（パスワードダイアログの「*」とは対照的に）、これは別のセキュリティホールです。
結論：セキュリティに関しては、常にalways地に頼ってください。あなたが知らない、考えない、そしてあなたの首を壊すものが多すぎます。
はい、モニターを見ている人がいない限り。
[...] HTTPリファラーの漏洩（ターゲットページの外部イメージがパスワードを漏洩する可能性がある）に関するステートメントに同意しませんin Slough's response 。
HTTP 1.1 RFC 明示的に述べています ：
参照ページがセキュアなプロトコルで転送された場合、クライアントは（非セキュアな）HTTPリクエストにRefererヘッダーフィールドを含めるべきではありません。
とにかく、サーバーログとブラウザーの履歴は、クエリ文字列に機密データを入れない十分な理由です。
はい、HTTPS接続を確立した瞬間からすべてが安全です。 POSTとしてのクエリ文字列（GET）がSSL経由で送信されます。