私は自分の会社のウェブサイトのセキュリティを向上させることに取り組んでおり、簡単に維持できる偽造の試みを防ぐトークンを作成したいと考えました。これが私が思いついたものです。
public class AntiForgeryToken
{
private readonly string _referenceToken;
public AntiForgeryToken()
{
_referenceToken = Guid.NewGuid().ToString();
}
public string ReferenceToken
{
get { return _referenceToken; }
}
}
MasterPage の基本クラスには、次の名前のプロパティでラップされた HiddenField があります。ReferenceToken
protected virtual void Page_Load(object sender, EventArgs e)
{
if (!Page.IsPostBack)
{
InjectToken();
}
ValidateToken();
}
private void InjectToken()
{
var token = ObjectFactory.GetInstance<AntiForgeryToken>();
ReferenceToken = token.ReferenceToken;
}
private void ValidateToken()
{
var token = ObjectFactory.GetInstance<AntiForgeryToken>();
if (ReferenceToken.Equals(token.ReferenceToken, SC.InvariantCultureIgnoreCase))
return;
...do stuff for failed token
}
セッション内にトークンを格納する StructureMap ハンドルを持っているので、ユーザー セッションごとに永続化されます。これはすべて、偽造防止スキームの有効な実装でしょうか?
編集:私の質問にはいくつかの混乱があるようです。はい、 ASP.NET MVC には AntiForgeryToken スキームが組み込まれていることを理解しています。この質問は、CSRF 攻撃 (クロス サイト リクエスト フォージェリ）。これにより、ユーザー権限の適切な承認が不要になるわけではないことを理解しています。
@Neal と @solairaja が投稿したまさにそのリンクを表示するつもりでした: ASP.NET MVC の AntiForgeryToken() helper を使用して Cross-Site Request Forgery (CSRF) を防止します。この記事では、CSRF 攻撃とは何か、MVC がそれをどのように阻止するかについて詳しく説明しますが、その解決策は Web フォームには適用できないため、独自の実装に取り掛かりました。
@Neal からの応答を見た後、GUID の作成を置き換える可能性が最も高い MVC ツールから実際のソース コードを取得できることに気づかなかったので、それが受け入れられる可能性が最も高いと思います。しかし、他の誰かが追加する価値のある情報を持っている場合に備えて、質問を開いたままにします.