0

私はこの問題にどのように取り組むべきかについて意見を測り、最終的には迅速な勝利を探したかっただけです（物事を考える間違った方法は、時間のプレッシャーが私が迅速に考えて行動しなければならないことを意味します！

少し問題のあるウェブサイトを受け取りました。

User1234として標準フォーム認証を使用してログインし、URLは次のとおりです。

www.mywebsite.co.uk/1234/Contact。

これにより、User1234の詳細が表示されます。

2つと2つを組み合わせると、1234が何らかのユーザーIDであると正しく想定できます。

認証されると、[Authorize]属性が存在するビューにアクセスでき、匿名/非承認のユーザーはリダイレクトされます。

ただし、User1234としてログインすると、次のようにURLをいじくり回すことができます。

www.mywebsite.co.uk/1235/Contact。

したがって、私はUser1234として認証されていますが、User1235のデータを見ることができます。これは明らかな理由で悪いです。

ログインすると、セッションでログインIDを積極的に設定するため、理論的には、ユーザーがActionResultを押すたびにチェックを実行でき、URLに存在するIDをセッションログインIDと照合できます。ただし、これはかなり多くのアクション結果を伴うプロジェクトであるため、土曜日の午後にすべてのActionResultに何かを追加するのは気が進まない。

global.asaxに、セッションログインIDとURL IDを比較できる各ActionResultリクエストでヒットするイベントがありますか？

または、これを実現したり、URLの改ざんを制限したりする方法について誰かが提案できますか？

4

3 に答える 3

1

あなたはベースコントローラーを試してみることができます

public class BaseController : Controller 
{
     protected override void OnActionExecuted(ActionExecutedContext filterContext)
    {
        //Do your stuff here
        base.OnActionExecuted(filterContext);
    }

}
于 2013-01-05T21:53:29.330 に答える
0

セッションからもユーザーIDを取得できるため、URLルートを変更したくないと思います。簡単な解決策は、影響を受けるコントローラーまたはアクションメソッドに配置できるActionFilterを使用することです。

public class VerifyUserIdAttribute : ActionFilterAttribute
{
    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        var sessionUserId = filterContext.HttpContext.Session["UserId"];

        var routeUserId = filterContext.RouteData.Values["UserId"];
        if (routeUserId != null && sessionUserId == routeUserId)
            filterContext.Result = new RedirectResult("<<url to redirect to>>");
    }
}
于 2013-01-05T23:51:03.493 に答える
-1

URLにデータエントリポイントが含まれている理由がわかりません。これは設計上の欠陥のようです。URLパラメーターを使用するすべてのコードを削除し、代わりに、ログインしたユーザーに基づいてIDが何であるかをコントローラーが検索するようにします。

于 2013-01-05T23:03:13.160 に答える