Examples of XSS that I can use to test my page input?

Question

I have had issues with XSS. Specifically I had an individual inject JS alert showing that the my input had vulnerabilities. I have done research on XSS and found examples but for some reason I can't get them to work.

Can I get example(s) of XSS that I can throw into my input and when I output it back to the user see some sort of change like an alert to know it's vulnerable?

I'm using PHP and I am going to implement htmlspecialchars() but I first am trying to reproduce these vulnerabilities.

Thanks!

Solution 1

You can use this firefox addon:

• XSS Me

XSS-Me is the Exploit-Me tool used to test for reflected Cross-Site Scripting (XSS). It does NOT currently test for stored XSS.

The tool works by submitting your HTML forms and substituting the form value with strings that are representative of an XSS attack. If the resulting HTML page sets a specific JavaScript value (document.vulnerable=true) then the tool marks the page as vulnerable to the given XSS string. The tool does not attempting to compromise the security of the given system. It looks for possible entry points for an attack against the system. There is no port scanning, packet sniffing, password hacking or firewall attacks done by the tool.

You can think of the work done by the tool as the same as the QA testers for the site manually entering all of these strings into the form fields.

Solution 2

For example:

<script>alert("XSS")</script>
"><b>Bold</b>
'><u>Underlined</u>

Solution 3

It is very good to use some of the automated tools, however you won't gain any insight or experience from those.

The point of XSS attack is to execute javascript in a browser window, which is not supplied by the site. So first you must have a look in what context the user supplied data is printed on the website; it might be within <script></script> code block, it might be within <style></style> block, it might be used as an attribute of an element <input type="text" value="USER DATA" /> or for instance in a <textarea>. Depending on that you will see what syntax you will use to escape the context (or use it); for instance if you are within <script> tags, it might be sufficient to close parethesis of a function and end the line with semicolon, so the final injection will look like ); alert(555);. If the data supplied is used as an html attribute, the injection might look like " onclick="alert(1)" which will cause js execution if you click on the element (this area is rich to play with especially with html5). The point is, the context of the xss is as much important as any filtering/sanatizing functions that might be in place, and often there might be small nuances which the automated tool will not catch. As you can see above even without quotes and html tags, in a limited number of circumstance you might be able to bypass the filters and execute js.

There also needs to be considered the browser encoding, for instance you might be able to bypass filters if the target browser has utf7 encoding (and you encode your injection that way). Filter evasion is a whole another story, however the current PHP functions are pretty bulletproof, if used correctly.

Also here is a long enough list of XSS vectors

As a last thing, here is an actual example of a XSS string that was found on a site, and I guarantee you that not a single scanner would've found that (there were various filters and word blacklists, the page allowed to insert basic html formatting to customize your profile page):

<a href="Boom"><font color=a"onmouseover=alert(document.cookie);"> XSS-Try ME</span></font>

Solution 4

Ad-hoc testing is OK, however I also recommend trying a web application vulnerability scanning tool to ensure you haven't missed anything.

acunetix is pretty good and has a free trial of their application:

http://www.acunetix.com/websitesecurity/xss.htm

(Note I have no affiliation with this company, however I have used the product to test my own applications).

View more solutions

Comments

[Tomalak]

Code injection vulnerabilities such as XSS or SQL injection are always a result of improper use or lack of data escaping. In PHP you must use htmlspecialchars() on everything you output to the page that is not intended to be markup. To save some typing you could use a wrapper function h($s) { return htmlspecialchars(s); } and use h() everywhere.

[Mike]

What is the point of testing for XSS vulnerabilities before you implement htmlspecialchars() (or htmlentities())?

[Tomalak]

Also, always think of the "code level" you are in: For example: When writing user-generated data to an HTML comment, you don't really have to htmlspecialchars() it, but you must remember to remove any occurrence of --> from that data or you have a possible XSS vulnerability right there.

[KRB]

@Mike Good point, although, I am curious because I had implemented striptags() with other tests and this was still happening. Not to mention if I don't reproduce a vulnerability before I implement htmlspecialchars() then I won't "feel" like it is going to work. Mostly for curiosity & learning though. :D

[KRB]

@Tomalak Thanks for the great tips! Do you know if there is any point of using striptags() and htmlspecialchars()? (should I make a new question for this?) THANKS!!!

[Tomalak]

@KRB: strip_tags() is not specifically an anti-XSS function. If you mix data and code (yes, that's basically what you do: in HTML "code" is the markup, "data" is everything else, like text or attribute values; in JavaScript "data" is string literals, etc) you must escape data accordingly. So there is no way around htmlspecialchars() in PHP/HTML, and strip_tags() can only assist.

[Cheekysoft]

every single function discussed here, if used alone, is vulnerable to XSS. There is no magic bullet, you need to encode in an injection-context-dependent manner. Please read owasp.org/index.php/… That explains about 6 different architectural areas in a HTML document. Each of which need different behaviour

[Dave Lasley]

This tool is amazing, I highly recommend! Screw reinventing the wheel

[KRB]

It's not supported with version 5.0. Has anyone used it on 5.0 with success?

[Cheekysoft]

Unfortunately, cross-site scripting is one thing that automated scanners are truly terrible at finding. They miss a majority of vulnerable setups in the wild and only fire on the most simple wide-open code.

[TommyAutoMagically]

You could improve this answer by including a simple example (like the answer by ComFreek) and then diving in to the merits of XSS Me.