face-smilePath: /catalog

Path: /catalog			
Vulnerabilities: Client-side template injection, Cross-site scripting (reflected), DOM data manipulation (reflected DOM-based), HTTP response header injection, Link manipulation (reflected DOM-based), SQL injection

Vulnerability 1: SQLi

Testing For SQLi Vulnerability.

When I clicked on the pre-made categories listed on the website, such as All, Accessories, Accompaniments, Books, Gin, and Juice, the URL changed to include a query string. The query string has a parameter named category that accepts the selected category value.

https://ginandjuice.shop/catalog?category=Accompaniments

Modified URL:

https://ginandjuice.shop/catalog?category='

Running this Query gives an Internal Server error.

This means SQLi can be possible.

Let's try SQLi payload.

I will capture the request and send it to Burp Intruder.

In the intruder I will test for not internal error message.

I am well aware that this is an authentication bypass payload, but if any query works, we can use similar types of queries to exploit other vulnerabilities.

In the intruder, Add Payload and grep match value as "internal".

I will utilize any payloads that do not result in an internal error.

This is search form. So, I will try union based Payload.

Using Union payload:

Determining number of column present.

I will use intruder again for the same. Just check the paylaod and Number sequence.

I have set value range from 0 to 20 WITH step size of 1. Also, Privouly applied Filter of "Internal" is applied. Start the attack.

I can see that there is no error from 1 to 9. So, We can assume that there is 9 columns present.

Now, Let's Determinal each column type.

This worked perfectly fine. That is it didn't gave any error.

Now I will check which all position can have String value. For this I will make use of intruder of burpsuite. You can also do mannually.

Capture and sent the request to intruder. Add all NULL in payload rotation one.

All the value with status code as 200 has data type as string.

So, Let's try the payload now.

This will give all the schema present.

Query returned Two schema that is INFORMATION_SCHEMA and PUBLIC .

I will check the tables which are present in PUBLIC Schema.

circle-info

When I used small letter in the name of the table "PUBLIC", It didn't display any output.

Found Three tables named PRODUCTS, TRACKING, USERS.

Now let's try to fatch the data of users table.

Command for getting column name is:

Payload for getting COLUMN names:

Encoded:

Got Columns name as USERNAME,PASSWORD,EMAIL.

Let's try to fatch the content of USERS tables.

This above command gives error.

Value can be displayed only one by one.

Extracting Username:

Extracting Password:

There is only one user present.

SQL injection (SQLi) vulnerabilities can result in the exposure of sensitive user information.

Vulnerability 2: Client-side template injection

This vulnerability is exploitable and exists in the /blog directory, where we have previously identified it.

[Refer from there]

Vulnerability 3: Cross-site scripting (reflected)

This vulnerability is exploitable and exists in the /catalog/subscribe directory, where we have previously identified it.

[Refer from there]

Vulnerability 4: DOM data manipulation (reflected DOM-based)

This vulnerability occurs when user-supplied data is parsed or echoed by the application into a part of the DOM, allowing an attacker to manipulate the response and trigger the DOM-based vulnerability.

I will verify whether the transmitted value is correctly parsed by the browser.

Testing Value:

If this value is displayed in bold by the browser, it confirms the existence of the vulnerability.

Original URL:

I will add my test value and see if it is displayed in broswer in bold.

Value is displayed in the Browser but not in bold.

Trying Other way:

The attempted payload did not display the provided value.

There is one more input field for subscribing for updates. I will capture the request and add my payload in the email to see if it gets parsed.

The value is not displayed, and only an error message is shown.

Upon analysis, it appears that there may be a potential false positive alert during vulnerability scanning.

Vulnerability 5: HTTP response header injection

This vulnerability occurs when user-supplied data is copied into an HTTP response header in an unsafe manner, allowing attackers to inject headers, modify the response body, or deliver various attacks such as cross-site scripting and cache poisoning.

For Testing testing I will pass X-Forwarded-To HTTP header in request filed and see if it is shown in response or not.

I have included New Line charector after the Search Term value. "%0d and %0a" then HTTP header.

Captured the request and forwared but I didn't see the HTTP header in response.

Reflected DOM-based vulnerabilities occur when user-supplied data is copied from a request and dynamically echoed into the DOM without proper sanitization. This can allow attackers to manipulate the application's response, enabling exploits like redirecting users to malicious sites, intercepting sensitive data, or executing unintended actions.

This vulnerability resembles DOM data manipulation; hence, the steps for verification remain the same. After conducting a thorough check, I concluded that this method is ineffective.

The issue might be due to a false positive alert.

Last updated

Was this helpful?