I have an ASP.NET MVC Application and the routing urls looks as follows:
foobar.com/users/8
foobar.com/users/90
foobar.com/exercise/details/5
foobar.com/exercise/details/400
So with this URL route, a user can manipulate the URL directly and change the ID's which are integers. What is the best practice of securing this so that users can't easily manipulate the URL ID's? How do enterprise applications handle this?
For a well designed system, users manipulating URLs should not be an issue. Even if you send the data in an HTTP Post body, users can still manipulate it using an intercepting proxy such as Burp.
Relying on secrecy of IDs (for example, choosing IDs randomly) is also not a solution. In pentester terminology, you will be vulnerable to direct object reference. The classical terminology for this flaw is violation of the complete mediation principle.
Instead of worrying about what users may do with URLs and content sent to your server, you should be securing the server from malicious inputs. The issue here is authorisation. I recommend you have a good, thorough read of Securing your ASP.NET MVC 4 App and the new AllowAnonymous Attribute and NerdDinner Step 9: Authentication and Authorization.
A lot of applications are designed to be URL hackable in that the user can change values. A lot of users like to manipulate the url to change page number, record, etc.
There is nothing wrong with this As long as you make sure its all secure. For instance your Details action should check the user can access record 5 before showing it.
Related
I've a huge classic ASP application where in thousands of users manage their company/business data. Currently this is not multi-user so that application users can create users and authorize them to access certain areas in the system.
I'm thinking of writing a handler which will act as middle man between client and server and go through every request and find out who the user is and whether he is authorized to access the data he is trying to.
For the moment ignore about the part how I'm going to check the authorization and all that stuff. Just want to know whether I can implement a ASP.net handler and use it as middle man for the requests coming for a asp website? I just want to read the url and see what is the page user is trying to access and what are the parameters he is passing in the url the posted data. Is this possible? I read that Asp.net handler cannot be used with asp website and I need to use isapi filter or extensions for that and that can be developed only c/c++.
Can anybody through some light on this and guide me whether I'm in the right direction or not?
Note: To be specific, I cannot modify anything in the existing application because there are hundreds of pages (each page again has couple of different actions, such as posted to the same page again) are there in the system and it is really big mess and we are coming up with a different solution to clear that mess but that takes couple of years to complete, meanwhile to provide the multi-user functionality to the users we are trying to do this. This layer acts like layer where we authorize the user to do certain operation or access a page, nothing more than this.
I've worked with an ASP classic website that runs Javascript on the server side. In IIS we selected JScript as the server-side scripting language and access the session variables and the database simultaneously to check user's access rights when they try to check out various parts of the site. What you're describing is completely do-able. Each page needs to have Javascript in <% %> tags and that identifies the content as server-side code. Be careful with security though!
As for the ASP.NET handler, I also developed an ASP.NET application that I added imported to our site (had to use a .NET thread pool) which could handle Ajax requests. IIS has this option to import ASP.NET applications to your site.
You've got options.
A fundamental idea in implementing a single page application with Knockout and Upshot is that most of the data will received from and sent to the server in JSON format using AJAX.
On the server, we will expose a number of endpoints (using perhaps WebAPI and the DbDataController) to respond to requests from Upshot. These endpoints may provide general queries for data such as lists of clients, previous orders, account information, etc.
Obviously, it is not desirable for one client to be able view another clients account information, previous orders, or other private data.
What strategies or approaches be used to secure queries (and data) which are being requested from upshot (or other mechanism) to the server? (In other words, how do we make sure a user only has access to his own data?)
Are the strategies the same or different than those used in a normal ASP.NET MVC application--namely use of the Authorize attribute?
This is probably a very simple question, but I am still not clear on all the differences between WebAPI controllers and normally ASP.NET MVC controllers.
Thank for your help!
A custom authorize attribute is one possible way to implement this requirement. The only difference with standard ASP.NET MVC controllers is that you derive from System.Web.Http.AuthorizeAttribute instead of System.Web.Mvc.AuthorizeAttribute.
I'm using ASP MVC application + WCF service with custom session behavior implementation. Clients receive, store and use (for authorization) session tokens. Now I'm searching for most secured way to store session token at client side in ASP MVC.
I see few ways:
Hidden field. Drawback: user can open page source code and get token.
Route value. Drawback: token is actually open. User can get it from address bar.
Session. I've read a lot articles with one conclusion: using Session in MVC application is a bad practice. But Session have a lot advantages as well: can be widely
configured, can store token at server side, etc.
I'm sure there are some best practices for solving my problem. Any help will be appreciated.
Require HTTPS connections, encrypt secure data, place in cookie.
You could also pass the token around your site, encrypted of course via a hidden field or something but your scenario is actually what cookies are made to do.
My bank sets a cookie, they should be good enough for what you are doing.
I'm using ASP.NET MVC and I am trying to separate a lot of my logic. Eventually, this application will be pretty big. It's basically a SaaS app that I need to allow for different kinds of clients to access. I have a two part question; the first deals with my general design and the second deals with how to utilize in ASP.NET MVC
Primarily, there will initially be an ASP.NET MVC "client" front-end and there will be a set of web-services for third parties to interact with (perhaps mobile, etc).
I realize I could have the ASP.NET MVC app interact just through the Web Service but I think that is unnecessary overhead.
So, I am creating an API that will essentially be a DLL that the Web App and the Web Services will utilize. The API consists of the main set of business logic and Data Transfer Objects, etc. (So, this includes methods like CreateCustomer, EditProduct, etc for example)
Also, my permissions requirements are a little complicated. I can't really use a straight Roles system as I need to have some fine-grained permissions (but all permissions are positive rights). So, I don't think I can really use the ASP.NET Roles/Membership system or if I can it seems like I'd be doing more work than rolling my own. I've used Membership before and for this one I think I'd rather roll my own.
Both the Web App and Web Services will need to keep security as a concern. So, my design is kind of like this:
Each method in the API will need to verify the security of the caller
In the Web App, each "page" ("action" in MVC speak) will also check the user's permissions (So, don't present the user with the "Add Customer" button if the user does not have that right but also whenever the API receives AddCustomer(), check the security too)
I think the Web Service really needs the checking in the DLL because it may not always be used in some kind of pre-authenticated context (like using Session/Cookies in a Web App); also having the security checks in the API means I don't really HAVE TO check it in other places if I'm on a mobile (say iPhone) and don't want to do all kinds of checking on the client
However, in the Web App I think there will be some duplication of work since the Web App checks the user's security before presenting the user with options, which is ok, but I was thinking of a way to avoid this duplication by allowing the Web App to tell the API not check the security; while the Web Service would always want security to be verified
Is this a good method? If not, what's better? If so, what's a good way of implementing this. I was thinking of doing this:
In the API, I would have two functions for each action:
// Here, "Credential" objects are just something I made up
public void AddCustomer(string customerName, Credential credential
, bool checkSecurity)
{
if(checkSecurity)
{
if(Has_Rights_To_Add_Customer(credential)) // made up for clarity
{
AddCustomer(customerName);
}
else
// throw an exception or somehow present an error
}
else
AddCustomer(customerName);
}
public void AddCustomer(string customerName)
{
// actual logic to add the customer into the DB or whatever
// Would it be good for this method to verify that the caller is the Web App
// through some method?
}
So, is this a good design or should I do something differently?
My next question is that clearly it doesn't seem like I can really use [Authorize ...] for determining if a user has the permissions to do something. In fact, one action might depend on a variety of permissions and the View might hide or show certain options depending on the permission.
What's the best way to do this? Should I have some kind of PermissionSet object that the user carries around throughout the Web App in Session or whatever and the MVC Action method would check if that user can use that Action and then the View will have some ViewData or whatever where it checks the various permissions to do Hide/Show?
What you propose will not work. Actions can be cached, and when they are, the action (and hence your home-rolled security) does not run. ASP.NET membership, however, still works, since the MVC caching is aware of it.
You need to work with ASP.NET membership instead of trying to reinvent it. You can, among other things:
Implement a custom membership provider or role provider.
Subtype AuthorizeAttribute and reimplement AuthorizeCore.
Use Microsoft Geneva/Windows Identity Foundation for claims-based access.
Also, I completely disagree with ChaosPandion, who suggests making structural changes in your code before profiling. Avoiding exceptions for "performance" reasons is absurd -- especially the idea that the mere potential to throw an exception for invalid users will somehow tank the performance for valid users. The slowest part of your code is likely elsewhere. Use a profiler to find the real performance issues instead of jumping on the latest micro-"optimization" fad.
The correct reason to avoid exceptions for authorizations is that the correct way to indicate an attempt at unauthorized access in a web app is to change the HTTP status code to 401 Unauthorized, not throwing an exception (which would return 500).
Define your authorisation requirements as a domain service so they are available to both the web and web service implementations.
Use an authorisation filter to perform your authorisation checks within the web application, this should be as simple as creating an auth request object and then passing it to your auth domain service.
If the authorisation fails, return the correct error - a 401 as indicated by Craig Stuntz.
ALWAYS authorise the action. If you can hide the link to unauthorised users - thats nice.
Simplify your views / view logic by writing a HtmlHelper extension method that can show / hide things based on a call to the auth domain service.
To use your authorisation service from the web service is simply a matter of constructing the auth request object from something passed in via the service message instead of from a cookie passed by the users browser.
Our shop is in the process of converting our internal project management application from ASP.NET Web Forms to ASP.NET MVC.
I would like to provide an RSS feed for our customers of their current open issues ... but I would like to do so with some type of authorization, e.g. login and a password.
Is this possible using ASP.NET MVC or should this be done through some other service like WCF? Sample code would be much appreciated.
I'm not sure of the best way, but can think of a few, none are super great though.
Use IIS WindowsAuthentication with basic security and implement the validation method and then mark the RSS action with an authorize filter. If they are using an RSS feeder that doesn't allow http authentication, you should still be able to do http://username:password#mysite.com/controller/action/rss.
Generate a token for each customer and place it in part of the url: http://mysite.com/controller/action/rss/{token}. This isn't that great.
Put the username/password as part of the route: http://mysite.com/controller/action/rss/{username}/{password} ... this is pretty horrible though.
All of them kinda suck because the password (or token) is url visible. Maybe that is considered okay if it is https instead of http though. I think the first option + https is pretty common though?
If private feeds are part of the RSS spec, you should look there for the mechanics of RSS auth.
I've thought about this before for a project and came to the conclusion that secure RSS will never work because not enough clients (e.g. google reader) support it.
Sorry, don't have a complete answer, but thought this might help anyway.