Slashdot Mirror

Oh, that Fortify? I'm talking about this one, which I assumed from the context of the question.

I am a security analyst by profession and education [not that it matters, but as a distinction of the previous poster's non-security background].

You are somewhat correct. Sloppy coding techniques do lead to security vulnerabilities which lead to exploit code which eventually lead to websites burning, etc. However, that is only one category of security flaws. If you look at, say the GDI flaws Microsoft had last year (for example), you'll notice that vulnerability is actually a design flaw-- allowing executable code to live embedded in file objects was the problem [the embedded code's trustworthiness had no mechanism to be measured and therefore any user double-clicking on a malicious code-within-an-image file would have their system compromised]. Design flaws are much more tricky to prevent and most experts attempting to solve this problem suggest that development houses should leave the design aspects of their code to people with a background in security principles, or at least have some sort of design-time security review. This is mostly what formalized threat modeling attempts to do.

But you are right ... there are vast categories of vulnerabilities that end up compiled in code unnecessarily. And a great place to start for anyone looking to weed these unforgiveable buffer overrun types of issues out of their code is to use a static analyzer on their code. Essentially, static analysis tools attempt to catch these obvious (or sometimes not so obvious) bugs before the code is shipped to customers. Fortify Software is a great place to look for such a tool.

You're likely referring to the JavaScript Hijacking paper from Fortify Software, the one which finds a loophole in a ridiculously contrived scenario that applies to roughly six sites on the planet. The threat they identify is real, but unlikely; it's orders of magnitude less severe than an XSS flaw or SQL-injection attack. Bob Ippolito demystifies the threat.

Nine times out of ten, a security exploit that uses JavaScript as the attack vector must be solved on the server-side, not in the JavaScript itself. This isn't buck-passing; it's just the truth. Nothing I can add to a JavaScript library will intercept a XSS attack, since the vulnerability (unsanitized HTML) lies on the server. Once the malicious JavaScript is on the page, the game is over.

That said: one of the suggested ways to protect yourself from this hijacking flaw is to surround the returned JSON with comment delimiters. Prototype 1.5.1, released on Tuesday, can handle this automatically.

(Disclosure: I'm a member of Prototype Core.)

Well, Fortify Software Security Research Group (which I am part of) has recently released a report ( http://it.slashdot.org/article.pl?sid=07/04/02/111 3242 ), where we discuss the new type of vulnerability we named JavaScript Hijacking.

We believe that JavaScript Hijacking is the only type of vulnerability found so far applicable only to Ajax applications. We've also analyzed 12 most widely used Ajax frameworks (DWR, GWT, Microsoft "Atlas", xajax, Prototype, Script.aculo.us, Dojo, Moo.fx, jQuery, Yahoo! UI, Rico, and MochiKit) and determined that all the frameworks that use JSON and/or JavaScript for transferring data (except for DWR 2.0 which was not released at the time) are vulnerable to JavaScript Hijacking.

To summarize, the vulnerability allows an unauthorized party to read confidential data contained in JavaScript messages. The attack works by using a tag to circumvent the Same Origin Policy enforced by Web browsers. Traditional Web applications are not vulnerable because they do not use JavaScript as a data transport mechanism.

Complete report is available here: http://www.fortifysoftware.com/servlet/downloads/p ublic/JavaScript_Hijacking.pdf .

As a side note, DWR 2.0 ( http://getahead.org/dwr/ ) and Prototype 1.5.1 ( http://prototypejs.org/2007/5/1/prototype-1-5-1-re leased ) have been recently released, and do contain fixes that prevent JavaScript Hijacking.

There hasn't been one proven exploit that has utilized Javascript.

It's simple to defend against. Don't be a wimp; read the original paper at http://www.fortifysoftware.com/servlet/downloads/p ublic/JavaScript_Hijacking.pdf, follow the advice, and all will be well. If nothing else, look at the Conclusion and Recommendations section at the end.

Just read the original advisory. TFA didn't link to it.

You're right, they're right. It's from March 12th, 2007 and it's a different issue than the one I mentioned before.
Putting the JSON data into comment tags or Google's while() approach sound like good defense mechanisms.
Also, using auth tokens in addition to cookies can defeat most scenarios as well (just ensure not to return a valid auth token in any replies that don't require a valid auth token already).

Here. For future reference:

1. Throw the words "Fortify Software" at Google.
2. Click on the first link.
3. Click on the prominent link in the middle of their home page.

It's really not that hard to find details. All you really need is the ability to operate a web browser, a search engine, and about thirty seconds of your time.

Where did you read this in the article? The article has no details.

Are we reading the same article? It lists vulnerable Ajax libraries. It uses GMail and webmail in general as examples of potentially vulnerable web applications. GMail and typical webmail applications aren't designed to be called from other domains in mashups.

Or do you have another source?

Here's the advisory (PDF). They override the Object() constructor before calling the JSON so they can capture the data without worrying about scope.

An application may be vulnerable if:

- It uses cookies to store session IDs or other forms of credentials; and
- It sends data from server to browser using "JSON" notation; and
- It doesn't require POST data in each request.

A vulnerable application can be fixed by changing any of these three aspects:

- Stop using cookies, and instead supply the credentials in the request's URL or POST data.
- Don't use JSON, or munge your JSON so that it can't be run directly from within a <script> tag; for example, you could put comments around it in the server and strip them off in your client.
- Have the client send some POST data and check for it on the server (a <script> tag can't send POST data).

My preference, and the strategy that I've used in Anyterm and Decimail Webmail, is to not use cookies. To me it actually seems easier to put the session ID in the request, rather than to mess around with cookies.

The advisory, which explains it all but is a bit waffly at the start, is at http://www.fortifysoftware.com/servlet/downloads/p ublic/JavaScript_Hijacking.pdf

All: I encourage all of you to read the detailed report Fortify wrote on this topic. Its written for developers and explains the problem in clear technical detail. http://www.fortifysoftware.com/advisory.jsp (No registration required) Its a long document but I doubt you'll have a lot of questions after reading it. Its refreshing to see reports written like this that don't insult a developer's intelligence.

http://www.fortifysoftware.com/products/sca/scaHow ItWorks.jsp
I think these guys compile an object that makes it easy to examine every possible logic path in the source.

It's more than just source code pattern matching.

Link to the project's homepage

http://opensource.fortifysoftware.com/welcome.html

"The downside is that you could also use that kind of search to look for things that are vulnerable and then guess who might have used that code snippet and then just fire away at it," says Mike Armistead, vice president of products with source-code analysis provider Fortify Software.

Check out http://www.fortifysoftware.com./ I don't work there (but I interviewed there) and haven't taken the time to compare valgrind with their software, but if this is possible and they aren't doing this now, I would imagine this is something they would do.

It turns out there's a fair number of things you can do to screw up security, even in Java. Think SQL injection and cross-site scripting. Check out http://vulncat.fortifysoftware.com/ for a longish list of code-level defects that can cause security problems.

Static analysis has a lot more to offer than looking at the names of methods and variables. FindBugs ( http://findbugs.sourceforge.net/ ) is an excellent open-source tool for finding common problems in Java, though it's focus is much more on code quality rather than security.

Full disclosure: I'm one of the founders of Fortify.

Brian