How to protect from new Javascript Injection technique that doesn't use eval()?

Question

There is a new Javascript injection technique that is generating chatter on the forums mentioned here

Here is the code sample:

String.prototype.code = function(){ return (new Function('with(this) { return ' + this + '}' )).call({}); };
var s = 'alert("hello!");'
s.code();

What infrastructure components need to be updated (if any) to monitor and protect from this class of exploit?

For example:

I'm under the impression that some DBA's scan their databases for evidence of a injection attack... this is almost a last-stand approach for mitigating a poorly written application in a distributed enterprise.

When I last worked with Microsoft on a JS Injection attack, the developer in India didn't properly verify form input. This caused our client's database to be littered with Javascript code that executed on the client. Microsoft's response was to search the database for pre-defined strings that are commonly used in attacks.

I'm assuming that there are products or sensors that monitor SQL or HTTP traffic for obvious js-malware. If I take my assumption a step further, those devices need to have the signature updated for this vector.

Answer 1

Its all XSS, its not proper to call it "JavaScript Injection". The XSS vector you are talking about isn't new, and its an interesting one. XSS is an output problem. If you perform the same input validation on all input you'll still have problems with XSS. If you encode or strip all < > characters for every input variable you'll still have huge problems with xss. This is because XSS is highly dependent on where the variable is being printed to the page.

This line of code is safe:

var x='alert(123)'

However, it can be exploitable if the attacker has access to single quotes ' . For instance if the attacker had a request like ?x=';alert(123);, then he would be able to break out of the quote marks and execute javascript. The solution is to encode all quote marks as well. In php you can use htmlspecialchars($var,ENT_QUTOES);

But here is the real kicker, even this function can't stop all XSS. It will stop about ~90% of xss. But even after a htmlspecialchars($var,ENT_QUTOES); you can still run into problems with DOM based xss and XSS via event handlers.

So whats the real solution? Test your code! Use a free vulnerability scanning service like Sitewatch or an open source tool like Wapiti. These tools know all of the strange rules for XSS, and it will be able to find these violations in your application. Google uses Sitewatch.

Answer 2

I'm not sure I understand what is so different about this technique than the general type of injection cross site scripting.

If this has gone so far and you happen to allow arbitrary JavaScript code to be injected and executed on your site, you're asking for trouble either way, no matter the technique. Try checking your site for most common XSS vulnerabilities.

I'm sorry if I'm missing something here, please correct me if I didn't get the big picture here (as I feel that way).