A5 Broken Access Control (2017)

Broken Access Control

“Broken Access Control” is number 5 on OWASP 2017 list.

What is Access control?

Access control, sometimes called authorization, is the means by which a web application grants access to specified content and functions to some users and not others.

lets discuss in details:

When access control is broken, anyone can send requests to one of your network applications. Broken access means that unauthorized access to system functionality and resources has created exploitable weakness that opens your company to harmful and potentially expensive outcomes.
Broken access control is used to describe vulnerabilities related to user authorization. Websites need to allow certain permissions for basic/public users and must also have an administrator who can allow or deny certain privileges to others.

Why it is dangerous?

Broken access control is a threat that is easily exploitable and widespread, as many websites allow unauthorized users to access areas of the site with a simple cut and paste into the browser. Many of these flawed access control schemes are not difficult to discover and exploit. Frequently, all that is required is to craft a request for functions or content that should not be granted. Once a flaw is discovered, the consequences of a flawed access control scheme can be devastating. In addition to viewing unauthorized content, an attacker might be able to change or delete content, perform unauthorized functions, or even take over site administration.
Once they’re in, hackers can access other users’ accounts logs, there details, change permissions, and essentially take over the system as an admin.

lets see some example..
Example
An e-commerce application supports URL rewriting, putting session IDs in the URL −

http://example.com/sale/saleitems/jsessionid=2P0OC2JSNDLPSKHCJUN2JV/?item=laptop
An authenticated user of the site forwards the URL to their friends to know about the discounted sales. He e-mails the above link without knowing that the user is also giving away the session IDs. When his friends use the link, they use his session and credit card.

Hands ON

Step 1 − Login to Webgoat and navigate to 'Session Management Flaws' Section. Let us bypass the authetication by spoofing the cookie. Below is the snapshot of the scenario.

Step 2 − When we login using the credentials webgoat/webgoat, we find from Burp Suite that the JSESSION ID is C8F3177CCAFF380441ABF71090748F2E while the AuthCookie = 65432ubphcfx upon successful authentication.

Step 3 − When we login using the credentials aspect/aspect, we find from Burp Suite that the JSESSION ID is C8F3177CCAFF380441ABF71090748F2E while the AuthCookie = 65432udfqtb upon successful authentication.

Step 4 − Now we need to analyze the AuthCookie Patterns. The first half '65432' is common for both authentications. Hence we are now interested in analyzing the last part of the authcookie values such as - ubphcfx for webgoat user and udfqtb for aspect user respectively.

Step 5 − If we take a deep look at the AuthCookie values, the last part is having the same length as that of user name. Hence it is evident that the username is used with some encryption method. Upon trial and errors/brute force mechanisms, we find that after reversing the user name, webgoat; we end up with taogbew and then the before alphabet character is what being used as AuthCookie. i.e ubphcfx.

Step 6 − If we pass this cookie value and let us see what happens. Upon authenticating as user webgoat, change the AuthCookie value to mock the user Alice by finding the AuthCookie for the same by performing step#4 and step#5.

How to Protect Yourself

The access control mechanism should be extensively tested to be sure that there is no way to bypass it. This testing requires a variety of accounts and extensive attempts to access unauthorized content or functions.

Some specific access control issues include:

Insecure Id’s – Most web sites use some form of id, key, or index as a way to reference users, roles, content, objects, or functions. If an attacker can guess these ids, and the supplied values are not validated to ensure they are authorized for the current user, the attacker can exercise the access control scheme freely to see what they can access. Web applications should not rely on the secrecy of any id’s for protection.

Forced Browsing Past Access Control Checks – many sites require users to pass certain checks before being granted access to certain URLs that are typically ‘deeper’ down in the site. These checks must not be bypassable by a user that simply skips over the page with the security check.
Path Traversal – This attack involves providing relative path information (e.g., “../../target_dir/target_file”) as part of a request for information. Such attacks try to access files that are normally not directly accessible by anyone, or would otherwise be denied if requested directly. Such attacks can be submitted in URLs as well as any other input that ultimately accesses a file (i.e., system calls and shell commands).

File Permissions – Many web and application servers rely on access control lists provided by the file system of the underlying platform. Even if almost all data is stored on backend servers, there are always files stored locally on the web and application server that should not be publicly accessible, particularly configuration files, default files, and scripts that are installed on most web and application servers. Only files that are specifically intended to be presented to web users should be marked as readable using the OS’s permissions mechanism, most directories should not be readable, and very few files, if any, should be marked executable.

Client Side Caching – Many users access web applications from shared computers located in libraries, schools, airports, and other public access points. Browsers frequently cache web pages that can be accessed by attackers to gain access to otherwise inaccessible parts of sites. Developers should use multiple mechanisms, including HTTP headers and meta tags, to be sure that pages containing sensitive information are not cached by user’s browsers.

There are some application layer security components that can assist in the proper enforcement of some aspects of your access control scheme. Again, as for parameter validation, to be effective, the component must be configured with a strict definition of what access requests are valid for your site. When using such a component, you must be careful to understand exactly what access control assistance the component can provide for you given your site’s security policy, and what part of your access control policy that the component cannot deal with, and therefore must be properly dealt with in your own custom code.

For administrative functions, the primary recommendation is to never allow administrator access through the front door of your site if at all possible. Given the power of these interfaces, most organizations should not accept the risk of making these interfaces available to outside attack. If remote administrator access is absolutely required, this can be accomplished without opening the front door of the site. The use of VPN technology could be used to provide an outside administrator access to the internal company (or site) network from which an administrator can then access the site through a protected backend connection.



NOTE:Information showing on this blog is only use for educational purpose.