xsser does not send any payload

[rhalyc]

I am trying to use xsser against dvwa but it looks like it is not working properly.

I am executing: xsser -u "http://localhost/vulnerabilities/xss_r/" -g "?name=" --cookie="PHPSESSID=rq8fvbrqv2pvr4ob622joj99s3; security=low" --proxy http://localhost:8080 --auto

I am using Burp as proxy to capture the requests and I have observed that when xsser request: GET /vulnerabilities/xss_r//?name= HTTP/1.1 Host: localhost User-Agent: Feedfetcher-Google; (+http://www.google.com/feedfetcher.html) Cookie: PHPSESSID=rq8fvbrqv2pvr4ob622joj99s3; security=low Accept: image/gif, image/x-bitmap, image/jpeg, image/pjpeg Connection: close Content-type: application/x-www-form-urlencoded; charset=UTF-8

and when the response arrive, in terminal is printed:

[-] Hashing: 9ab07af70c1a97ea93f18b2fe7400b35 [+] Trying: http://localhost/vulnerabilities/xss_r//?name= [+] Browser Support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02] [+] Checking: url attack with ">... fail

So, you can see that xsser has never sent the payload that was supposed to be sent. This is happening with each payload.

[epsylon]

xsser has never sent the payload that was supposed to be sent ;-) Did you tried using http://127.0.0.1?. Or you changed your target for localhost just for publishing? BTW, if you are trying a proxy (MIM) xsser is sending request to that place correctly, so I don't understand why you say that request has never sent.

[rhalyc]

I'm sorry, I think I could have expressed myself better. What I mean is that when running "xsser" the tool indicates that it will test for example the payload ">. However, when capturing the request using "Burp" that payload is not in the request. So either something is not working for me, or I don't understand how "xsser" will detect that there is a vulnerability if it doesn't send any kind of payload to see if the server returns it in the response.

I was testing "xsser" locally against DVWA but I couldn't get it to detect the XSS vulnerability.

[epsylon]

And how is that PAYLOAD at your request? Look at this schema provided with the FAQ -> https://xsser.03c8.net/xsser/url_generation.png At XSSer you have: PAYLOAD and VECTOR. They are different words that explain different parts of an injection. Can you try it again, but using a more verbosed mode?: xsser -u "http://localhost/vulnerabilities/xss_r/" -g "?name=" --cookie="PHPSESSID=rq8fvbrqv2pvr4ob622joj99s3; security=low" --proxy http://localhost:8080 --auto --no-head -v

[rhalyc]

I have executed it, this a copy paste of part of the output:

$xsser -u "http://localhost/vulnerabilities/xss_r/" -g "?name=" --cookie="PHPSESSID=u0qe073vrrbk2avp41c1nu8ue1; security=low" --proxy http://localhost:8080 --auto --no-head -v
===========================================================================

XSSer v1.7b: "ZiKA-47 Swarm!" - 2011/2016 - (GPLv3.0) -> by psy

===========================================================================
Testing [XSS from URL]...
===========================================================================

[-]Verbose: active
[-]Cookie: PHPSESSID=u0qe073vrrbk2avp41c1nu8ue1; security=low
[-]HTTP User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
[-]HTTP Referer: None
[-]Extra HTTP Headers: None
[-]X-Forwarded-For: None
[-]X-Client-IP: None
[-]Authentication Type: None
[-]Authentication Credentials: None
[-]Proxy: http://localhost:8080
[-]Timeout: 30
[-]Delaying: 0 seconds
[-]Delaying: 0 seconds
[-]Retries: 1 

===========================================================================
Target: http://localhost/vulnerabilities/xss_r/ --> 2018-11-05 21:52:39.403126
===========================================================================

---------------------------------------------
[-] Hashing: 07c95004cbc9dc31c5f2c44377b7f7e0
[+] Trying: http://localhost/vulnerabilities/xss_r/?name=
[+] Browser Support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]
[-] Headers Results:

Date: Mon, 05 Nov 2018 20:52:39 GMT
Server: Apache/2.4.25 (Debian)
Expires: Tue, 23 Jun 2009 12:00:00 GMT
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
X-XSS-Protection: 0
Vary: Accept-Encoding
Content-Length: 4338
Connection: close
http-code: 200
total-time: 0.020646
namelookup-time: 0.000289
connect-time: 0.000341
header-size: 312
request-size: 441
response-code: 200
ssl-verifyresult: 0
content-type: text/html;charset=utf-8
cookielist: []

---------------------------------------------
[-] Injection Results:
[+] Checking: url attack with "><SCRIPT>alert('PAYLOAD')</SCRIPT>... fail

Searching hash: 07c95004cbc9dc31c5f2c44377b7f7e0 in target source code...

Injection failed!

===========================================================================
Target: http://localhost/vulnerabilities/xss_r/ --> 2018-11-05 21:52:39.403126
===========================================================================

---------------------------------------------
[-] Hashing: 4900908507d3afc8a6e47f000b4ec65f
[+] Trying: http://localhost/vulnerabilities/xss_r/?name=
[+] Browser Support: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]
[-] Headers Results:

Date: Mon, 05 Nov 2018 20:52:39 GMT
Server: Apache/2.4.25 (Debian)
Expires: Tue, 23 Jun 2009 12:00:00 GMT
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
X-XSS-Protection: 0
Vary: Accept-Encoding
Content-Length: 4338
Connection: close
http-code: 200
total-time: 0.021497
namelookup-time: 0.000132
connect-time: 0.000199
header-size: 312
request-size: 441
response-code: 200
ssl-verifyresult: 0
content-type: text/html;charset=utf-8
cookielist: []

---------------------------------------------
[-] Injection Results:
[+] Checking: url attack with </TITLE>PAYLOAD... fail

Searching hash: 4900908507d3afc8a6e47f000b4ec65f in target source code...

Injection failed!

[...]

---------------------------------------------
[-] Injection Results:
[+] Checking: url attack with <form><button formaction=javascript&colon;PAYLOAD>X... fail

Searching hash: cd0744dd7e89b97d1f5234995c741aa7 in target source code...

Injection failed!

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

Mosquito(es) landed!

===========================================================================
[*] Final Results:
===========================================================================

- Injections: 558
- Failed: 558
- Successful: 0
- Accur: 0 %

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

[I] Could not find any vulnerability!. Try another combination or hack it -manually- :)

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

As you can see it didn't find the vulnerability because it never sent anything inside the GET parameter "name". Should it has found the vulnerability or what am I doing wrong?

[epsylon]

It is sending it, but the running output is showing you VECTOR and PAYLOAD separately, but at the end they are built (and sent) togheter. You can check it, for example, reviewing our requests are made at your Burp proxy. Did your tried to inject a valid payload manually on that webapp?. Did you tried "numerical" injections (..alert(1);..)?

[rhalyc]

I have used Burp as proxy and I have seen that VECTOR + PAYLOAD is not sent.

If you run xsser -u "http://localhost/vulnerabilities/xss_r/" -g "?name=" --cookie="PHPSESSID=rq8fvbrqv2pvr4ob622joj99s3; security=low" --proxy http://localhost:8080 --auto --no-head -v And you capture all the packets sent by XSSER (Burp is listenining at port 8080) you can see that the VECTOR + PAYLOAD is not sent:

The get requests is always: /vulnerabilities/xss_r/?name= So, as XSSER is not injecting any kind of string in the parameter it can not detect de XSS.

Answering your questions: Yes, I have tried to inject several payloads in the "name" parameter and the web is completely vulnerable to XSS (it does not use any kind of filtering)

So, what I am wondering now is:

• XSSER is a tool to detect XSS, right?
• As you can see XSSER is not sending any kind of VECTOR + PAYLOAD inside the "name" parameter, so it is not detecting the XSS, what could be wrong? Should it detect it? Can you tell me how to detect a XSS in the Dam Vulnerable Web Application (or in any other Vulnerable Web) using XSSER??

Thank you for your help

[epsylon]

I will try to check it. Maybe somethings gets wrong after latest commit but yes, you should be able to detect XSS vulnerabilities using this tool.

[epsylon]

Ok. I have found what's your mistake when spelling commands. You should specifiy wich parameters do you want to try by using some keywords: XSS, PAYLOAD, 1, etc.. For example, to inject automatically all provided vectors, you should try next command: xsser -u "http://localhost/vulnerabilities/xss_r/" -g "?name=XSS" --cookie="PHPSESSID=rq8fvbrqv2pvr4ob622joj99s3; security=low" --proxy http://localhost:8080 --auto --no-head -v Take a look to 'XSS' keyword used after parameters. This method is nice, because you can inject to any parameter provided (or not), just using it.

[epsylon]

Another example: xsser -u "http://localhost/vulnerabilities/xss_r/" -g "?name=XSS&surname=XSS&age=1&job=sysadmin" --cookie="PHPSESSID=rq8fvbrqv2pvr4ob622joj99s3; security=low" --proxy http://localhost:8080 --auto --no-head -v This will try to inject all provided vectors (~600) at parameters: 'name' and 'surname', only numerical vectors at parameter: 'age' and will not inject any parameter at 'job'. Etc..

[epsylon]

Maybe is a good idea for the next release to add a function than when a KEYWORD hasn't been added to the parameters, it is added by default with some "classics XSS" injection. You can check this, when not any parameter has been added to a command. For example (look that we aren't using '-g' parameter, this time): ./xsser -u "http://localhost/vulnerabilities/xss_r/search=" --cookie="PHPSESSID=rq8fvbrqv2pvr4ob622joj99s3; security=low" --proxy http://localhost:8080 --auto --no-head -v

[rhalyc]

Thank you for your help

[epsylon]

@rhalyc Thanks to you, for your report and patient on debugging tasks. I hope you have now a more better idea about what XSSer can do for you.