There are so many things to talk about these days, but I don't have the time to start writing long posts on each and every subject, so I've decided to dedicate yet another "periodic blurbs" post to them all.
- Anurag Agarwal started a (blessed) thread on browser security restrictions, in which he suggested a high level solution for vulnerabilities such as XSS and XSRF. After reading this thread, and following some of the links, I've discovered that there is an abundance of suggested solutions for browser insecurities, and it seems to me that a lot of people took a stab at what I believe would be the next evolution/revolution in web security. Now, all we have to do is start nagging to browser and server vendors, to join hands in the war against client-side attacks. If you are interested in "browser security revolution" - check out these links:
- Ivan Ristic (Mod Security) proposed what I think is the most holistic and promising solution for browser security. He even gave it a TLA, calling it SBM (Secure Browsing Mode). You can't beat that.
- Ivan's work references Gervase Markham's article called Content Restrictions - which I believe is probably the best solution around. This is a must-read article!
- While researching the subject, I stumbled upon a very interesting research paper called "Defending against Injection Attacks through Context-Sensitive String Evaluation". The paper was written by two IBM researchers (go IBM!), Tadeusz Pietraszek and Chris Vanden Berghe, The paper describes an approach for defending against injection attacks such as XSS, SQL Injections, Shell command injections, etc. by addressing the root cause of these attacks - ad-hoc serialization of user provided input. Definitely worth reading.
- PDP shares his own (pessimistic) thoughts on the subject of browser security. Here are a few quotes to wet your appetite:
So yes, we can setup a policy but it will never take off. First of all standardization bodies needs to except it. Then browsers have to implement it and we have a browser war going on at the moment. No developer will implement a standard that is not widely adopted.
IMHO we need to look at security personalization options within the browsers rather then inventing new standards that may crash and burn like they’ve done so far.
Let’s get back to the question about CSRF. You can’t stop CSRF. This is it! The technology does what it is supposed to do. I see how some policies can be used for good, for example in situations where attackers are after your router through some sort of CSRF attack, but again, I seriously doubt that something like what Anurag has proposed will ever work. For sure it will improve the situation security wise in certain areas but at the same time will make Web technologies rather inflexible which is something that developers hate. I don’t think that people like crossdomain.xml either, and this is the reason why most sites allow everyone to connect to their stuff, although they probably don’t know about the dangers of doing that.
- Several researchers from the IBM Tokyo research labs (Go IBM!), explain the security issues with today's browsers and propose their own solution for the problem in this very interesting presentation called "Security Model for the Client-Side Web Application Environments"
- I've seen a few cases lately, where people are becoming more and more aggressive about what they believe in. A friend from work claims that people in the software industry turn everything into a religion (e.g. Linux vs. Windows, Blackbox vs. Whitebox, Manual Pen Testing vs. Automated Scanning, etc.). When I started this blog, I promised myself that I will not get into personal fights with people, I will not slander, trash or badmouth anyone in the industry just because I don't share their thoughts - and believe me, this is hard, because I am a very enthusiastic person. Check out this latest soap opera (I tried to keep the actual time flow): "Detecting, Analyzing, and Exploiting Intranet Applications using JavaScript" >> "Timing attacks on web privacy" >> "Putting up, then shutting up" >> "RSnake Puts Up" >> "Drama".
- [Trash Alert] The soap opera mentioned above, reminded me that some people in this industry really don't have any class or style. You see, some players in the web application security market are finding it hard to sell their products by presenting their own products' virtues and benefits, so they use the tactics of leeching on to their competition (usually using FUD), and in some cases, I believe they cross the line. BTW, the same competitor that was mentioned above, actually uses the Watchfire & SPIDynamics logos on their own web site - how desperate can you get to actually incorporate your competitors' logo in your own ad?!?!
- While I am on the subject of "security wars", it seems to me that the web security market is so ripe (and hence, loaded emotionally), that people have completely lost their heads. Instead of joining hands and cooperating to educate the market, they prefer getting at each other's throats, over and over again. For crying out loud, we should all be saying the same thing -- Being secure is not about using whitebox or blackbox technologies, it's not about using a hosted service, or an application firewall, and it will certainly not come if you only use an automated scanner -- like anything else in the software world, security is all about perception, process, and methodology. If you want to secure your applications, make sure that you (and your development & QA teams) know what the actual problem is, that you have a process for eliminating security issues from the project inception phase, and up until the application goes GA (and even further). You have to implement a security process throughout your entire development lifecycle, using more than a single solution or product.
This industry needs to preach for a holistic approach to web application security, to encourage end users to use multiple solutions, tailored together for a complete solution instead of turning against its own members, in what oftentimes looks like a farce.
That's it for now.