2

私のウェブサイトは、ウェブページやウェブサービスを通じて公開されている非常に賢明な情報 (銀行口座番号など) を提供しています。顧客は、ユーザー名とパスワードで認証されると、これらの情報を変更できます。

データベースのエントリを正常に変更したり、Web ページに表示される情報を変更したりするハッキングの侵入は、口座番号が正しくなく、悪意のある銀行口座に送金される可能性があるため、壊滅的です。

このようなサービスを可能な限り堅牢にするためのアーキテクチャに関する一般的なアドバイスはありますか? 脆弱なパスワードの場合、私は責任を負いません。そのため、私の主な懸念は、認証プロセスを単純にバイパスし、私の側でアラートをトリガーせずにデータベースを変更する攻撃についてです。また、さまざまな情報を表示するために直接変更された Web ページの html コードである可能性もあります...

ありがとうございました

4

2 に答える 2

1

この場合、システム自体を可能な限り強化するようにします。これには、セキュリティ ロールから、データベースのトランザクション ベースの使用、ロギング、SQL インジェクション、クロス サイト スクリプティングなどのあらゆる種類の攻撃の防止まで、非常に幅広い範囲が含まれます。 IP チェック (即時に拒否されないシステムへの要求を取り込むことが許可されている IP のホワイト リストがあるように)。言うまでもなく、システム内に実装されているセキュリティ機能 (キーワード: ファイアウォール、ユーザー権限など) に関係なく、ホスト アーキテクチャを保護する必要があります。開発プロセス中は、論理エラーなどを検出するために、常に自動コード チェック ソフトウェア (Sonar など) を実行する必要があります。

次に、プライマリ システムのステータスを監視するためだけに 2 つ目のシステムを用意することもお勧めします。このシステムは、次の場所にログインして通知する必要があります。

  • システム自体に加えられた変更 (誰かがビジネス ロジックにアクセスし、たとえば認証ロジックを削除した場合など)

  • プライマリ システムの状態と一致しないデータベースへの変更。

  • 疑わしいアクションを検出する: たとえば銀行には、口座に適用されるルールがあります。たとえば、前回ヨーロッパ内で支払いを行ったことがあり、その後、中国などに巨額の支払いを行った場合、この支払いをコミットするための通知を受け取ります. 顧客の 2 回目のコミットメントがない限り、支払いはトリガーされません。

最後に、可能な限り強化することはできますが、一般的に「100%」安全にすることはできない(少なくとも理論的には)ことをすでに正しく指摘しているため、システム全体の適切なレベルのセキュリティ部分にはビーイングが含まれます不要な変更を検出し、すでに行われている正確な変更を特定し、システムの全体的なステータスに関する情報を取得して、破損した状態が既に発生した場合にロールバックまたは手動で修正できるようにします。

上記の手法を実装した後でも、使用されているフレームワーク、ライブラリ、およびシステム全体のセキュリティ バグを継続的にチェックする必要があります (システムを自動的に破壊しようとするセキュリティ侵入フレームワークの使用など)。

私の答えでお見せしたいのは、コメントがすでに示唆していることです。これは非常に広範で複雑なトピックであり、複数の層のセキュリティ上の懸念があり、自分で勉強するか、面倒を見ることを「保証」するフレームワークソリューションを用意する必要がありますトピック(Webframeworksのように、基本的なXSS防止が含まれていることがよくあります)。

于 2013-09-04T09:59:58.483 に答える