OWASP JUICE Shop Solutions : -

Karim Ahmed

13 min readDec 12, 2024

1-SQL INJECTION [union based] :

SQL injection in search bar : /rest/products/search?q=

Retrieve All the Data Base Schema

if we try to search then intercept the request

if we tried to make error with SQL to see if we see the error in the response :

We got a SQLITE ERROR

So we know that server is using SQLITE and in SQLITE database name is sqlite_master :

You can read more about SQLITE here : https://www.sqlite.org/schematab.html

apple'))UNION%20SELECT%20*%20FROM%20sqlite_master -

We got error in the number of columns:

We can use order by to know the number of columns

ORDER BY 3 
apple'))ORDER%20BY%2012

So We have 9 Columns , now Let’s continue So we can retrieve the database schema

ap'))UNION%20SELECT%20sql,2,3,4,5,6,7,8,9%20FROM%20sqlite_master -

And Now we can see all the database Schema

Prevention and Mitigation Strategies: Using just parameterized query

=====================================

2-Boolean-Based SQLI

SQL injection in login page :http://localhost:3000/#/login

Let’s Try to use simple SQLI payload

or 1=1 ; -

We Could sign in as admin as admin was the first in data base which so we can now easily navigate to the admin panel .

If we just tried some default admin panels name like
admin — administrator — admins — [admin-panel]-administration we can use intruder in burb suit or u can see the file main.js

Using administration worked now we are in admin panel

Prevention and Mitigation Strategies : Using just parameterized query

=============================================

3-Dom XSS :

Search Bar

DOM XSS occurs when the client-side JavaScript code modifies the DOM based on user input in an unsafe manner, leading to script execution.

Let’s Try Simple script

<script>alert(1)</script>

The script didn’t work .

Let’s try image tag

<img src=x onerror=alert('XSS')>

It did work

Now we can make in image tag put onerror redirect link

img src=x onerror="window.location='attcker.com'">

or Cookie stealing

Prevention and Mitigation Strategies :Implement proper input validation and output encoding. Use security libraries and frameworks that handle these issues automatically.

===========================================

4-Improper Error Handling or Information Disclosure

We employed Dirp, a directory brute-forcing tool, to enumerate directories and files on the target application. By using wordlists and custom configurations, Dirp helped uncover hidden endpoints that could aid in further exploitation or information gathering

So First Let’s go to the [*/ftp]:

From all these files, the file named `[acquisitions.md](<http://acquisitions.md>)` contains a line stating that **it is a confidential document

Confidential documents should not be stored in such open directory

Let’s see the [coupons_2013.md.bak]

As we see it’s an error that should not regular user see ,If you’re using a vulnerable version of a framework or library (like Express 4.17.1 in this case), attackers might exploit known vulnerabilities

Prevention and Mitigation Strategies: Log detailed error information server-side but do not expose it to users -Conduct tests to ensure errors do not expose sensitive information.

=============================================

5-Stored XSS :

Register page

After sign up If We intercept the request :

note: use back slash to escape quotes ==> escaping client side security

Let’s Send the request and see

Good , due we now admin has access to all the users logs or registered users so the attack should work properly when admin access the admin panel [/administration]

=============================================

6-Reflected XSS :

target

After Ordering a Product
we can choose Track order :

In the URL we Can see id parameter .
We can test our payload

[<script> alert(1) </script>]

It Did not Work .

Lets Try another one:

[<iframe src="javascript:alert(`xss`)">] or 
<img src='x' onerror=alert(1)>

=============================================

7-Unrestricted File Upload

in: /#/complain

Change the file size of file uploaded

In Complaint form :

Intercept The request :

The Selected Part we test if we make it bigger than allowed 100kb

Example:

Forward Our Request :It did work which leads to : Denial of Service (DoS) Attacks , This can result in system crashes, slowdowns, or resource exhaustion

Prevention and Mitigation Strategies : Enforce Server-Side Validation:
Validate file size, type, and content on the server, regardless of client-side restrictions.
Set Maximum Upload Limits:
Configure maximum file size limits at the web server and application levels (e.g., php.ini settings like upload_max_filesize and post_max_size).

===========================================

8-Unrestricted File Upload

in: /#/complain

Change the file type of file uploaded

In Complaint form :

MANPULATE FILE TYPE

As we see here :

IT takes only PDF Or ZIP So let’s Try another type :

Hit send in burp suit

As we see We Could
MANPULATE FILE TYPE And ===>This leads to Web Shell Upload -Remote Code Execution (RCE)

Prevention and Mitigation Strategies:
Restrict Executable Files : Deny uploads of files with extensions like .php, .jsp, .exe, .sh, or any executable type.
Verify MIME Types : Compare the MIME type with the file’s actual content and reject mismatches.

=============================================

9-Authentication vulnerability

in:/#/login

Brute Force Login (or Password Enumeration)

Lets Try log in as admin ,After good recon we can see that every user ends with [juice-sh.op]

So let’s assume our admin email is admin@juice-sh.op

And now let’s see if the website well let us enumerate the password .

First Open Burp Suit and intercept the request

Let’s Send To the intruder :

choose the password value as our place we need to try our common password list Start the attack

As we see we Found that password is [admin123]

Prevention and Mitigation Strategies: Limit Login Attempts: Implement account lockout or rate limiting to prevent rapid brute-force attempts.
Strong Password Policies: Ensure users are required to use strong, complex passwords that aren’t easily guessed.

=============================================

10-IDOR

in : view-basket

change basket_id=2to basket_id=randomNum) and access and see or modify another user's basket

After using developer tools (e.g., browser’s Developer Tools or Burp Suite) to inspect the session while viewing our basket we noticed a parameter, such bid, in the request that identifies the basket being viewed.

Let’s Try changing The [bid]

As we see We could See another user Basket

10.2- Another way :

Check the HTTP traffic while placing products into our own shopping basket to find a leverage point.

We can See in the request BasketId :

First Let’s Send To Repeater
So let’s try to change the basket id :

Ok Let’s try HPP let’s simply add the parameter [ BasketId] again with another value

note: If you Do not HPP here is link ==> HPP

And it worked

Now if we next time manipulate both basketId and quantity we can add more products in another user’s basket

Prevention and Mitigation Strategies: Implement proper access control checks on both server-side and client-side. Validate user permissions for each action to ensure users can only access and modify their own resources

=============================================

11-Horizontal Access Control Violation

in :/rest/product/*/review

where * any number

Change The Review Original Author

IF We need To change a review’s author ,so First Let’s review a product

I Already Let my burp suit open ,So let’s See The requests

The highlighted , Let’s send To repeater

Here As we see in the request the message and it’s author are sent in the body ,so we can try to change it to another user .

As we see it did really worked .

Prevention and Mitigation Strategies:
Verify Ownership: When a user attempts to modify or interact with a review (e.g., changing the author or editing the review), ensure that the logged-in user is the owner of the review or has permission to modify it.
Access Control: Implement role-based access control (RBAC) or object-level access control to restrict actions based on user roles. Only authorized users (e.g., admins or the actual author) should be allowed to change the review’s author or edit the content.

=============================================

12-Improper Input Validation :

The basket functionality is vulnerable to improper input validation .I can modify the parameter quantity in my basket to be negative

First : If we try to intercept the requests of adding products and check the burpsuit http history :

Send to repeater and Let’s see how the app deals when put the quantity with negative value :

Send our request and see :

As we see it accepts the negative value now Let’s normally continue the payment .

As we see the number I will pay is (-7.49) which is not normal now let’s pay and check our wallet .

As you see we got money instead of paying for purchasing items .

Prevention and Mitigation Strategies:Perform server-side checks to validate the quantity before processing transactions

=============================================

13-Cross-Site Request Forgery (CSRF) :

The change password functionality is vulnerable to CSRF attacks

First Let’s intercept the change password Request :

Let’s Send to see the response :

Successfully changed to the new password

Now Let’s see if we can change current password to any thing so we see how it deals with it :

send it :

That was incorrect so that means we can not perform CSRF until we know the current password , so let’s try to remove the current and send the request :

That is good now we can send the request without the current password , so now there is no any parameter we do not know its value now we can perform our CSRF attack .

<html>
  <body>
    <form action="http://localhost:3000/rest/user/change-password">
      <input type="hidden" name="new" value="password" />
      <input type="hidden" name="repeat" value="password" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

Prevention and Mitigation Strategies: Implement anti-CSRF tokens to validate the authenticity of requests. Ensure that all state-changing requests require a unique token that is verified on the server-side.

=============================================

14-Brute force attack :

In Forget password

There is important parameter which is [answer ] means before we attempt to change another user’s password we need to know what is the answer of his security question
First I did not think in the brute force attack ,so let’s intercept the forget password request

As we see there are 4 parameters and I put the victims email so first let’s send to see the response.

As expected wrong ok now , what I did think in was first
let’s send the request with no answer parameter maybe it will pass and successfully change the password.

We got error :

Second thing we tried let’s put our email or email we know it’s answer and put victim’s email :

AGAIN GOT ERRRO :

so I did think in the brute force attack on the answer , so let’s send to intruder .

We got our target is the answer
so i got simple common list of names and a list based on the questions

[Your eldest siblings middle name?
Mother's maiden name?
Mother's birth date? (MM/DD/YY)
Father's birth date? (MM/DD/YY)
Maternal grandmother's first name?
Paternal grandmother's first name?
Name of your favorite pet?
Last name of dentist when you were a teenager? (Do not include 'Dr.')
Your ZIP/postal code when you were a teenager?
Company you first work for as an adult?
Your favorite book?
Your favorite movie?
Number of one of your customer or ID cards?
What's your favorite place to go hiking?]

============================================

15-Improper Input Validation [2] :

Gain Deluxe membership with no paying using burpsuit

First After Creating new account Let’s navigate to the deluxe membership

Click on the Become a member :

As we see We do not have the proper amount in our wallet , now using burpsuit Intercept the request :

So First Let’s see if we can send the request with no [paymentMode] value

send the edited request :

Prevention and Mitigation Strategies: Validate relevant information on the server side. The server should not issue a deluxe token or change the user’s role without verifying that payment had been received. That it didn’t even verify that a mode of payment had been selected is a major flaw, and one I would hope is extraordinarily infrequent in the real world