:: extra ::

We just released our report on the first (and to our knowledge the only) type of attack that specifically targets Ajax-style web applications. The attack is called JavaScript Hijacking. The report is here.

As part of the work, we took a look at 12 Ajax frameworks, including Google's GWT, Microsoft Atlas, Yahoo! UI, and a number of open source projects. A lot of the open source projects provide only client-side JavaScript libraries. In the report we point out that almost none of the frameworks protect against JavaScript Hijacking or give programmers any indication that there's anything they need to protect against themselves.

Thus-far, nobody has questioned us on the technical aspects of the attack, and quite a few of the framework maintainers have said they plan to address the problem. But we've taken some flak for our proposed solutions from a few owners of client-side JavaScript libraries. It boils down to one sentence in the report:

"Preventing JavaScript Hijacking requires a secure server-side implementation, but it is incumbent upon the client-side libraries to promote good security practices."

Some of the client-side guys aren't so happy with that. They say that security is totally a server-side problem. Keep in mind, most of these projects don't say a thing about writing a secure server in their documentation, and worse yet, some of them actually require the server to be vulnerable unless the application programmer wants to start monkeying around in the guts of the framework. Ugh.

Now that I'm done writing the report, I can ditch the any semblance of an even or balanced tone, so let me try saying it again. Here's the deal: if you're going to write some code that you expect programmers to re-use, and if that code walks people right into creating a security cesspool, you are doing the world a disservice. Don't be surprised when I tell the world to steer clear of your stuff.

Computerworld's published this piece on April 6th:
http://computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=security&articleId=9015588&taxonomyId=17

The article describes how hackers are now offering subscription services and support for their malware. Could this be the beginning of the next Internet bubble? The article describes:

"As organized gangs increasingly turn to cybercrime, sites like the one described are coming to represent the new face of malware development and distribution, according to security researchers. Unlike malicious code writers of the past who tended to distribute their code to a tight group of insiders or in underground newsgroups, the new breed is far more professional about how it hawks, plies and prices its wares..."

How much for the service? Just pay about $20 a month and get malware you can use to attack sites.

Black box testing is software testing. It's time for black box testing to start applying some of the same discipline used in the software testing world.

Most organizations admit they don't know how thorough their black box testing is, but most people assume their tests are comprehensive and effective. More than half of our survey participants believe their testing covered at least 60% of their applications, but the data suggest they're not doing as well as they think.

We looked at two of the leading black box tools as they probed five small web applications. Our data suggests that even for small applications, people using black box tools are not even getting 30% coverage. (Looking at larger apps generally makes the situation even worse.) Applying manual effort to customize the tools can significantly improve their effectiveness, but the tests still failed to achieve coverage numbers greater than 50%. Conclusion: black box tools aren't a good a substitute for good testing techniques.

In the past, people have used black box testing as a way to attract attention to the security problem. For that purpose, coverage doesn't matter: all you have to do is find some security holes. Software security is starting to mature a little bit, and now we need to start looking at whether or not our security testing is effective. We can borrow a lot from software testing. It's time for security testing to start growing up!