MVC3 URL parameters - avoiding malicious attacks/s

问题:

When navigating to a new webpage, is there a "Best Practice" for passing Ids around.

For example, a person registers to use a website, they get given an Id, this needs to be passed around the rest of the website/pages where it is used to retrieve relevant data from a database.

If the Id is passed in the url: http://myWebsite.com/User/Details/1234, the user could change it to http://myWebsite.com/User/Details/4567 and potentially retireve a different user's details.

Putting this value in a hidden field and then POSTing wouldn't be great either as "view source" would display the value.

Many thanks

回答1:

That's why you should always verify that this id belongs to the currently authenticated user. The currently authenticated user is stored in the forms authentication cookie and is something that the user cannot change because the value is encrypted. This cookie is emitted when the user logs in and you can access it everywhere where you have an instance to HttpContextBase (which is pretty much almost anywhere in the V and C parts of the MVC pattern).

For example, like this:

[Authorize]
public ActionResult Foo(int id)
{
    string currentUser = httpContext.User.Identity.Name;
    // TODO: go ahead and check in your backed that the id 
    // belongs to the currently connected user
    ...
}

Obviously writing those checks over and over again in all controller actions could quickly become boring, not to mention the DRYness of the approach. That's why it is recommended to write a custom Authorize attribute which will perform those checks before even entering into the controller action. Then you will decorate your controller actions with this custom attribute and you will know for sure that if the code has reached inside the action it means that the current user is the owner of the id passed as parameter. The way this id is passed as parameter doesn't really matter. Could be route data, query string, POST, whatever. The user can modify it as much as he likes. The important part is that you ensure that the value he entered is coherent with your domain authorization logic.

So:

public class AuthorizeOwnerAttribute : AuthorizeAttribute
{
    protected override bool AuthorizeCore(HttpContextBase httpContext)
    {
        var authorized = base.AuthorizeCore(httpContext);
        if (!authorized)
        {
            // the user is either not authenticated or not authorized
            // no need to continue any further
            return false;
        }

        // at this stage we know that the user is authenticated and
        // authorized (in roles), so let's go ahead and see who this 
        // user is
        string username = httpContext.User.Identity.Name;

        // now let's read the id. In this example I fetch it from
        // the route data but you could adapt according to your needs
        string id = httpContext.Request.RequestContext.RouteData.Values["id"] as string;

        // Now that we know the user and the id let's go ahead and 
        // check in our backend if the user is really the owner
        // of this id:
        return IsOwner(username, id);
    }

    private bool IsOwner(string username, string id)
    {
        // go ahead and hit the backend             
        throw new NotImplementedException();
    }
}

and then:

[AuthorizeOwner]
public ActionResult Foo(int id)
{
    ...
}