2

組み込みクライアントのリクエストを処理するサーバー コンポーネントを開発していますが、これも私の管理下にあります。

現在、すべてがベータ版であり、セキュリティは次のように機能します。

  1. クライアントは https 経由でユーザー名とパスワードを送信します。

  2. サーバーはアクセス トークンを返します。

  3. クライアントは、カスタム ヘッダーのアクセス トークンを使用して、http 経由でさらに要求を行います。

これはデモには問題ありませんが、リリースする前に修正する必要があるいくつかの問題があります。

  • 誰でもloginリクエストをコピーして再送信し、アクセス トークンを取得できます。一部のユーザーが回答したように、https を経由するため、これは問題ではありません。私の間違い。

  • リクエスト ヘッダーを検査するだけで、誰でもリッスンしてアクセス キーを取得できます。

タイムスタンプを使用して重複したリクエストを拒否できる対称鍵暗号化を考えることができますが、このシナリオにはよく知られている良い方法があるかどうか疑問に思っていました (これはかなり一般的なようです)。

洞察に感謝します。

PS: 念のため、サーバーに Java を使用しており、クライアントは C++ でコーディングされています。

4

3 に答える 3

2

一般的な推奨事項の1つは、httpsを使用することです。

セッション全体でhttpsを使用することは別として、中間者攻撃のhttpsmanは十分に信頼できるはずです。アクセストークンについて心配する必要はありません-httpsがこれを処理します。

さらなるリクエストにhttpを使用すると、いくつかの脆弱性が発生するようです。これで、ネットワークスニファを持っている人なら誰でも、トラフィックを傍受してトークンを盗み、リクエストをスプーフィングできます。保護を構築してそれを防ぐことができます-トークンの暗号化、一度トークンを使用するなどですが、そうすることでhttpsを再作成します。

中間者攻撃に戻る-これは、サーバーとクライアントの間に自分自身を挿入し、コードを介してリクエストを集中させる誰かの能力に基づいています。つまり、攻撃者が物理ネットワークにアクセスできる場合は、すべて実行可能です。このような攻撃者が直面する問題は、適切なデジタル証明書を提供できないことです。攻撃者は、署名に使用した秘密鍵を持っていません。ブラウザを介してhttpsにアクセスすると、ブラウザから警告が表示されますが、それでもページにアクセスできます。

あなたの場合、サーバーと通信するのはクライアントです。また、証明書のすべての適切な検証が実施されていることを確認できます。あなたがそれをするならあなたは大丈夫なはずです

編集

Yishaiのセカンド-はい、主にCPUにいくらかのオーバーヘッドが関係していますが、この追加のオーバーヘッドがサーバーをオーバーボードに追いやる場合、アプリに大きな問題があります

于 2009-12-11T14:55:37.483 に答える
2

最初の質問は、それを理解するためだけです。クライアントになりすましている不正なアクセスについて十分に懸念している場合は、HTTPSを介して会話全体を実行してみませんか。最小限のパフォーマンスヒットは、このアプリケーションにとって十分に重要であり、セキュリティの追加レイヤーの価値はありませんか？

次に、誰かがログイン要求を再生するにはどうすればよいですか？私が間違っていなければ、それはHTTPSを介して行われています。接続が正しく設定されている場合、HTTPSはワンタイムナンスを使用したリプレイ攻撃を防ぎます（ここを参照）。

于 2009-12-11T14:56:51.163 に答える
2

最初の部分がわかりません。ログイン要求がhttpsの場合、どうすればそれをコピーできますか？

2番目の部分に関しては、tこれはかなり標準的なセッションハイジャックのシナリオです。この質問を参照してください。もちろん、ここには組み込みのブラウザオプションはありませんが、基本的な考え方は同じです。重要な場合にのみ安全な接続を介してトークンを送信するか、何らかの方法でトークンを送信デバイスに関連付けます。

ブラウザでは、基本的にIPアドレスしかありません（これはあまり良くありません）が、あなたの場合、同じトークンが存在しないことを確認するためにリクエストに対して検証するデバイスに固有の何かを表現できる場合があります他の場所から使用されます。

編集：ここで幸運なことに、プロキシの背後でIPアドレスが変更されることを除外し、実際にこの目的に使用することができます。

しかし、結局のところ、ここで独自のライブラリを作成するよりも、有名でレビュー済みのライブラリのhttpsを使用する方がはるかに安全です。httpsはオーバーヘッドであると認識していますが、自分でローリングすると、攻撃者が悪用できる明らかなものを見逃してしまうという大きなリスクがあります。

于 2009-12-11T14:57:33.987 に答える