If you don't know about this vulnerability, please read the following article for details. In short, it is a series of problems caused by the attacker's request becoming the victim's request.

First loophole

During the exercise, I simply searched all post requests, and then added a simple payload to detect after the request. Although I found the vulnerability in the end, I did not successfully exploit it to control user requests.

Here I used intruder to verify the vulnerability, and finally the request returned sensitive information of the user, and the "victim" request has been controlled by me.

Second loophole

When I found the first vulnerability, I learned how to better detect it, and a few days later I found the first.

This time, the target website is a shopping website, and this kind of vulnerability is found in the delivery address function point.

I managed to redirect the victim's page to 404.

Now that I'm no longer satisfied with the victim control request, I've decided to find a reflection point. At first, I wanted to find an XSS, and self XSS was ok, but unfortunately I didn't find it. Then I decided to try to save the "victim" data where I could view it. At first, I chose the address in "save address", but I found that there was a limit of 50 bytes, which I failed to get around after a period of attempts. Then I began to search again, tried "personal data" and other places, and finally found the appropriate place of invoice title in "Print Invoice".

Next I'll attack. I use my own cookie to send a request to save the victim's information as the title of my invoice.

At first, the attack failed because I didn't add content length to the request.

But the attack succeeded after debugging! I successfully got sensitive information such as "victim" cookies!!