1

How is everyone else protecting against this vulnerability? In an MVC application that is separated in multiple logical layers i.e. Presentation Layer (MVC) > Service Layer > Business Layer > Repository Layer. Is it just a matter of performing a check at the controller level e.g. 

[Authorize]  
public class AccountsController : Controller  
{  
   [HttpGet]  
   public ActionResult Details(long accountNumber)  
   {  
        var account; 
        //account = Call Service Layer to get the account. 

        if (account.UserId != User.Identity.GetUserId())  
        {  
             return new HttpUnauthorizedResult("User is not Authorized.");  
        }
   }   
}

Is there any particular design pattern I can use to improve this design? Furthermore wouldn't it be better to perform this check in my service layer?

Cool Breeze
  • 1,289
  • 11
  • 34
  • Authentication is, by its nature, largely a presentation layer function. The mechanism you use to validate authentication may be a business layer function, but the mechanism to do the actual authentication depends on the front-end technology being used to access it. For instance, your service layer knows nothing about Cookies or FormsAuthentication. So you can't let it do all the work, though you can defer some of that work to your service layer from your presentation layer. Using your example above, User is part of asp.net, which you probably don't want to push to your service layer – Erik Funkenbusch Jun 03 '15 at 05:54
  • 1
    The point here is that your front end has to be the gate keeper, although the keymaster might well be your business layer ;) – Erik Funkenbusch Jun 03 '15 at 05:57
  • 1
    So what you're saying is to perform the authentication in the presentation layer and the authorization in the service layer i.e. to decorate the service layer methods like this: [PrincipalPermission(SecurityAction.Demand, Role="RoleName")] I am also assuming I could perform the if statement in the original post using principal.Identity.Name? – Cool Breeze Jun 03 '15 at 05:59
  • No, i'm not saying that... although doing that may be fine. I'm not telling you how you SHOULD do it, just how you SHOULDN'T. Or rather, the realities of authentication. You might also want to design your app so that direct object reference is largely unnecessary. Instead of Details taking an account number, the controller already knows who the users is, and just get their details. Only allow this sort of thing for users authorized to view other users details, or provide a subset of details to users who lookup by id that are not sensitive. Of course that may not be possible for all apps – Erik Funkenbusch Jun 03 '15 at 06:02
  • In the above example if you were to change the signature to not include an account number and the user had multiple accounts... It wouldn't work? is that what you mean "it may not be possible for all apps"? – Cool Breeze Jun 03 '15 at 06:07
  • How can a user have multiple accounts? You can only be authenticated against one account at a time... – Erik Funkenbusch Jun 03 '15 at 06:08
  • Sorry for not making it clear... The example in the OP is an example in a financial application i.e. getting account details. – Cool Breeze Jun 03 '15 at 06:11
  • I see what you mean now... account is a financial account, not user account. – Erik Funkenbusch Jun 03 '15 at 06:14
  • I am imagining that 1 user account can have multiple bank accounts so therefore they would have a list of of their accounts on 1 page and then they can select one of their accounts to get more information. If you didn't have a parameter to accept the account number how would you know which one to retrieve? – Cool Breeze Jun 03 '15 at 06:14
  • In that case, then it's quite simple. You pass the user account to the service layer, and it only returns accounts that belong to the user. It's impossible for a different user to view another account because the service layer would return null if the account did not belong to the user. If I ask for account 1111111, and 1111111 does not belong to my userid, then the service layer returns an error or null or something to indicate they have no access. – Erik Funkenbusch Jun 03 '15 at 06:15
  • Yes so I would imagine the service layer method would be something like: "GetFinancialAccountDetails(int id)" inside the method you could then retrieve the account and verity that the owner of the account is equal to principal.Identity.Name? – Cool Breeze Jun 03 '15 at 06:19
  • More like `GetFinancialAccountDetails(int userId, int accountId)`. Again, your service layer shouldn't depend on, or know anything about IIdentity (principal.Identity) as that is an asp.net thing and part of the presentation layer. You probably also want to work with userid's and not names, since names can change. – Erik Funkenbusch Jun 03 '15 at 06:38
  • Have a look at this: http://stackoverflow.com/questions/2085560/authorization-user-info-in-a-service-layer-net-application I think its reasonably fine to set the principal? i.e. rather than passing in the user id? – Cool Breeze Jun 03 '15 at 08:21

0 Answers0