1

いくつかの金融取引を実行するためにいくつかの Web サービスに接続するアプリケーションを Flex で設計しています。Web サービスは https プロトコルを使用して保護されており、リクエストごとにログイン時に作成されたユーザー トークンを要求しています。これは、ユーザーの認証と承認に使用されます。ここまでは順調ですね。

重要な点は、すべての Web サービスが粗粒度であるとは限らないことです。例を挙げると、EnoughFounds と Transfer という 2 つの Web サービス メソッドを使用できます。したがって、メソッド EnoughFounds が「true」と応答した後でのみ、Transfer を実行します。このロジックは、Flex アプリケーション コード内でプログラムされます。

提示されたシナリオは次のとおりです。誰かがアプリケーションをダウンロードして逆コンパイルした場合。次に、ステップ EnougFunds が実行されないようにコードを変更します。または、EnoughFunds ステップを通過せずに転送を実行する他のテクノロジで、まったく新しいクライアントを作成することもできます。転送を実行すると、ユーザーはサーバー上で承認および認証されます。しかし、彼は実際の資格情報を使用しているため、転送を実行できます。彼がスキップしたチェックは、セキュリティ ドメインではなく、ビジネス ロジックに属しています。アプリケーションを実行しているコードが、私が書いてユーザーがダウンロードした変更されていない Flex コードであることを確認する必要があります。どうやってやるの？シーケンスがサーバー上で実行されるようにサービスを書き換えることができることを知っています。

この特定の問題を解決するセキュリティ メカニズムがいくつかあるに違いないと私には思えます。

ベスト プラクティスに関するアドバイスを求めているわけではないことに注意してください。私の要件は、サーバー側で何も変更しないことです。サービスを変更せずに、プロトコル レベルでシーケンスを保護するにはどうすればよいですか?

4

6 に答える 6

17

これは大きな間違いです。十分に重要なビジネス ルールは、サービスでチェックする必要があります。クライアントが何をしようとも、サービスは決して悪いことを起こさせません。

特に、EnoughFunds 操作を行うことは理にかなっています。なぜなら、EnoughFunds が false を返した場合、十分な資金がないことをユーザーに伝えることができるからです。ただし、Transfer 操作では、十分な資金があるかどうかを確認する必要があり、そのような重要な確認をクライアントに依存してはなりません。

于 2009-02-24T17:34:51.283 に答える
9

このビットを追加さ​​せてください-ゲームを逆コンパイルし、http通信を操作するツールを介して送受信されるメッセージを変更/編集する子供がいます-これは、外部に価値のないゲームのためだけです. 私のユーザーは実際にフィドラーとFirefoxヘッダーツールをロードしてサービス呼び出しを操作し、毎日リセットされるゲームボードでハイスコアを取得しています.

お金や「本当の」価値をミックスに投入するとどうなるかを考えると身震いします.

クライアントが送信するデータを信頼しないでください...「enoughFunds」呼び出しを使用してユーザーインターフェイスを更新しますが、「転送」段階を実行するときは、サーバー側で純粋にその呼び出しを再評価する必要があります-信頼しないでくださいクライアントが転送を要求したからといって、それを受け入れる必要があります。

于 2009-02-24T17:41:22.920 に答える
6

他のすべての回答が指摘しているように、サーバー側に問題があるため、サーバー側を変更せずにこれを解決することはできません。また、サーバー側の変更を伴わない適切なプロトコルは存在しません。

これを銀行の窓口にいる人と比較するのは非常に適切です。その人物は銀行員に、自分が誰であるか、実際にアカウント X を所有していることを確認する資格情報を提示しました。それがログインです。

今、その人は口座 X から Y への送金を注文したいと考えています。利用可能な資金について彼女が何を言おうと、問題になることはありません。彼女が十分な資金があるという銀行の頭取からの署名された文書を提示した場合でも、銀行は送金が行われる前に確認する必要があります。

これは、「EnoughFunds」が「Transfer」の前に呼び出され、1 回だけ呼び出され、あまり前に呼び出されず、適切なパラメータで呼び出されたことを保証するセキュアなシーケンス ロジックをプロトコルに組み込んだ場合でも、クライアントが銀行「大丈夫です、十分な資金があります。」それは決してそれをカットするつもりはありません。

最も近いのは、銀行の顧客がカウンター越しに従業員の画面を指差し、「ほら、あなたのシステムを見てください。十分な資金があるので取引を実行できると表示されています」と言っているようなものです。つまり、クライアントは、サーバーが行ったばかりのEnoughFunds への呼び出しの時間、入力および出力を検証可能に再現できます。これは問題ありませんが、まったく無意味です。

したがって、解決策は Transfer が内部で EnoughFunds を呼び出すようにすることです。クライアントが知る必要がある場合は、十分な資金がない場合に説明的な例外/エラーを返すことができます。

こんな感じです。
(ソース: userfriendly.org )

于 2009-03-05T08:54:36.390 に答える
5

正直なところ、開発計画を真剣に再評価する必要があると思います。ここで他の人が正しく述べているように、クライアントの整合性に依存することはできません。

簡単に言えば、あなたが制御できる環境の外には「安全で信頼できるコード」のようなものはありません（つまり、サーバー-それでも議論の余地があります）。実際に話しているソフトウェアがわからないため、アプリケーション層プロトコルをどのように「微調整」しても、悪意のある攻撃者がリバースエンジニアリングされた実装で単にあなたをだましているわけではないという保証はありません。あなたの「微調整された」プロトコルの。

「信頼のドメイン」は、WebサービスAPIにのみ拡張され、それ以上は拡張されません。サービスがその操作の整合性を検証できない場合、それは不適切に設計されたサービスです。

于 2009-03-06T18:36:36.823 に答える
1

私はあなたがいくつかのことを考慮すべきだと思います：

  • 改ざん防止URL
  • 期限切れのWebページ
  • EnoughFundsとTransferロジックを1つの呼び出しに結合します。John Saundersが述べたように、とにかく転送する前にEnoughFundsをチェックする必要があるので、一度チェックする方が理にかなっています。
于 2009-03-03T14:32:12.677 に答える
0

まず、他の回答に同意します。クライアントは絶対にあなたの敵であり、決して信頼されるべきではありません。また、あなたが投稿したいくつかのコメントを拡張するには、「EnoughFunds」が何らかの暗号化されたトークンを返したとしても、それがまだハッカーによって金額 10 で呼び出されておらず、その後の転送が金額 10000000 でアクティブ化されたことを保証します。

アプローチは、"EnoughFunds and Transfer" など、アトミックなビジネス ロジックを一緒に配置する必要があります。

すべてのサーバー呼び出しにシーケンスを追加することをお勧めします。これにより、古いサーバー呼び出しは順序が狂っているため、再実行できなくなります。サーバーは、ある種の「暗号化された」番号として「次のシーケンス トークン」を返す必要があります。これは、乱数を生成して応答の一部として返すのと同じくらい簡単で、サーバーセッションに配置して、そのクライアントからの後続の呼び出しで再確認することもできます。

繰り返しますが、このトリックはセキュリティ対策ではなく、簡単すぎる「いじくり回し」の状況を回避するためのものです。

これは、API の難読化と組み合わせることができます。Web サービスを名前で呼び出すと (例: EnoughFunds サービスはそれだけで呼び出されます)、リバース エンジニアリングがはるかに簡単になります。代わりに、サービスを列挙するのと同じくらい簡単なことを行い、中央コントローラーを経由します - activateTask=12?param1=200 。ただし、これはまだリバース エンジニアリングが非常に簡単です...次のように、各リクエストを完全に暗号化することに投資できればより良いでしょう: SFASDFsdq1231sd4DFGTRsdf2rDF

そしてもちろん、そのような適切なリクエスト暗号化は、セッション ID (別名: 通常はログイン認証トークン) に基づいている必要があります。

于 2009-03-01T19:16:50.077 に答える