Understanding Top Web 2.0 Security Attacks
Filed under: The Big Picture, Web 2.0 & Social Apps | Tags: ajax, cache poisoning, DOM, javascript, mashup, security, XSS |
One of the most eye-opening sessions of the conference so far has been this one on Web 2.0 security. The speaker, Danny Allan from Watchfire, an IBM company, was a fantastic speaker and one of the most engaging of the week. There are a lot of security risks in just about all rich internet applications on the web today, mostly due to the way the world wide web was built – there are all kinds of ways hackers can attack a web site to gain access to secure information. Why would they want to gain access to this information? Mostly, almost always, for financial gain.
He listed out 3 types of core attacks that may be used:
- Browser attacks: such as plugin flaws.
- Server side attacks: this is the more traditional attack such as SQL injection attacks.
- Client side attacks: Using XSS (cross-site scripting), CSRF, etc hackers can gain control over a users computer. There are 108 ways to exploit XSS attacks.
The main technologies that are attacked are:
- Browsers
- Ajax
- Web Services
It’s also worth noting that mashups are especially difficult to protect. There is the possibility that an attack in one widget could pull sensitive data from other widgets. Also it’s difficult to know when that happens because the DOM doesn’t recognize these sorts of attacks.
Other types of attacks mentioned are JS hijacking, prototype hijacking (hackers are able to basically replace your javascript function with their own), cache poisoning, DNS attacks, DNS Reminding attacks.
He then proceded to show us this demo of a XSS proxy which allowed him to gain control of a users’ bank information (not a real bank site) by pasting some malicious javascript code in the site search box and submitting it. Using the XSS proxy, he basically had a hacker admin panel that allowed him to view all kinds of data he ’stole’ from the user, including every link they clicked, every page viewed, all passwords and data typed in text fields, and basically anything sent through the browser you can think of. Since this was staged and just a demo, there are of course a lot of things that needed to be in place for this to work correctly but the point is, it’s possible. One of the things I thought was really interesting is that he actually leveraged CSS code (href tag styles) in his algorithm to gain access to this fake person’s data. Yikes!
I would be interested to find out more on the CSS leverage code. I would like to know what was used and if there’s anyway to prevent it from happening.
In his hacker application demo he had created (hardcoded) a list of specific pages within certain websites that he wanted to steal information from (for example, a recent transaction page in a banking site). His javascript function then basically did a comparison between that list and a list of sites the user actually visited which was generated by finding the RGB values of the hyperlinks (defined in the stylesheet as visited, normal) to somehow help gain access to the user’s browser. The problem is, this isn’t a fault of CSS – i think it’s a fault in the Document Object Model. The leverage of the CSS was just a small part of the attack… but very clever.
Somehow i missed the point. Probably lost in translation
Anyway … nice blog to visit.
cheers, Pamela!!