BROKEN ACCESS

CONTROL
Access control otherwise called as authorization which will manage the permissions to the
users in a organization when the access control mechanism was not implemented in a right
way it can be compromised by the attacker who can gain admin access from user profile.

DESCRIPTION

Broken access control will give added access to the user who is not supposed
to have that access. For example, let’s say there is a document which was accessed
by three people namely admin, editor, viewer. The admin will have access to view,
edit and delete that document, the editor will only have access to edit that
document, the viewer will only have access to view the document. Imagine an
attacker who logged in as user and have access of the admin, this is called as broken
access control. A user who has access to information which he should not supposed
to have.
The types of broken access control are.

 Insecure ID
 Forced Browsing
 Directory Traversal
 Client-side caching

Insecure ID’s:

When looking for something in a database, most of the time we use a unique ID.
Often, this ID is used in the URL to identify what data the user wants to get. Let’s say
I’m logged in to a website, and my user ID is 1337. When I go to my own profile
page, the URL looks something like this: https://portswigger.com/profile?id=1337.
This page might contain sensitive data, which nobody else should see. But what if I
replace the ID with another user’s ID? If the webserver is configured improperly,
then if I visit e.g., https://portswigger.com/profile?id=42, then I will get the profile
page of another user, with every sensitive data. You might ask how do I know the ID
of another user? Well, if the user IDs are random and kept secret, then it’s a bit
harder, but this is not nearly enough defence. This is a good example of ‘security by
 obscurity’, which is widely considered bad practice. The good solution is to
implement proper access control in the server, so it does not serve the user with the
requested data if they are not authorized to access it.

Forced browsing:

Forced browsing is when the user tries to access resources that are not referenced
by the application, but still available. For example, a web application might have an
admin page, but there is no link to the admin page on other parts of the website, so
just by clicking around, a regular user never gets to the admin page. But if someone
directly edits the URL, e.g., visit https://example.com/admin, they might access the
admin page if the access control is broken.

Directory traversal: 

When a website stores data in different files, the server might expect a filename as a
request parameter. E.g., if there is a web application for reading short novels, the
URL might look like this: https://example.com/novels?file=novel1.txt. On the server
side, there is probably a folder where all novels are stored, and the server looks for
the given file name in this folder. An attacker could abuse this behaviour for example
by visiting the URL https://example.com/novels?file=../../../../../../etc/passwd. The
lots of ../-s will eventually reach the root directory, and the attacker can access any
file from there. To defend against this attack, the webserver should be configured in
such way that it has no access to the files that it does not need. Filtering for .. in the
input parameter could also work.

Client-side caching: 

Browsers store websites in their cache to ensure faster loading if the user tries to
access the same website again. This might be a problem if multiple people use the
same computer, e.g., in a library or an internet café. Developers should prevent
browsers from storing sensitive data in their cache.

MITIGATION

Access control vulnerabilities can generally be prevented by taking a defence-in-

depth approach and applying the following principles:
 Unless a resource is intended to be publicly accessible, deny access by default.

 Wherever possible, use a single application-wide mechanism for enforcing access

controls.

 At the code level, make it mandatory for developers to declare the access that is
allowed for each resource, and deny access by default.

 Thoroughly audit and test access controls to ensure they are working as designed.