I just stumbled upon a post by Lori MacVittie, Why it's so hard to secure JavaScript.
I found it interesting because it voices the (frustrated) opinion of an important Web Application Firewall vendor, F5, about something I've been reasoning for some years :)
She essentially admits scripting languages are such a mess to secure at the semantic level («Hey Giorgio, why doesn't NoScript just strip out malicious scripts and leave the rest my page alone?»), especially from an external node (like a firewall) which does not actually parse the code:

I am not aware of any security solution that currently parses out JavaScript before it's delivered to the client. If there are any out there, I'd love to hear about them.

Well, WebCleaner comes to mind.
Also NoScript's Anti-XSS filters actually parse cross-site request fragments through SpiderMonkey, mainly to reduce false positives by acting on syntactically valid JS only.

But she obviously means something different: a device placed outside the browser, parsing JavaScript and performing sandboxed behavioral analysis.
The latter is the true challenge here, but building such a toy might be not impossible, especially since the best JavaScript implementations out there, Mozilla's SpiderMonkey/TraceMonkey and Google's V8 are open-source and embeddable. However, performance penalties aside (most of the scripts should be parsed and possibly compiled and executed at least twice), you would loose a very important decision factor: browser context, i.e. DOM, cookies, authenticated sessions, navigation history and so on.
Unless they imagine to stuff a "twin" of your browser inside your firewall, sort of a proxy based on Gecko+SpiderMonkey or WebKit+V8 and acting as a guinea pig just before the "real" navigation happens...
But for the time being,

That's why browser add-ons like NoScript are so popular. JavaScript security today is binary: allow or deny. Period. There's no real in between. There is no JavaScript proxy that parses and rejects malicious script, no solution that proactively scans JavaScript for code-based exploits, no external answer to the problem. That means we have to rely on the browser developers to not only write a good browser with all the bells and whistles we like, but for security, as well.

8 Responses to “Firewall Makers vs Evil JavaScript”

  1. #1 Rob says:

    Hey, the F5 girl is hot!
    Is she Lori or a different model? :P

  2. #2 Giorgio says:

    @Rob:
    I can't tell for sure, but I tend to agree with your polite aesthetic judgment.

  3. #3 Doron says:

    Google has a project called Caja (http://code.google.com/p/google-caja/) that attempts to secure javascript in webpages by rewriting it and allowing you to configure what the JS can access.

  4. #4 Giorgio says:

    @Doron:
    Caja's scope is quite different, IMHO, trying to provide a sandboxed environment for web applications wanting to run user-generated JavaScript "safely".

  5. #5 Benjamin Otte says:

    Here's a program. if it inf-loops it's evil, if it doesn't it's fine. Now we just need to solve the halting problem and then we can secure JS!

  6. #6 Giorgio says:

    @Benjamin
    ROTFL, that's why I talked about sandboxed execution...

  7. #7 Mook says:

    But if you manage to execute the script with the browser context anyway, isn't that just like actually being in the browser? That is, you negate the security benefits by putting a different browser in front that can be exploited? Especially if it's using the same JS engine (spidermonkey / V8)...

  8. #8 Giorgio says:

    @Mook:
    You're obviously right: that's much challenging (as I said) because you should manage to sandbox and analyze the page behaviour, isolating exploits so that they do not bring down the firewall/proxy itself (kind of virtualization?)
    Also this would't add anything to protect from in-browser attacks such as XSS and CSRF, because (unless you add some technology which you could better deploy inside the browser itself, such as NoScript, Firekeeper, CSP or the upcoming ABE) they would be successfully carried by the proxy.
    My whole point (and the conclusion of the original article as I understood it) is that securing JavaScript at the semantic level is very impractical, if not impossible, and anyway a task for the browser, not for any other external device/software.

Bad Behavior has blocked 6298 access attempts in the last 7 days.