URIの機密データを非表示にする
これを行う必要があるかどうかは決定されていないため、これは潜在的に架空の質問ですが、より頻繁に出てくる質問だと思います。
バックグラウンド
RESTfulサービス を実装するときの標準的なアプローチは、問題の リソース を識別するために必要な情報をURIに含めることです。私は restafarian ではありませんが、このアプローチには、私たちが利用したいと考えているものよりも多くの利点があります。
問題
私たちは、特定の種類の情報の保護に関する規制要件の対象となっています。これらの保護された要素の一部は、基本的なREST公式に従うと、リソースパスに含まれます。
URLが暗号化されているため、TLSはほとんどの懸念事項をカバーします。ただし、平文で保管できる場所がいくつかあります。特に、デフォルトでアクセスログに書き込まれることが多く（これは便利です）、このためにブラウザーを使用する場合は、閲覧履歴にクリアテキストで保存できます。
アプローチ
これが問題であり、そのようなアプローチを使用したい場合、ソリューションの主な候補はURIの一部またはすべてを暗号化することです。データは非常に予測可能であり、値のセット全体の計算が簡単であるため、ハッシュはオプションのようには見えません。 URI全体を暗号化すると、このアプローチの多くの利点が制限されます。対称暗号化では、秘密鍵を広く配布する必要があるため、目的が達成されません。最良と思われるオプションは、公開データを使用して機密データを暗号化することです。
私が理解しているように、あなたの 暗号化された出力は、少なくともモジュラスと同じ長さである必要があります です。したがって、2048ビットのキーを使用する場合、各データは少なくとも256バイトである必要があります。これにより、かなり長いURIが生成されますが、とにかくしばらく これで問題ないはずです だと思います。その制限は、実際のソリューションには適用されない可能性があります。
このアプローチは有効であると思われますか、および/または他に何か不足していますか？ TLSに使用されるのと同じ鍵ペアを使用することは有効でしょうか？リプレイ攻撃を回避したり、暗号化された値を指定されたキーにマッピングしたりすることを避けるために、暗号化された部分に他の情報が含まれている必要があるでしょう。
[〜＃〜]注[〜＃〜]：私の特定の問題では、認証された当事者のみが電話をかけることができることを述べなければなりません。これは、間違いが発生する可能性がありますが、公衆インターネット上で公開されることを意味するものではありません。関係するすべての当事者は、データを保護するために法的拘束力があります。 RESTfulサービスの人気が高まっているので、そのようなアイデアのより一般的な使用法を探索する価値があると思います。
解決策には、URIの一部またはすべてを暗号化するという1つの主要な候補があるようです。データは非常に予測可能であり、値のセット全体の計算が簡単であるため、ハッシュはオプションのようには見えません。 URI全体を暗号化すると、このアプローチの多くの利点が制限されます。対称暗号化では、秘密鍵を広く配布する必要があるため、目的が達成されません。最良と思われるオプションは、公開データを使用して機密データを暗号化することです。
あなたの論理は健全です。
私はあなたが提案したとおりに機能する1つの製品を知っています。機密データはJavaScriptコードによってエンドユーザーのブラウザーで暗号化され、「key = value」パラメーターのペアの一部に公開鍵暗号化されたbase64エンコードされた文字列が含まれるHTTPS GETリクエストが行われます。
利点は、機密データが復号化されることなく、これらのリクエストが複数のTLSエンドポイントを持つネットワークを介して渡される可能性があり、途中のWebサーバーログまたはプロキシが機密データにアクセスできないことです。
このアプローチは有効であると思われますか、および/または他に何か不足していますか？
それは有効ですが、ここで見逃したくないものは次のとおりです。
- 暗号化を実行するのに十分なインテリジェンスを備えたクライアントが必要です。つまり、Javascript、またはカスタムアプリなどです。
- 自分の暗号をロールバックしないでください。信頼できる信頼できるライブラリを使用して、アプリのコードレビューを取得します。
- キー管理。キーを生成し、キーを公開し、キーをローテーションし、キーを廃棄する必要があります。正しく実行することは、データの制御を失うこととデータへのアクセスを失うことのバランスを取ることを意味するため、慎重に行う必要があります。
TLSに使用されるのと同じ鍵ペアを使用することは有効でしょうか？
私はそれに反対することをお勧めします。 「暗号システムを過負荷にしない」という一般的な経験則は別として、その鍵が「信頼できる」ものではない状況がいくつかあります。私が遭遇したものの1つは、DDoS軽減サービスが攻撃中にトラフィックの前面に出ている場合、Web証明書およびキーのコピーが必要になることが多いということです。
リプレイ攻撃を回避するために、暗号化された部分に他の情報が必要になる可能性があります
場合によります; REST処理しているトランザクションがべき等である場合、それはそれほど重要ではありません。それが何かを変更する場合、はい、再生保護がより重要です。
または、暗号化された値を所定のキーにマッピングして戻しますか？
はい、それは絶対に必要というわけではありません-使用するキーの数とOUPとRUPテールがどれだけ長いかによって異なりますが、どのキーを推測する必要がない方がはるかに簡単です:)
「人気の質問」として浮上したので、改めて気づかされました。私はこれを尋ねたので、 OWASPの推奨事項 が要求ヘッダーを使用することであることを学びました：
- POST/PUTリクエストでは、機密データをリクエスト本文またはリクエストヘッダーで転送する必要があります
- GETリクエストでは、機密データをHTTPヘッダーで転送する必要があります
これによりAPIの使用が多少難しくなりますが、少なくとも一部の一般的なフレームワークでは、このアプローチがサポートされています。
このアプローチは有効であると思われますか、および/または他に何か不足していますか？
ただし、あなたのアプローチは有効です。以下の理由により、事前共有対称キーの使用は却下しません。
- 非対称は、対称よりも復号化がはるかに遅くなります。サービスがURIから複数の値を復号化する必要がある場合、パフォーマンスに影響が出る可能性があります。
- この暗号化の攻撃方法は限られています。ほとんどの場合、TLSはこのデータを保護する必要があります。
- セキュリティを強化するために、さまざまなコンシューマにさまざまな事前共有キーを与えることができます（広く共有される対称で懸念に対処します）。これにより、キーローテーションの柔軟性も向上します。
- 非対称暗号化では、暗号化されたテキストが大きくなります。 URI +クエリ文字列が十分に長い場合、414（Request-URI Too Long）を引き起こす可能性があります
TLSに使用されるのと同じ鍵ペアを使用することは有効でしょうか？
理論的には、攻撃者がキーペアを取得した場合、TLS接続と暗号化されたヘッダーの両方を復号化できるため、そうすべきではありません。
...現実的な/サポートの観点から、TLSキーペアが取得された場合、それは最悪のシナリオです。 2番目の鍵ペアがあっても、「完全な侵害」イベントを防ぐことはできません。これは、解読可能なヘッダー/ボディに機密データが含まれている可能性があるためです。
特定のビジネスニーズに合わせてオプションを慎重に検討する必要があると思います。
より標準的なアプローチは、機密情報を体内に移動することです。
本当に、これはあなたのロギングの実践に帰着します。ログに本文を含めることで上記の提案を無意味にすることも、完全なURIをログに記録しないことで問題を回避することもできます。情報は常にサーバーで引き続き利用できます（暗号化スキームでも、少なくともスタックの一部で復号化する必要があります）。
URLを膨らませてデバッグを困難にし、ユーザーに何が起こっているのか不思議に思うような複雑なスキームを実装するのではなく、ログのデフォルトを環境に適したものに変更するほうがよいように思えます。
あなたのアプローチが考慮していないいくつかの点があります：
uRIの一部またはすべてを暗号化する
URIはどのように暗号化しますか？ブラウザはそれをしますか、それともウェブページをしますか？ブラウザーがそれを行う場合、ブラウザーはどのようにしてURIのどの部分を暗号化するかを認識し、Webページがそれを行う場合、サーバーのTLS証明書をどのように取得しますか？ これを読んでください 。また、URL全体を暗号化することはできません。暗号化しないと、ブラウザーは通信するサーバーを認識できません。
リプレイ攻撃を回避したり、暗号化された値を指定されたキーにマッピングしたりすることを避けるために、暗号化された部分に他の情報が含まれている必要があるでしょう。
TLSを使用している場合、リプレイ検出はすでにTLSによって処理されています（ SSL暗号化リクエストはリプレイ攻撃に対して脆弱ですか？ ）。
StackOverflowで発生したURLパラメータの暗号化に関するいくつかの議論があります： 1 、 2 と他のいくつかのgoogle検索結果： それは悪い考えです 、 Javaでそれを行う方法