Just to stress on the real dangers of AJAX APIs in a harmless way, I designed a simple application that wraps around Johnny’s Google Hacking Database. You can learn more about it from here. Now imagine that something similar is implemented into a Worm… that could potentially bring a lot of problems. Of course, I am working on counter attack scenarios so let’s see what the future holds for us.

We also polymorph too, but thats a long story…

Keep up the good work!

Yahoo pipes experience some problems these days. It works now! The service was down when I was presenting my topic… that was so unlucky…

ntp,

very good thoughts, but I don’t see them happening. As I always mention, security and accessibility should be balanced. This means that you cannot go for only secure technologies because you will loose their easiness of use. IPv6, VPNs, SSL have their problems on their own. Nothing will change. Attackers will move from one type of attack vector to another. The sooner we understand that, the better. Security is not a destination, it is a process. I believe tat big organizations/corporations already understand that. They are not trying to fix all vulnerabilities in their systems but to mitigate the overall risk and come up with a strategy that can tackle the problem when it occurs.

Elio,

NoScript is OK extension but it does not solve anything. First of all, it is hard to use. The overage user will never use. Come on! Nobody likes being asked very time something happens. Moreover, AJAX the main way to develop applications on line. If we want to turn off JavaScript to protect against AJAX worms and viruses then we may as well block kernel32.dll to protect against desktop worms and viruses. The end result will be none-usable system. Consumers don’t like that! There must be other solutions! More creative solutions, that are ready to be discovered and implemented.

What can we do about it?

As web developers, reconsidering the mindless way we’re sharing content, we’re binding resources to random domains and we’re handling data turning it into code with no clue of what and where we’re running.

As web users, a conscious adoption of the NoScript Firefox extension ( http://noscript.net ) may be a start point…

Alternatively (or not), we can jump the fence and run for the easy money :)

we can’t just uplift our entire web infrastructure to signed scripts (although this might be a good idea). httpOnly isn’t going to prevent this sort of thing and has problems of its own. safer methods such as content-restrictions may be worthwhile to look at.

i think microsoft and firefox developers will fix xss at the browser-level this year, possibly after a devastating attack or two like the ones you describe. this would prevent future xss super worms.

as for the jikto on steroids – this has been an attack channel that has been waiting to happen for years. my suggestion is to learn how to get off firewalls as soon as possible. alongside your existing infrastructure, build an ipv6 network with systems and applications that are resilient to both the 12-year patch syndrome and the zero-day. this means all-new applications using developers certified in secure programming, that use secure frameworks, and that use threat-modeling and SCA tools that also combine fuzz testing before deployment. when you use third-party applications, make sure they complete a rigid software contract, get their reports/analysis on their secure software practices, and validate through external testing before any integration of their product.

until we get to the secure software paradise described above, i figure we’ll need to learn a lot about incident response and dealing with threats over vulnerabilities. consider a quick retirement of all legacy applications. firewall/IPS appliances and anti-virus software is not going to help us – so stop buying them. they may have bought us time, but that time is clearly now over with and done.