Skip to content

Tag: Web Security Academy

Notes on Blind SQL Injection

https://portswigger.net/web-security/sql-injection/cheat-sheet

Lab: Blind SQL injection with conditional responses

https://portswigger.net/web-security/sql-injection/blind/lab-conditional-responses

In this lab, we are using the responses to enumerate the password of the “administrator” account. First, we need to perform a check on whether the “administrator” account exists and the length of the password. Once this is done, we will perform a substring query to enumerate each of the character of the password.

You can use Burp Repeater or Intruder to enumerate the password. I find both methods to be time-consuming. I wrote a script to enumerate the password instead. The script will look for “Welcome” value in the response. If it is true, the script will note down the character and continue to the next position until all the password character is enumerated.

Lab Write-up: Exploiting XXE to perform SSRF attacks

In this post, you will see how an XML external entity attack can be exploited to perform a SSRF. The lab can be found in this link (https://portswigger.net/web-security/xxe/lab-exploiting-xxe-to-perform-ssrf).

In the lab description, it was mentioned that the app server is running on AWS’s EC2 instance. To retrieve metadata about the server, you will need to inject an external entity to call this url:
http://169.254.169.254/

The next thing to take note is to notice the XML payload is being posted to the server. Below is the screenshot:

If you try to change the Product ID value to a random string, you can see that the response is showing the random string back. This means that you can inject the metadata to Product ID to retrieve the information.

Notice when we change to product ID to ‘testing123’, the value will be reflected back.

You will need to inject the below external entity into the XML payload:

The response will return ‘latest’. But what the hell is that? It took me a while to figure out that this is a folder name.

You see now that the URL is ‘http://169.254.169.254/latest’, the value ‘metadata’ is returned.

Eventually, when you keep appending the folder name to the URL, you will see the AWS EC2 metadata.


Lab Write-up: SSRF with filter bypass via open redirection vulnerability

This is a writeup on one of the SSRF labs by Portswigger.
https://portswigger.net/web-security/ssrf/lab-ssrf-filter-bypass-via-open-redirection

You can try to produce intentional errors by providing unicode values. This cause the stock check server to return some error message. From below screenshot, we can see that the url is actually:
http://localhost:80/product/stock/check?productId=1%26storeId=12

Another thing you can play around is to decode the payload and send the request. Notice the response is returning “Missing parameter”. This is because you need to encode the ‘&’ character. Probably there is some sort of blacklist filter. Let’s learn to double encode to bypass the filter.

Another observation we can make is to look at the source code. We can see there is an open redirect in the “Next product” function. So the keyword for redirection might be ‘path’?
https://acfe1fda1fa0f12e80181f3300d500a8.web-security-academy.net/product/nextProduct?currentProductId=4&path=/product?productId=5

First attempt, we try to see if the stock check url has any open redirect. It turns out that it just return the stock value without performing any redirection. You can try other keywords like view / url / path etc. and still it will not redirect. So this doesn’t work.

Second attempt, we take the url payload from ‘Next Product’:

/product/nextProduct?currentProductId=4&path=/product?productId=5

Replace the current path value with the admin url ‘http://192.168.0.12:8080/admin’. The below screenshot shows that the redirection is successfully and we can see some of the admin functions appearing.

Now, you can exploit the SSRF vulnerability by sending a delete request using the admin URL.