Scanners are scanners

When scanning the XSS-Game site http://xss.progphp.com/ with various XSS scanners, I found most scanners are similiar in missing XSS in the following pages. Apparently, no scanners can detect all XSSes. Scanners are limited to their developers' skills and experience in security testing.

This post might be of help to scanner developers to improve their scan engines or let them alone for the human analysis part.

1. http://xss.progphp.com/xss12.html

solution: javascript:alert(/XSS/)

Some real-world applications parse our GET/POST requests and put them

in the links. It's likely that Scanner XYZ thinks javascript:alert(/XSS/) which is not its own submitted payload.

2.  http://xss.progphp.com/xss11.html

solution:

http://xss.progphp.com/xss11.html?bar=%2522%253E%27%253E%253Cscript%2520%253Ealert%28/XSS/%29%253B%253C%252Fscript%2520%253E%250A

This is a double-encoding XSS but it's likely that Scanner XYZ

focused only on non-vulnerable parameter 'foo' and missed vulnerable

parameter 'secret'. I know from experience Scanner XYZ can detect

double-encoding XSS.

3. http://xss.progphp.com/xss8.html

solution: http://xss.progphp.com/xss8.html?input=%22%3E%3CscripT%3Ealert%280%29%3C/scripT%3E

This one might be trickier for scanner. But Scanner XYZ can be made to think

like 'human' when it sees generic error messages.

Notice: Undefined index: input in /var/www/xss/xss8.html on line 7

Or at least, Scanner XYZ can report 'generic' application error messages. I

think application error message detection is not currently available

in Scanner XYZ.

4.  http://xss.progphp.com/xss6.html

solution: x-forwarded-for: "><script>alert(0)</script>

This shows that Scanner XYZ is likely to fuzz possible http headers that are

returned only from  the server. Scanner XYZ forgot to fuzz arbitrary headers

that are potentially processed by servers.

5. http://xss.progphp.com/xss5.html

solution: back=javascript:alert(0)

This is a common XSS-able scenario in today's web applications.

Whenever users have done something, they're redirected to the location

that may be history - 1 or arbitrary location put in hidden input tag.

Scanner XYZ can easily be made to check if  the redirection header 301/302

location points to XSS-able uri (javascript:, data:) or any arbitrary

uri (jar: , mailto:, ftp:...etc).  Scanner XYZ can also report this as open

redirection.

6. http://xss.progphp.com/xss4.html

solution:

Referer: http://www.google.com

Referer: javascript:alert(0)

This shows that Scanner XYZ is likely to fuzz http headers that are returned

only from the server.

I wish Scanner XYZ consider generic hidden parameters like Referer,

X-Forwarded-For in finding flaws.

7. http://xss.progphp.com/xss13.html

solution:

http://xss.progphp.com/xss13.html?foo=JzthbGVydCgwKS8vXCc7YWxlcnQoMSkvLyI7YWxlcnQoMikvL1wiO2FsZXJ0KDMpLy8tLT48c2NyaXB0PmE9YWxlcnQ7YSgvWFNTLyk8L1NDUklQVD4iPic+PFNDUklQVD5hbGVydCg0KTwvU0NSSVBUPj0me30iKTt9YWxlcnQoNik7ZnVuY3Rpb24geHNzKCl7Ly8=

- Base64-encoded XSS.  It would be better if this check is added to

Scanner XYZScanner.