In the following screenshot, you have a vulnerable application and you have intercepted the next request:
We have their parameters in this request; login, action, and secret. The vulnerable parameter here is login. The secret variable is the data assigned by the user during their registration; the vulnerability that exists is that if the malicious user modifies the login parameter, the application changes the secret value for the user specified without validation. So, we have created another user called vendetta2, to try to modify the secret value pertaining to this individual, as demonstrated in the following screenshot:
Now, click on Intercept is on to send the modified request, as shown in the following screenshot:
As you can see, this vulnerability could be used to perform actions that are not authorized for the user who is doing them, but it could also be used to access restricted information, for example, information that is the property of another user, but if you modify an ID, a username, or an identificatory, it could be accessible. Take the following example:
POST /blog/information.php HTTP/1.1 Host: 192.168.1.66 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded Content-Length: 41 Connection: close Cookie: PHPSESSID=b1500088ce194bd822cc2b3d0ff3320f Upgrade-Insecure-Requests: 1 user=vendetta2&action=show
This vulnerability is located in a blog application, which shows certain information depending on the data saved in the user parameter. If the malicious user modifies the user in the request, the application will show the information of another user.
Other common variations of these kinds of bugs are when the information that is used as an identifier is passed, not as the parameter in the request, but in the header itself. Take the following example:
POST /blog/information.php HTTP/1.1 Host: 192.168.1.66 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded Content-Length: 41 Connection: close Cookie: PHPSESSID=b1500088ce194bd822cc2b3d0ff3320f Upgrade-Insecure-Requests: 1 action=show
In this case, we do not have the parameter user, but we have one element to track the user; it is the session ID: PHPSESSID. It is common in applications that if you modify the session ID to another that is used by a valid user, it could affect this user. Note that in these cases, it is necessary to modify the session ID in each request, because when you send another request, it will be changing to the original.
In order to avoid this issue, you can add an order in the Options tab of the Proxy tool to modify a value in each request, as demonstrated in the following screenshot:
