3

インジェクション、XSS、CSRF などの OWASP 上位 10 のセキュリティ脆弱性を防ぐために、ASP.Net に最適な再利用可能なライブラリと組み込み機能、およびテスト チームが使用するこれらの脆弱性を検出するための使いやすいツールを探しています。

開発ライフ サイクルの中で、セキュリティ コーディングをアプリケーションに組み込み始めるのに最適な時期はいつだと思いますか?

4

3 に答える 3

4

私の経験では、開発者にツールボックスを提供し、最善を尽くすことを期待するだけでは、実際にはうまくいきません。セキュリティは、コード品質の側面です。セキュリティの問題はバグです。すべてのバグと同様に、よく知っている開発者でさえ、最終的にそれらを作成することになります。これを解決する唯一の方法は、バグをキャッチするプロセスを用意することです。

どのような種類のセキュリティ プロセスが必要かを考えてください。自動テストのみ？コードレビュー？手動のブラックボックス テスト? 設計書レビュー？バグ追跡システムでセキュリティの問題をどのように分類しますか? セキュリティ バグを修正する優先度をどのように決定しますか? 顧客にどのような保証を提供できますか?

開始に役立つものとして、OWASP ASVS 検証標準があります。これは、セキュリティ検証プロセスが実際に機能することを検証するのに役立ちます: http://code.google.com/p/owasp-asvs/wiki/ASVS

于 2010-07-06T14:19:37.863 に答える
4

私の2セント：

  • ユーザー入力を決して信頼しないでください。これには、フォーム、Cookie、パラメーター、リクエストが含まれます...
  • ライブラリを最新の状態に保ちます。私たちの間では、セキュリティ上の欠陥が日々発生しています。パッチはリリースされますが、それらを適用したり、ライブラリをアップグレードしたりしないと意味がありません。
  • 制限的で妄想的であること。ユーザーに自分の名前を書く必要がある場合は、制限を設けて [Az] 文字のみを使用できるようにします。強い制約は平均的なユーザーを苛立たせますが、システムをより安全にします。
  • 重要なデータをログに記録しないでください。これは、ユーザーが使用したパスワードなどをログに記録してはならないことを意味しますが (明らかです)、システムへのログインに失敗したときにユーザーが入力したパスワードをログに記録しようとしてもいけません (ユーザーは簡単にタイプミスした可能性があるため)。推測する）。この例をすべての重要なデータに拡張できます。そこになくても、誰かが手に入れようとする心配はありません。

ウィキペディアの CSFR 記事から抽出:

  • Cookie だけでなく、GET および POST パラメーターで認証を要求する。
  • HTTP Referer ヘッダーを確認しています。
  • Flash ムービーへの意図しないアクセスを許可する crossdomain.xml ファイルがないことを確認する[14]
  • 認証 Cookie の有効期間を制限する
  • POST を処理するとき、フォームから取得する必要があることがわかっている場合は、URL パラメータを無視します
  • すべてのフォーム送信と副作用 URL で秘密のユーザー固有のトークンを要求すると、CSRF が防止されます。攻撃者のサイトが正しいトークンを提出物に入れることができない
于 2010-07-06T12:45:21.470 に答える
3

最初のベスト プラクティス: コーディング中に脆弱性に注意してください。コードを作成する場合は、何をしているのかを考えてください。

于 2010-07-06T11:46:38.580 に答える