1. Broken Access Control

Vulnerabilities that result in users/attackers accessing resources or performing actions that they shouldn't have access to are broken access control vulnerabilities.

Three common subcategories of broken access control vulnerabilities are Vertical, Horizontal, and Context-based. Vertical ones are vulnerabilities that result in users gaining more permission/capabilities than they should e.g. if a user that belongs to a role of customers gains moderator role capabilities. Horizontal ones are vulnerabilities that give users access to resources of other users, e.g. users have the capability to modify posts or comments of other users. And Context-dependant are ones that gave users the capability to access or perform actions that they shouldn't base on the current state of the application, e.g. user can modify a Twitter post after posting it.

Common Attacks and Examples

Unprotected Resource Routs:

Let's say your products are files like an image/video marketplace or some investment reports portal. Users pay monthly or per product to access/download your files. This access functionality works by redirecting a user to the file location e.g. investreports.com/reports/?file=01-2022.pdf if this route isn't protected next month user can just go to investreports.com/reports/?file=02-2022.pdf instead of paying. Or even worst can happen if your app allows relative paths investreports.com/?file=../../../etc/passwd.

Using programs such as Burp Suite or ZAP with scanning/spider features you can easily find a lot of URLs that you should not know exist. For example, I can find paths to yet unannounced product images.

URL Parameter Tampering

A User wants to delete a post after clicking on the delete button and a request is sent to recepies.com/posts/delete/22 and the post is deleted. This route needs to be protected to check whether the user is an author of this post, or else the user will be able to delete any post by modifying the URL recepies.com/posts/delete/46. The same can happen if you would use something like recepies.com/posts/delete/?post=22&userId=312 for user validation because a user can still easily guess or find somewhere correct userId for the post, modify the URL recepies.com/posts/delete/?post=46&userId=254 and delete the post.

URL parameters should never be used for user verification or role validation recepies.com/dashboard/?userId=312&role=author can easily be changed to recepies.com/dashboard/?userId=254&role=admin. The same goes for any HTTP request method, the POST request body is also easily modifiable

URL tampering is also a common way for context-dependant vulnerabilities, for example, a user initiates the checkout process and gets redirected to checkout cart example.com/checkout/cart after making changes user proceeds and finished the checkout process and ends on example.com/checkout/success page. Then user changes URL back to checkout cart URL example.com/checkout/cart to access latest cart that was in the checkout process and modify it.

JWT (JSON Web Token) Tampering

One of the most popular authentification technic is JWT.
JSON Web Token is a string like eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Which consists of three parts separated by a dot:
Header eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9,
Payload eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
and Signature SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c. Source JWT.IO

Header and Payload are easily decodable so you can read their contents, however, modification of them needs knowledge of signature secret or token will be invalid.
Example of changing content without encoding it with a correct secret. Source JWT.IO

The most common reason for JWT vulnerabilities is related to misuse or using vulnerable/outdated packages. For example, if no signature verification is implemented on the server side attacker can easily modify the payload and it will work despite it having an invalid signature. Also, some outdated libraries can allow you to change Header's "alg": "HS256" part to "alg": "none" which will remove the signature completely.

Cookie Tampering

Cookies are key-value pairs that are stored in your browser. Compared to local storage and session storage, Cookies are sent to a server on every request* this gives users the ability to store stateful information and removes the necessity of re-authorization on every request. You can easily see and even modify them using browser's devtools, so in idea, you can do the same as in previous attacks and just turn something like role | user into role | admin. However such vulnerability is really rare because cookies are usually encoded and validated on the server side.

* if cookies are set to the same path as the request domain. Also in case if Secure flag on a cookie is set then it will be sent only over HTTPS.
P.S. HttpOnly flag prevents cookies from being accessed by javascript via document.cookie, to protect users from Cross-Site Scripting (XSS) attack

Headers Modification

Referer is an HTTP request header that contains an address to the page that made the request. Some web apps use it for access control after admin logs into /admin server uses Referer header to verify that user is admin and allow admin actions to be performed. For example admin makes request to /admin/delete/user/2 from admin dashboard page /admin so Referer header is set to /admin. However, you can easily get around such validation by making a custom request to /admin/delete/user/2 and manually writing headers: { Referer: /admin }

CORS Misconfiguration

Cross-Origin Resource Sharing (CORS) is a mechanism that uses HTTP headers to control access to resources located outside of the origin domain. Basically, CORS allows or prevents server from replying to requests that were sent from domains other than its own. The most important part of CORS is Access-Control-Allow-Origin header that is used to whitelist domains that are allowed to make requests to the server, the value can be wildcard "*", URL "example.com" or "null".

Misconfiguration can happen if ACAO header is set to a wildcard or server is using flowed whitelist or regex for ACAO. For example, if a user is authenticated to your website with misconfigured CORS, and then the user visits naughty-website.com this website can make any request to your website as an authenticated user because no origin is checked and anyone is allowed to make a request.

Geolocation Manipulation

Almost every media service such as Netflix, Spotify, etc. uses geolocation for access control, because of legislation, restrictions, or agreements. Such limitations can easily be avoided by users using proxies or VPNs.

Source: OWASP TOP 10