#IBRAHIMXSS Tool Commands

1. GET Request: http://testphp.vulnweb.com/listproducts.php?artist=1

Dealing with GET requests in the #IBRAHIMXSS Tool is very simple, like other
commands. Basically, for a GET request on a URL, we need a query parameter (e.g.”=”).
Any query with a value will work, and the tool will automatically search for all queries in
the URL. If there are multiple queries, the #IBRAHIMXSS Tool will send payloads one by
one to each query. If there is only one query, it will send all payloads to that query. In this
example, it will send payloads to "artist=1," changing the value '1' to our XSS payloads.

Always use --shuffle to avoid WAFs, as this option shuffles URLs and payloads,
ensuring they are mixed and not all sent to one URL. Additionally, use --threads with a
value between 10 and 20, depending on your PC's performance. The optimal number of
threads is 15, which worked best for me.
After you run a command, the tool will start, and you will see alerts marked in green.
This means #IBRAHIMXSS has confirmed an alert. You will also see the payload that
was used, the targeted URL, the page title, and the detected WAFs.

After a few seconds, a Chrome window will pop up with an .html report, including a
screenshot, the payload used, and the affected URL. You just need to click on the URL,
and the payload will trigger.
 2. PATH Request: https://brutelogic.com.br/xss.php/

If we want to test a Path-based XSS, we need to include the --path feature from the
#IBRAHIMXSS tool. This feature will randomly inject our XSS payloads into every path
segment ("/") starting from the home URL path to the last path. If we want to inject only
on a specific URL path, we need to declare and mark that place.

For example, on this URL: https://brutelogic.com.br/xss.php/

If we only want to test path-based XSS on "xss.php/", we need to place the payload on it
like this: https://brutelogic.com.br/xss.php/{payload}

Our payloads will be sent to that specific path.

After some time, our tool will send payloads to xss.php/*, and you will see in the
terminal that we are getting alerts at that location.

After that, our report will open in Chrome, showing all possible vulnerabilities.
This was an example of injecting path-based XSS at a specific marked place with
{payload}. However, if we don't place a {payload} in the marked place, #IBRAHIMXSS
will automatically inject into every possible path, as shown in the image below.

Don't forget to always include the --path option for testing path-based XSS. Whether you
want to place {payload} or not, you always need the --path option for path-based XSS
testing.

In this image, you can see that payloads are randomly injected one by one into each
path segment of the entire URL.

For example, in the URL: https://public-firing-

range.appspot.com/reverseclickjacking/singlepage/ParameterInQuery/OtherParamete ,
the tool will inject payloads into all path segments: reverseclickjacking, singlepage,
ParameterInQuery, and OtherParameter.

As you can see, we got our XSS alert in the last OtherParameter path.
In the end, we will get our report.

3. DOM-based Request: https://public-firing-

range.appspot.com/address/location.hash/assign#

In this section, we will talk about DOM-based XSS. It's the same procedure as for
path-based XSS; we just need to place our {payload} in the desired place with #, and
that's it.

Also, one note: it's the same for GET query requests. If we have more parameters with =
in the URLs, we need to place {payload} on the desired query we want to test. But we
still need to include --path. So, to make this clear, using --path with the {payload} mark
will inject on your desired places in GET requests, and using –path without {payload}
mark it will randomly inject in all places.
And we tested our "assign#" parameter. As you can see, we got alerts on that because
we placed {payload} as assign#{payload}, and it tested there.

4. Extension-based XSS with #IBRAHIMXSS Tool:

Tested url: https://indiamp3.net/download/telugu-mp3-songs/1.html

If we want to test XSS in file extensions, because sometimes they are not properly
filtered and sanitized, we can also get XSS alerts in those cases. We can do this by
placing the XSS payload in the file name and triggering it. Additionally, we can change
the extension name in a GET request to an XSS payload.

For example, with the tested URL: https://indiamp3.net/download/telugu-mp3-

songs/1.html
If we want to test 1.html, we just need to replace 1 with {payload}. The tool will then
send our XSS payloads instead of 1, effectively injecting the payloads in place of 1.
 5. POST Request: http://testphp.vulnweb.com/guestbook.php

For POST requests, in normal POST requests, the data will be URL-encoded. We need to
place our {payload} marker on the desired text and body fields that we want to test.

For example, on http://testphp.vulnweb.com/guestbook.php , there is a field "text" on

which we can make a POST request. What we need to do is place {payload} in that field,
then intercept that request with Burp Suite. We need to check if the {payload} is well
formatted; sometimes it will be URL-encoded. If it is, just remove the encoding and
place a clear marker {payload}.

After that, right-click on the request in Burp Suite and choose the option "Copy to file."
Then, save it as a .txt file in the same folder where our tool is located. In our example, we
will save it as request.txt.
After that, we need to run our command for the POST request:

--post --request request.txt

If the domain is HTTP, we need to include --http. If the domain is HTTPS, we don't need
to include it, as it's defaulted to HTTPS.
After we run our tool and the report pops up, we will have a screenshot of the page, the
payload used, and the request file indicating where it was executed. You will see that all
our payloads are placed in the “text=” field.

Now, open http://testphp.vulnweb.com/guestbook.php and you can manually test each

payload to confirm that there is XSS and that our tool was accurate.
For our POST requests, we have three parts:

1. Normal URL-encoded POST

2. Multipart with multiple Content-Disposition headers

3. Content-Type application/json

We already covered the first part with a normal URL-encoded POST on

http://testphp.vulnweb.com/guestbook.php.

Now, let's move on to the second option: Multipart with multiple Content-Disposition
headers.

Basically, it's the same as above, but we need to include one more feature, which is
--multipart, to handle multipart Content-Disposition headers. That's all.

Here's the updated command:

First, we need to go to http://myproject234.rf.gd/login.php and log in to the WebApp

with the credentials admin:admin123. After logging in, visit
http://myproject234.rf.gd/post.php and enter our POST requests into the Text field to
test them.

The command will be:

--post --request multipart.txt --multipart

For the Content-Type application/json part, it's similar to the previous methods. We
just need to include a new feature, --json.

The command will be:

--post --request json.txt --json

In --json, we will not get any XSS alerts in your terminal because it's JSON. We need to
manually go to the domain URL we are testing and refresh the page where we are
sending our payloads. If it's vulnerable, we will get hundreds of XSS pop-ups on that
page. If it's not vulnerable, our payloads will just be sent there without any trigger.
Do not forget that for all three types of POST requests, the procedure is the same:

1. Put {payload} in the desired place.

2. Intercept the request with Burp Suite.

3. Save the request from Burp Suite by copying it to a file with a .txt extension.

Just decide which type you need: ordinary POST, --multipart, or --json. It depends on the
type of POST request your WebApp uses.

I hope you now better understand the #IBRAHIMXSS commands.

Happy hunting!

Best regards,
Ibrahim,
#IBRAHIMXSS Tool