1

アカウントと管理者のグループがある架空の銀行アプリケーションについて考えてみます。各管理者は、一部のアカウントに対する変更権限を持っています。アカウントに対して行われた変更を保存するために、アプリケーションは編集ページでアカウントIDを送信します。管理者は、フィドラーなどのツールを使用して投稿リクエストを変更できます。アカウントIDを許可されていないアカウントIDに変更した場合。次に、それを検出するための最良の方法は何ですか。

ポストバックでの承認のためにすべてのデータを再検証するには、どのような戦略を使用する必要がありますか?私の関心は、コードではなく、デザインに向けられています。

言い換えると、実際のアプリケーションが、ユーザーが任意のツールからポストバックリクエストを変更している場合でも、アプリケーションがそれを検出できるようにする方法です。

4

2 に答える 2

1

ポストバック時に承認のためにすべてのデータを再検証する必要がありますか?

はい、そうです。「すべての入力は悪である」という哲学から始めて、各データ ポイントを検証することで、そのステートメントが正しくないことを証明する必要があります。データ全体が検証に合格しない場合、入力は確かに悪です。

スマート Web アプリケーションは、クライアント側とサーバー側の両方の検証を採用しています。クライアント側の検証により、サーバーのラウンドトリップを行わずに何が間違っているか不足しているのかをユーザーにすばやく警告し、サーバー側の検証により、誰かがクライアント側の検証コードを「いじる」場合でも、間違ったデータが見過ごされないようにします (オーバーライドします)。

残念ながら、クライアント側 (JS コード内) にもキーがあるため、クライアント側でデータを暗号化することはできません。悪意のあるユーザーが悪意のあるペイロードを暗号化するのを防ぐことはできません。また、隠しフィールドなどの難読化は、悪意のある攻撃者にとっては非効率的です。参考までに、フィドラーでフィールドを変更したり、パラメーターを投稿したりする必要はありません。必要なのはfirebug extensionだけです。

マントラは「サーバー側ですべてのものを検証する」です。限目。

于 2012-07-04T05:53:29.200 に答える
0

バンキングのような重要なアプリケーションについては、次のセキュリティ手順を提案します

1) 暗号化されたアカウント ID を送信します。2) そのアカウント ID を非表示フィールドに保持し、ユーザーがデータを投稿するときに、テキスト ボックスまたはラベルからではなく、非表示フィールドからアカウント ID を取得します。3) ポストバックの承認のためにすべてのデータを再検証します。

于 2012-07-04T05:36:18.623 に答える