Seba

I suppose you already know of the dangers of malicious Javascript and Cross-Site-Scripting (XSS), otherwise you wouldn’t read OWASP blogs, would you :-).

What worries me are the next stages. Recently XSS was the attack vector discovered in Google’s popular Desktop Search. One of the tools referenced in the research paper is the XSS proxy tool. This reminded me of the post by PDP on persistent XSS, stating “Persistent XSS is more dangerous since it allow attackers to control exploited clients for longer”.

The idea is that you can infect the victim browser with XSS that ‘phones home’ and stays persistent in the victim’s browser. You can expect XSS-based bot nets, analogous to their classic Trojan nephews.

Another result of this kind of infection, is that it only takes one XSS vulnerability within a popular web site to infect clients for a longer period of time. Even when the XSS is fixed on the web application, browsers can stay infected for longer periods of time. Sounds a lot like the Domain Contamination by Amit Klein, but then client side!

We should not think that there is no profit to make with JS Badware, this excellent paper on “Man in the Browser” attacks by Philipp Gühring shows what can be done with infected browsers. You can expect XSS-based attack kits targeting web-banking customers really soon! People do make money with attack kits, as RSA showed recently.

The different stories above sketch a grim picture of where the following battlefields of malware will be: your browser! I am curious on how the Anti-Virus companies will provide protection against these new threats. Self-modifying JavaScript (tool kits) will be coming to a browser near you soon!

This is all related to the return of the ‘fat’ client. Your client connection to online web applications is getting incredibly complex. See Ajax, see support for off-line functionality in the upcoming Firefox3, see Adobe’s FLEX and Appolo developments.

Interesting times are ahead of us …

This interesting blog posting strengthent my conviction that we have too narrow-minded a view on the developers that create (web) applications.

If we want improve the development processes from a security standpoint it is critical that we first identify the ‘actual’ development process that is going on. This is most often not the view that e.g. Project Management Office has on the development efforts.

In the cases where the development proces is driven by “geeks” we have to concentrate our efforts on educating these geeks. This will have a higher pay-off than trying to improve the processes, as these processes will probably only exist on paper.

The security community has to stop thinking that development is still performed with the classical waterfall model. Nowadays a lot of development is done “agile” with XP driven development cycles.