Hacking OWASP Juice Shop: Part 1 - Discovering Critical Vulnerabilities

In the Name of Allah, the Most Beneficent, the Most Merciful.
All the praises and thanks be to Allah, the Lord of the ‘Alamin (mankind, jinns and all that exists).

I decided to check OWASP Juice Shop today. I will be writing about all the vulnerabilities and security issues I encounter, starting with testing the login functionality. This write-up will be the first, and I will indicate this in the title.

I tried using ' OR 1=1-- as the email and a random password, and it logged me into the admin account.

First vulnerability: Login is vulnerable to SQL injection.

I clicked on the review section and noticed some users had left reviews. I thought, “What if I can log in as these users using SQL injection?”

I tried the following email addresses:

• bender@juice-sh.op
• stan@juice-sh.op

However, instead of logging in as those users, it logged me into the admin account.

Second vulnerability: Some User login is also vulnerable to SQL injection, but it grants admin access instead of the targeted user account.

I created a test account: test+1@gmail.com. I noticed that the system allows a user to use their email as their password and also as the answer to the security question. This should not be allowed for security reasons.

Third vulnerability: The system permits using the same email address for both the username and password, compromising account security.

I went back to Burp Suite and noticed a POST request to /api/Users/. Curious, I sent it to the Repeater, removed the POST body, changed the request to GET, and sent it. I received a response error:

{
  "error": {
    "message": "No Authorization header was found",
    "name": "UnauthorizedError",
    "code": "credentials_required",
    "status": 401,
    "inner": {
      "message": "No Authorization header was found"
    }
  }
}

I checked the site map for any requests with an Authorization header and found one. I decoded it and discovered it was the admin authorization token. I added it to the request, hoping it would work, and it did. I received users’ emails and roles in the response. I can log in using SQL injection without needing a password.

Fourth vulnerability: PII disclosure due to improper authorization checks.

Note: Normal user authorization tokens also worked.

I made a request to /api/ after removing /Users/ from the endpoint, which triggered a stack error. I consider this a security issue.

Fifth vulnerability: Stack trace disclosure due to improper error handling.

I noticed a header GET /rest/products/search?q= and tried apple' OR 1=1. This triggered an error that revealed the database name and the location of the error.

{
  "error": {
    "message": "SQLITE_ERROR: near \"' OR 1=1%'\": syntax error",
    "stack": "Error: SQLITE_ERROR: near \"' OR 1=1%'\": syntax error",
    "errno": 1,
    "code": "SQLITE_ERROR",
    "sql": "SELECT * FROM Products WHERE ((name LIKE '%apple' OR 1=1%' OR description LIKE '%apple' OR 1=1%') AND deletedAt IS NULL) ORDER BY name"
  }
}

Sixth vulnerability: Information disclosure due to improper handling of SQL errors.

I triggered another error via the /api/BasketItems/ endpoint by inputting a value it didn't expect (e.g., -1). This revealed more information about the database.

Seventh vulnerability: Information disclosure due to improper validation of user input.

I noticed that a normal user can’t view the users who liked a particular product. By changing the authorization header to that of an admin, I was able to get the emails of users who liked the product.

Eighth vulnerability: Privilege escalation allowing unauthorized access to user emails.

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

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

Twitter — callgh0st