機密データをURIに隠す

私たちがこれをすることを要求されるかどうかは決定されていないので、これは潜在的に仮定の質問ですが、私はそれがより頻繁に出てくる質問であると思います。

バックグラウンド

RESTfulサービスを実装する際の標準的なアプローチは、URIにリソース私は restafarian ではありませんが、このアプローチには利点がたくさんあります。の利点。

問題

当社は特定の種類の情報を保護することをめぐる規制要件の対象となっています。基本的なRESTの公式に従うと、これらの保護された要素のいくつかはリソースパスに入ります。

TLSは、URLが暗号化されているための懸念のほとんどをカバーします。ただし、それらが平文で保管される可能性がある場所はいくつかあります。特にそれらはデフォルトでアクセスログに書かれることが多く(これは便利です)、そして人々がこれのためにブラウザを使うならば、彼らは彼らの閲覧履歴の中に平文で保存されることができます。

アプローチ

Assuming this is an issue and we want to use such an アプローチ it seems there is one prime contender for the solution, which is to encrypt parts of the URI or all of it. Hashing does not seem to be an option since the data is highly predictable and calculating the entire set of values is easy. Encrypting the entire URI will limit a lot of the advantages of the アプローチ. Symmetric encryption requires distributing a secret key widely and therefore defeats the purpose. The option that seems the best is to encrypt on the sensitive data with a public key.

私が理解しているように、あなたの暗号化された出力は、少なくともモジュラスの長さである限り必要です。したがって、2048ビットのキーを使用する場合、各データは少なくとも256バイトである必要があります。これはかなり長いURIになりますが、私はそしてその限界は実際に私達の解決策に適用されないかもしれません。

Does this アプローチ seem valid and/or is there anything else I am missing? Would it be valid to use the same key-pair that would be used for TLS? There probably needs to be some other information in the encrypted portion to avoid replay attacks or mapping an encrypted value back to given key, correct?

NOTE: I should mention that for my specific 問題, only authenticated parties would be able to call. This is not something that we mean to be expose on the public internet although mistakes can happen. All parties involved are legally-bound to protect the data. I think it's worth exploring more general usage of such an idea because of the growing popularity of RESTful services.

5
@ billc.cnこれは間違いなく実行可能ですが、この質問の範囲はRESTスタイルのインターフェースにとどまる必要があると思います。私があなたが提案する解決策が、少なくとも単純な方法ではなく、そのモデルに本当にあてはまるとは思わない。
追加された 著者 nikky,
@LamonteCristoそうは思わない。それはセッションのようなものではなく、優れたサービスデザインのように、ステートレスです。
追加された 著者 nikky,
@JulianKnight仲介者は暗号化されたURIをどのように入手するのでしょうか。
追加された 著者 nikky,
@dandavisもしあなたがサーバーサイドセッションを意味するのであれば、それはありません。セッションは冗長です。
追加された 著者 nikky,
他の答えに同意してください。これはあらゆる面で悪いアプローチです。 URIは機密データを保持するようには設計されていません。実際、正反対のことが言えます。フロントエンドシステムの鍵の安全性を保証することはできません。また、クライアントとサーバーの間でURIを記録する可能性がある、または可能性がある(インターネットの使用を想定した)システムが多数存在する可能性があります。 TLSは役に立ちますが、その問題を解決するわけではありません。
追加された 著者 user1593858,
ハッシュの前に機密情報をsessionIDと連結する場合はハッシュを使用できますが、単にトークンを使用します。
追加された 著者 dandavis,
代替案を提供できますか:トークン/署名付きのリクエストと引き換えにアクセスしたいリソースのIDでPOSTを行い、それを後者のGETに使用します。このようにして、各URLをログに記録してアクセスを追跡することができますが、ここに漏れる単一の秘密鍵はありません。
追加された 著者 billc.cn,

5 答え

解決策には、次のようなものがあります。   URIの一部または全部を暗号化します。ハッシュはそうではないようです   データは非常に予測可能で、全体を計算するためのオプション   値の設定は簡単です。 URI全体を暗号化すると、多くのことが制限されます。   アプローチの利点対称暗号化には   秘密鍵を広く配布するため、その目的が無効になります。   最善と思われるオプションは、機密データを暗号化することです。   公開鍵を使って。

あなたの論理は正しいです。

私はあなたが提案するとおりに機能する製品を1つ知っています。機密データはJavascriptコードによってエンドユーザのブラウザで暗号化され、 'key = value'パラメータのペアの一部に公開鍵暗号化されたbase64エンコード文字列が含まれるHTTPS GET要求が行われます。

利点は、機密データが復号化されることなく、これらの要求が複数のTLSエンドポイントを持つネットワークを介して渡されることができ、中間のWebサーバーログまたはプロキシが機密データにアクセスできないことです。

このアプローチは有効に思えますか、それとも他に何か欠けているものはありますか?

それは有効ですが、ここであなたが見逃したくないものがあります:

  1. 暗号化を実行するのに十分なインテリジェンスを持つクライアントが必要です。それはJavascript、あるいはカスタムアプリ、あるいは何かを意味します。
  2. 自分の暗号を転がさないでください。しっかりとした信頼できるライブラリを使用して、アプリのコードレビューを入手してください。
  3. 鍵管理。鍵を生成し、鍵を公開し、鍵を回転させ、そして鍵を撤回する必要があります。それを正しく行うには、データの制御を失うこととデータへのアクセスを失うことのバランスがとれます。 >

TLSに使用されるのと同じキーペアを使用することは有効ですか?

私はそれに対してお勧めします。 「暗号システムをオーバーロードしない」という一般的な経験則とは別に、その鍵が「信頼されていない」場合もあります。私が遭遇したことの1つは、DDoS攻撃軽減サービスは、攻撃の際にトラフィックに直面しているのであれば、Web証明書と鍵のコピー を持っていることを好むことが多いということです。

おそらく暗号化された部分に他の情報が必要です   リプレイ攻撃を防ぐために

場合によります;作業しているRESTトランザクションがべき乗であれば、それほど重要ではありません。それが何かを変えるならば、そう、そう、再生保護はより重要です。

または暗号化された値を特定のキーにマッピングしなおしますか?

はい、それは絶対に必要というわけではありません - あなたが使用する鍵の数や、それらのOUPとRUPの末尾の長さによっては異なります。しかし、どの鍵を推測しなくてもいいのです。

5
追加された
@ gowenfawr良い点です。これが過去の失敗にどのようにつながるかのいくつかの例に興味があります。それほど問題でない場合は、回答にリンクを追加してもらえますか。
追加された 著者 nikky,
@gowenfawr私の場合、キーはregに基づいて技術的に敏感なものからかなり敏感なものまで、そしてGETからの応答はかなり敏感なものから非常に大規模なもの(神聖なたわごと!)までの範囲です。そのため、URLを取得してGETを実行できるのは、POSTを再生するよりもおそらく大したことです。無効な条件を作成して手動でレビューするためです。それでは、同じTLSキーを使用しない理由は他にありますか?
追加された 著者 nikky,
@制限なし、クライアント証明書を使用して実現する可能性があります。クライアント呼び出しのほとんどは他のサーバーからのものです。機密データは一般に他の人々に関するものであり、重大な違約金を伴いながらそれを保護する法律があります。
追加された 著者 nikky,
@Limitすべてのユーザーが認証され、権限がチェックされますが、それは同じ要求をする権利がないという意味ではありません。だれかがキーYについてXに要求を出したという事実はそれ自体敏感かもしれません。ユーザーとクライアントのIDをリクエストとタイムスタンプに追加することで、同じキーに対する各リクエストは異なるURIを持つようになります。
追加された 著者 nikky,
@Limitリプレイの懸念は、誰かがURIをつかむことができれば、彼らがそれに対してGETを実行し、機密データを識別することになるかもしれないレスポンスデータを得ることができるということです。
追加された 著者 nikky,
「私が遭遇したのは、DDoS対策サービスがWeb証明書とキーのコピーを持つことを好むことが多いことです」その場合、通信全体が危険にさらされることはないでしょうか。レスポンスで返されるコンテンツは、URL内のキーよりはるかに機密性が高く、それらのキーが多くの場合、またはほとんどの場合に何であったのかを明らかにします。
追加された 著者 nikky,
この質問の原動力となる基本的な条件は、TLSを使用してもログとキャッシュがデータを漏らす可能性があることから、要求の内容をどのように保護するかということです。
追加された 著者 gowenfawr,
私はクレジットカードのデータに精通しているソフトウェアの@JimmyJamesが入って、低価値の小切手が出て行くので、返品データについては心配ありません。明らかにそれはアプリケーションによって異なります。この問題は、万能というわけではありません。 (そして、率直に言って、あなたの鍵を必要とするDDoSプロバイダーは私にあらゆる種類の方法を思い出させます)。
追加された 著者 gowenfawr,
@JimmyJamesが唯一の真の理由は「ベストプラクティス」です。歴史上、キーをオーバーロードすると失敗する可能性があることを繰り返し教えてきました。そして、私が「ベストプラクティス」と言うとき、それを意味することを忘れないでください。
追加された 著者 gowenfawr,
彼らがTLSを使用しているなら、再生検出はすでにカバーされています。そうじゃない?
追加された 著者 Limit,
@JimmyJamesあなたが個人情報の漏洩を心配している場合、あなたは役割ベースのアクセスシステムを実装するべきです。再生検出だけでは解決策にはなりません。正当な要求が複数ある可能性があり、確率的暗号化を使用しない場合、暗号化の出力は常に同じになります。
追加された 著者 Limit,
@JimmyJamesは私の無知を許しますが、あなたはURIの中にユーザ識別を挿入していますか? RESTは、ユーザーIDをAFAIKで送信するためのより良い(読み取り:より安全な)方法をサポートしています。
追加された 著者 Limit,

それが「人気のある質問」として登場したので、私はこれを思い出しました。これを聞いてから、 OWASPのおすすめはリクエストヘッダーを使用することであることを知りました。 :

  • POST/PUTリクエストでは、機密データはリクエストボディまたはリクエストヘッダで転送する必要があります
  • GETリクエストでは、機密データをHTTPヘッダーで転送する必要があります

これはAPIをやや使いにくくしますが、少なくともいくつかの一般的なフレームワークでこのアプローチに対するサポートがあります。

2
追加された

このアプローチは有効に思えますか、それとも他に何か欠けているものはありますか?

しかし、あなたのアプローチは有効です。以下の理由から、事前共有対称鍵の使用を却下しません。

  • 非対称は、対称よりもはるかに復号化が遅くなります。サービスがあなたのURIから複数の値を復号化しなければならない場合、パフォーマンスは影響を受ける可能性があります。
  • この暗号化の攻撃経路は限られています。ほとんどの場合、TLSはこのデータを保護するべきです。
  • セキュリティを強化するために、さまざまなコンシューマにさまざまな事前共有キーを割り当てることができます(広く共有されている対称性を使用して懸念に対処する)。これにより、キーの回転をより柔軟にすることもできます。
  • 非対称暗号化では、暗号化されたテキストが大きくなります。あなたのURI +クエリ文字列が十分に長い場合、それは414(Request-URI Too Long)を引き起こす可能性があります。

TLSに使用されるのと同じキーペアを使用することは有効ですか?

In theory you shouldn't because if an attacker obtained your key-pair they could decrypt both your TLS connections & your encrypted headers.

...現実的な/サポートの観点から、TLSキーペアが取得された場合、これは最終的なシナリオです。 2番目のキーペアを持っていても、復号化される可能性のある重要なデータがヘッダー/本文に含まれている可能性があるため、「完全侵害」イベントを防ぐことはできません。

特定のビジネスニーズに合わせてオプションを慎重に検討する必要があると思います。

2
追加された

より標準的な方法は、機密情報を身体に移すことです。

本当に、これはあなたの伐採習慣に帰着します。あなたのログに本文を含めることによって上記の提案を無価値にすることもできますし、完全なURIをログに記録しないことによって問題を回避することもできます。その情報はあなたのサーバで常に利用可能です(あなたの暗号化された方式でさえ、それはスタックの少なくともいくつかの部分によって解読されなければなりません)。

私は、URLを膨らませてデバッグを難しくし、ユーザーに何が起こっているのか不思議に思うような複雑なスキームを実装するよりも、ログのデフォルトを自分の環境に適したものに変更するほうがいいでしょう。

0
追加された
私はあなたの意見を尊重しますが、データを身体に移すことは他の問題を引き起こします。ロギングの問題は解決策の一部ではありません。それは考えずにエミュレートされる古い技術の成果物です。
追加された 著者 nikky,
私は必ずしもあなたの答えに異議を唱えるわけではありませんが、それは質問を回避します。質問には、URIに情報が含まれており、それを保護する必要があるという前提があります。アクセスログを無効にすることはオプションですが、偶然に簡単に再度有効にできるデフォルトであるため危険です。
追加された 著者 nikky,
確かに、私は質問がまずい前提から始まると言っているだけで、実際の問題を解決するためのより良い方法があります。
追加された 著者 Dale M,

あなたのアプローチが考慮していないことがいくつかあります。

  • encrypt parts of the URI or all of it

    How will you encrypt the URI? The browser does it or the web-page? If the browser does it, how does the browser know what part of the URI to encrypt and if the web-page does it, how will you get the TLS certificate of the server? Read this. Also, you can't encrypt the entire URL otherwise the browser will not know the server that it should talk to.

  • There probably needs to be some other information in the encrypted portion to avoid replay attacks or mapping an encrypted value back to given key, correct?

    If you are using TLS, then the replay detection is already handled by TLS (Are SSL encrypted requests vulnerable to Replay Attacks?).

There are several discussions about encrypting URL parameters that have happened on StackOverflow: 1, 2 and some other Google search results: It's a bad idea, how to do it in Java

0
追加された
コメントは詳細な議論のためではありません。この会話はチャットに移動
追加された 著者 Rory Alsop,