3

MVC アプリケーションを保護するための一般的に知られているプラ​​クティスを次に示します。

  • 出力をエンコードする
  • SQL をパラメータ化する
  • 検索を前後にテストします
  • 一方向ハッシュ パスワード
  • アカウントをロックアウトするか、ログイン試行を制限する
  • ファイル システムへのアクセス時にコード ベースの偽装を使用する
  • ロックダウンされたユーザー名で SQL にアクセスする
  • ボットに対抗するためのフォーム送信にハニーポットまたはキャプチャを使用する

私が見逃したものや誤って述べたものがある場合は、お気軽に貢献してください。

独自のソフトウェアのペン テストを行うときに、他にどのような手法やベスト プラクティスを使用または検討しますか。アプリケーションを公開する前に「タイヤを蹴る」ために何をしますか。

使用している場合、どの侵入テスト サービスまたはソフトウェアを使用していますか?

4

3 に答える 3

4

モデルバインディングを使用するすべてのメソッドは、バインド可能なプロパティのホワイトリストまたはブラックリストで保護する必要があります。

string[] allowedProperties = new[]{ "Title", "Description"};
UpdateModel(myObject, allowedProperties);

また

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create([Bind(Include="Title,Description")] MyObject object )
{

}

これはもちろん、巧妙に細工されたリクエストが意図しない方法でオブジェクトを更新/操作しようとするのを防ぐためです。

于 2010-01-27T06:40:34.360 に答える
3

少しあいまいですが、あなたのリストは良いです。たとえば、md4 は一方向ハッシュですが、1 日もかからずにデスクトップで衝突が発生する可能性があるため、非常に安全ではありません。ソルト値が大きい sha256 は、より安全なアプローチです。（これでも説明が不完全であることはわかっています。炎上しないでください）

全面的に機能する包括的なセキュリティ チェック リストはありません。特定のアプリケーションには、特定の脆弱性が存在する可能性があります。これらの欠陥は、実際には分類されていない論理エラーである場合があります。

OWASPのWeb アプリケーションの脆弱性トップ 10 は、学習すべき優れたリソースです。最も顕著なのは、壊滅的な攻撃になる可能性がある XSRF がリストにないことです。リストされていない「シンク」ベースの攻撃が多数あります。たとえば、攻撃者が自分の選択したパスを fopen に渡すことができたらどうなるでしょうか? A Study In Scarlet では、PHP に対するこれらの攻撃の多くについて説明しています。

于 2010-01-27T22:52:27.497 に答える
1

あなたの提案はすべて、MVC アプリケーションだけでなく、あらゆる Web アプリケーションに適用されます。

MVC 固有の提案は、「スキニー コントローラー、ファット モデル」のようなものです。

于 2010-01-27T23:02:15.460 に答える