403

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

4

9 に答える 9

507

はい、そうです。ただし、機密データに GET を使用することは、いくつかの理由からお勧めできません。

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

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

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

于 2008-11-27T09:11:34.057 に答える
89

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

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

于 2008-11-27T08:29:42.923 に答える
67

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

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

于 2016-03-28T06:52:42.963 に答える
31

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

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

于 2008-11-27T08:24:36.647 に答える
28

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

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

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

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

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

結論: セキュリティに関しては、常に人里離れた道に頼ってください。知らないこと、考えないこと、首を痛めることになることが多すぎます。

于 2008-11-27T08:45:19.603 に答える
13

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

于 2008-11-27T11:17:52.540 に答える
12

Slough's response の[ ...] HTTP リファラー漏洩 (ターゲット ページの外部画像からパスワードが漏洩する可能性がある)に関する声明には同意しません。

HTTP 1.1 RFCは明示的に次のように述べています。

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

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

于 2008-11-27T09:40:29.163 に答える
9

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

于 2008-11-27T08:24:56.227 に答える
-5

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

于 2012-11-08T02:00:56.220 に答える