JavaScript DOM XSS Injection validation

Is开发者_开发问答 this regular expression enough to catch all cross site scripting attempts when embedding HTML into the DOM. eg: Such as with document.write()

(javascript:|<\s*script.*?\s*>)

It is referenced in this document from modsecurity.com http://www.modsecurity.org/documentation/Ajax_Fingerprinting_and_Filtering_with_ModSecurity_2.0.pdf

Would it catch all <\sscript.?\s*> variants in UTF-8 for instance?

Unfortunately not. There are actually quite a few ways to sneak past that regex if an attacker is really trying. With modern browsers, that regex should do a pretty good job, but its not exhaustive. For example, something along the lines of this could open javascript without explicitly saying script or javascript

<img src="blah.jpg" alt="" onmousedown="alert('a')" />

Check out here (somewhat outdated but gets the point across) and here for more examples

Is this regular expression enough to catch all cross site scripting attempts

Hahahahahahahahahaha.

Sorry. But really... no, that's not even the tip of the iceberg.

Daniel has mentioned one other method of injecting script, but really there are hundreds. It is not at all possible to sanitise HTML using a simple regex. The only approach (and even then it's not trivial) is to properly parse the HTML, throwing out all malformed sequences and element/attribute names except for a few known-safe ones.

Of course this only applies when you are actually deliberately accepting HTML input and you want to limit its potential harm. If the situation is that you're accepting text but forgetting to escape it properly on the way out, you need to fix that HTML-escaping, because no amount of input-sniffing will fix an output-problem.

This is why mod_security is utterly bogus. It is giving you the illusion of improved security by catching a few of the most basic injection techniques, while letting everything else through to a vulnerable application. It won't, in the end, prevent you from being hacked, but the more injection signatures you add, the more it'll deny and mess up legitimate requests. For example it might prevent me from entering this message because it contains the string <script>.

The other respondents are right: there are many contexts through which injection may occur. Remember, the solution must consider both the many contexts in which an injection can occur. Blacklist (or "known bad") approach to filtration won't work because they fall prey to attacks that encode injections using unexpected character sets, creative use of whitespace, and other techniques. For more information, see OWASP DOM Based XSS. That page's Links educate on the 'problem' side.

As for the solution, consider the OWASP XSS DOM Prevention Cheat Sheet, which we just published. There are several tool kits referenced within the Cheat Sheet that help you implement escaping or encoding strategies. Probably MY FAVORITE approach to assuring that server-written client-side code is encoded and escaped appropriately is JXT. From its google code page:

<!-- Automatically escaped content -->
Hello ${user.getName()}!

<!-- Example tag with 3 different contextual encoding requirements -->
<img src="/profile-photo?user=${user.getId()}"
     alt="Photo of ${user.getName()}"
     onclick="openProfile('${user.getId()}')" />

<!-- Override the default escape, rare, but occasionally needed: -->
<jxt:out value="${user.getProfileHtml()}" escape="none"/>

Note that this includes auto-escaping for contexts but also a custom tag that allows for un-escaped output, in case special elements of your page/app would be broken by a cart blanch encoding regime.