This feature has to do with authorization, as it happened with other previous features. The problem here is accessing some parts of the application for which the user is not authorized, for instance, a non-administrator user accessing the private wage records of the rest of the company). As usual, the official documentation states the problem precisely:
Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.
The symptoms can vary: the UI showing links to unauthorized functionality, authentication, and/or authorization checks missing in the server or even the server not checking the identity of requests, and so on.
OWASP exemplifies this type of attack in two scenarios:
- Scenario #1: The attacker simply forces browsers to target URLs. The following URLs require authentication. Admin rights are also required for access to the
admin_getappInfopage.http://example.com/app/getappInfohttp://example.com/app/admin_getappInfo- If an unauthenticated user can access either page, that's a flaw. If an authenticated, non-admin user is allowed to access the
admin_getappInfopage, that is also a flaw, and it may lead the attacker to more improperly protected admin pages.
- Scenario #2: A page provides an
actionparameter to specify the function being invoked, and different actions require different roles. If these roles aren't enforced, that's a flaw.
Access control implementation inside the code is also to be checked. If you follow a single privileged request, try to verify the authorization pattern. Then, you can search the code base trying to find a pattern and identifying when that pattern is not followed. Keep in mind that automated tools rarely find these issues.
Perhaps one of the most typical examples of this attack is seen when a request shows the structure of information in the URL, allowing the user to guess the possible attacks. For instance, say, an attacker sees the following after a request:
http://thesite.com/application?userId=1234
Then, it's easy to figure out the pattern to follow in order to obtain somebody else's information, just changing the number of the request at the end. If there are no proper procedures about authorization, the user can gain control over unauthorized data.
Prevention measures are well established, although they're quite difficult to automate (most of them should be managed manually, although there are some tools):
- Try to get information from administrative components with a regular user account.
- Use a proxy and access the application as an administrator. Then, try to get access to the restricted pages using the previous regular user credentials.
- Find out as much as you can about how admins are validated in the system and make sure that proper security procedures are enforced.
- If the function is part of a workflow, try to check whether the conditions are in a suitable state to allow access.
- Try to audit failed attempts to access information in order to discover the possible paths for an attack.
- Provide access based on roles on every action method (ASP.NET MVC and the classic ASP.NET). This means having to avoid granting access based on individual users.
Finally, note that in relation to IIS, there are two execution modes: the classical one (and the only one until version IIS 6) and the integrated mode. In the integrated mode (in use from IIS 7), .NET sees any request, so a given handler can authorize each request, even if the request is addressed to a non-.NET resource (such as JavaScript or a multimedia file).
So, if you are running IIS7+ versions, make sure that the integrated mode is active because otherwise, .NET only handles requests for files such as .aspx, .ascx, and the like, so other files can be unsecured.