Hacking OWASP Juice Shop: Part 5- Privilege Escalation via Manipulated User Registration

I hope you enjoyed Part 1, Part 2, Part 3 and Part 4. Here, I’m starting Part 5, which focuses on additional vulnerabilities discovered in OWASP Juice Shop. Here, I’ll delve into issues such as bypassing user role restrictions, posting feedback in another user’s name, and manipulating registration to gain administrative privileges. These vulnerabilities illustrate significant gaps in both application logic and security practices that can be exploited to achieve unauthorized access and perform unintended actions.

NOTE: I’ll add an important narrative at the end.

The task is to upload a file that has neither a .pdf nor a .zip extension, as those are the only allowed file types. I selected a .pdf file and clicked submit, but intercepted the request using Burp Suite and removed the .pdf extension from the filename. This allowed me to bypass the file type restriction.

Twenty-second vulnerability: Bypassing file type restrictions by modifying the request payload to upload a file without a .pdf or .zip extension.

The task is to register as a user with administrator privileges. To achieve this:

I tried registering a new user and filled in the necessary details, then intercepted the request. I noticed that when creating my previous test account, the response body included:

In my new request, I decided to append "role":"admin" to the request body:

This allowed me to successfully create an account with admin privileges.

Twenty-third vulnerability: Bypassing user role restrictions to register as an administrator by modifying the request payload.

The task is to post some feedback in another user’s name. Here’s how I achieved it:

I decided to post a review with the following request body:

In response, I received:

I then changed “anonymous” to “test+1@gmail.com” in the request body:

NOTE: i didn’t sign in that is why the comment has anonymous in bracket.

I sent the request, and it was successful, but I did not receive any message indicating the task had been solved.

Suspecting that the system uses the UserId to specify users, I modified the request body to include UserId:

This resulted in an internal server error, but the review went through, and I successfully solved the challenge.

Twenty-fourth vulnerability: Posting feedback in another user’s name by manipulating the request payload to include a different email and UserId.

That’s all for now. Thanks for reading! Don’t forget to drop a like. You can subscribe to get the next write-up delivered straight to your inbox.

Look-up Part 1, 2, 3 & 4:

For any suggestions or Correction, Kindly reach out to me:

Twitter — callgh0st

Imam Ali A.S : The most observant person is one who sees his own faults and refrains from his sins.