web-dev-qa-db-ja.com

セキュリティ上の懸念は、httpsを介したGETリクエストを使用したパスワードの送信に有効ですか？

sapui5 -frameworkを使用して spa を構築するWebページがあります。ブラウザとサーバー間の通信は https を使用します。ページにログインするための対話は次のとおりです。

  1. ユーザーがブラウザにhttps://myserver.comと入力してWebサイトを開きます
  2. Unsernameとpasswordの2つのフォームフィールドを持つログインダイアログが表示されます。
  3. usernameとpasswordを入力し、login-buttonを押した後
  4. ajaxリクエストはGETを使用してURLに送信されます：https://myusername:[email protected]/foo/bar/metadata

私の理解によれば、GETを使用して機密データを送信することは決して良い考えではありません。しかし、この答えは HTTPSはURL文字列が安全です は次のように述べています

HTTPS Establishes an underlying SSL conenction before any HTTP data is
transferred. This ensures that all URL data (with the exception of
hostname, which is used to establish the connection) is carried solely
within this encrypted connection and is protected from
man-in-the-middle attacks in the same way that any HTTPS data is.

同じスレッドの別の答え：

These fields [for example form field, query strings] are stripped off
of the URL when creating the routing information in the https packaging 
process by the browser and are included in the encrypted data block.

The page data (form, text, and query string) are passed in the
encrypted block after the encryption methods are determined and the
handshake completes.

しかし、 get を使用した場合、セキュリティ上の懸念がまだあるようです。

これは、次のようなURLに当てはまりますか？

    https://myusername:[email protected]/foo/bar/metadata
    // or 
    https://myserver.com/?user=myUsername&pass=MyPasswort

このトピックに関する追加の質問：

Security.stackexchangeには追加情報があります。

しかし、私の意見では、いくつかの側面はまだ答えられていません

質問

私の意見では、上記の点はgetを使用しないことの正当な異論です。事実です。パスワードの送信にgetを使用することは悪い考えですか？

これらは攻撃オプションですか、それ以上ですか？

  • ブラウザの履歴
  • サーバーログ（URLが暗号化されていないか暗号化されたログに保存されていると想定）
  • リファラー情報（これが実際に当てはまる場合）

Getを使用してhttps経由で機密データ（パスワード）を送信する場合、どの攻撃オプションが存在しますか？

ありがとう

securityauthenticationsslhttpssapui5
23
surfmuggle

これらの2つのアプローチは基本的に異なります。

  • https://myusername:[email protected]/foo/bar/metadata
  • https://myserver.com/?user=myUsername&pass=MyPasswort

myusername:myPassword@は "ユーザー情報" （このフォームは実際には最新のURI RFCでは非推奨）ですが、?user=myUsername&pass=MyPasswortはクエリの一部です。

RFC 3986のこの例を見ると、次のようになります。

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment
      |   _____________________|__
     / \ /                        \
     urn:example:animal:ferret:nose

myusername:myPassword@はauthorityの一部です。実際には、HTTP（基本）認証ヘッダーを使用して、通常、この情報を伝えます。サーバー側では、通常、ヘッダーはログに記録されません（ログに記録される場合、クライアントがそれらをロケーションバーに入力したか、入力ダイアログを介して入力したかに関係なく、違いはありません）。一般に（実装に依存しますが）、ブラウザーはそれをロケーションバーに保存しないか、少なくともパスワードを削除します。 Chromeはサポートしていません（そして IEは回避策なしにそれらを実際にサポートしていません ）一方で、Firefoxはユーザー履歴をブラウザの履歴に保持しているようです

対照的に、?user=myUsername&pass=MyPasswortはqueryであり、URIのより重要な部分であり、 HTTP Request-URI 。これは、ブラウザの履歴とサーバーのログに記録されます。これもリファラーで渡されます。

簡単に言うと、myusername:myPassword@は、機密性の高い情報を伝えるように明確に設計されており、ブラウザは通常、これを適切に処理するように設計されていますが、ブラウザは、機密性の高いクエリとそうでないクエリの部分を推測できません。そこに情報漏えい。

HTTPSページからのRefererヘッダーは通常、HTTPS上の他のリクエストとともに同じホストにのみ送信されるため、リファラー情報は一般に第三者に漏洩しません。 （もちろん、https://myserver.com/?user=myUsername&pass=MyPasswortを使用した場合、これは同じホストのログに記録されますが、同じサーバーログに残るため、それほど価値はありません。）

これは HTTP仕様（セクション15.1.3） で指定されています。

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

これは単なる「SHOULD NOT」ですが、Internet Explorer、ChromeおよびFirefoxはこのように実装しているようです。これが1つのホストから別のホストへのHTTPSリクエストに適用されるかどうかは、ブラウザとそのバージョンによって異なります。

この質問 と このドラフト仕様 で説明されているように、<meta>ヘッダーを使用してこの動作を上書きすることが可能になりましたが、とにかく?user=myUsername&pass=MyPasswortを使用する機密ページ。

残りの HTTP仕様（セクション15.1.3） も関連することに注意してください。

HTTPプロトコルを使用するサービスの作成者は、機密データの送信にGETベースのフォームを使用しないでください。これにより、このデータがRequest-URIでエンコードされるためです。多くの既存のサーバー、プロキシ、およびユーザーエージェントは、リクエストURIを第三者に見える可能性がある場所に記録します。サーバーは代わりにPOSTベースのフォーム送信を使用できます

?user=myUsername&pass=MyPasswortを使用することは、GETベースのフォームを使用することとまったく同じです。Refererの問題を封じ込めることはできますが、ログと履歴に関する問題は残ります。

21
Bruno

HTTPSであっても、GETを介してあらゆる種類の機密データを送信することは危険です。これらのデータは、サーバーのログファイルに保存される可能性があり、他の側へのリンクまたは他の側からの参照のヘッダーに含まれます。それらはブラウザの履歴にも保存されるため、攻撃者はリンクの元のコンテンツを推測して検証し、履歴に対する攻撃を試みる可能性があります。

それとは別に、そのような質問はsecurity.stackexchange.comで行うほうがよいでしょう。

25
Steffen Ullrich

このことを考慮：

https://www.example.com/login

ログインページ内のJavascript：

$.getJSON("/login?user=joeblow&pass=securepassword123");

今、リファラーは何でしょうか？

セキュリティが心配な場合、追加のレイヤーは次のようになります。

var a = Base64.encode(user.':'.pass);
$.getJSON("/login?a="+a);

暗号化されていませんが、少なくともデータは単純に見えません。

0
Jay

ユーザーがボタンをクリックし、クライアントブラウザによって生成された次のリクエストを想定します。

https://www.site.com/?username=alice&password=b0b12 ！

[〜＃〜] https [〜＃〜]

まず最初に。 HTTPSはこのトピックとは関係ありません。 POSTまたはGETの使用は攻撃者の観点からは重要ではありません。攻撃者はクエリ文字列から直接機密データを取得したり、トラフィックがHTTPの場合は直接POSTリクエスト本文を取得したりできます。そのため違いはありません。

サーバーログ

Apache、Nginx、またはその他のサービスがすべてのHTTPリクエストをログファイルに記録することはわかっています。つまり、クエリ文字列（？username = alice＆password = b0b123！）がログファイルに書き込まれます。システム管理者もこのデータにアクセスしてすべてのユーザー資格情報を取得できるため、これは危険な場合があります。また、アプリケーションサーバーが侵害された場合にも別のケースが発生する可能性があります。パスワードをハッシュ化して保存していると思います。 SHA256のような強力なハッシュアルゴリズムを使用すると、クライアントのパスワードはハッカーに対してより安全になります。しかし、ハッカーはログファイルに直接アクセスして、非常に基本的なシェルスクリプトを使用してプレーンテキストとしてパスワードを取得できます。

参照者情報

クライアントはリンクの上で開いていると想定しました。クライアントブラウザがhtmlコンテンツを取得して解析しようとすると、イメージタグが表示されます。この画像は、ドメイン外でホストできます（ポストイメージまたは類似のサービス、またはハッカーの制御下にあるドメインを直接）。ブラウザは画像を取得するためにHTTPリクエストを行います。しかし、現在のURLは https://www.site.com/?username=alice&password=b0b12 ！紹介者情報になります！

つまり、アリスと彼女のパスワードは別のドメインに渡され、Webログから直接アクセスできます。これは本当に重要なセキュリティ問題です。

このトピックは、セッション固定の脆弱性を思い出させます。セッションとほぼ同じセキュリティ上の欠陥については、次のOWASPの記事をお読みください。 （ https://www.owasp.org/index.php/Session_fixation ）読んでおく価値があります。

0
Mehmet Ince

コミュニティは考慮事項について幅広い見解を提供してきましたが、上記はこの問題に関するものです。ただし、GETリクエストでは、一般に認証が必要な場合があります。上記のように、ユーザー名/パスワードをURLの一部として送信することは決して正しいことではありませんが、通常、これは認証情報の通常の処理方法ではありません。リソースの要求がサーバーに送信されると、サーバーは通常、応答の401および認証ヘッダーで応答します。これに対して、クライアントは（基本スキームで）認証情報を含む承認ヘッダーを送信します。これで、クライアントからのこの2番目の要求はPOSTまたはGET要求になる可能性があります。それを妨げるものは何もありません。したがって、通常、これは要求タイプではなく、情報を通信するモードが問題です。

参照 http://en.wikipedia.org/wiki/Basic_access_authentication

0
Ironluca