What is it?
It is another buzzword for something that isn't quite what it really is. I read this new post by Watchfire[1]. And it is basically a way gaining unauthorized access through a tricked same origin request, or simply put: CSRF. Like many, I wrote many articles about this and the danger of running servers or services on your localhost c.q. intranet to perform remote SQL injection or XSS through a CSRF'd GET request. Nothing new, because it doesn't violate the same origin policy in a browser because the victim is doing the attack himself and therefore still violated the same origin policy. Confused already? You should, but you do not have to invent new buzzwords for techniques that are already known and utilized for years.
I wrote before that a browser should not request content beyond it's current server supplied origin. This means everything, images, iframes, frames, stylesheets and javascripts. Because that makes it possible in the first place. CSRF strictly seen violates the same origin policy through a different route than we are used to. Instead of gaining attacker access, we trick the browser or the victim to do it for us. This means that we can violate the same origin policy completely and it also means that blacklisting some services from violating the same origin policy is as flawed as whitelisting a few features who can. To me, a strict same origin policy should block all content that is fetched from non-same origins.
As I show in figure 1, CSRF can violate the same origin policy, by letting the client make a second request locally. Depending on the situation, the second local POST/GET request can be made through HTML objects, forms, server-side or Javascript redirects.
Watchfire also talks about Cross Application Scripting (XAS) Which is another useless buzzword that invokes confusion. Again, it's the same as CSRF that is the vehicle for Javascript (XSS) and could be the vehicle for SQL injection, or remote file inclusion or remote code execution for that matter.
Even their recommendations are somewhat off-beat. In my opinion it is solely up to browser vendors to restrict all access to local services. Make a distinction between local and remote and you can solve these issues. Again, a browser is a client that may only request a server who serves up webpages, not the other way around. This implicitly means that a browser should only browse remotely and not locally. In the case of Internet Explorer their biggest mistake was to integrate explorer into the Windows shell, we have to get rid of the ancient idea that a client should have access to the machine it works on, and make a clear distinction between a client and a server. Until then we will be facing more and more security issues relating local exploitation.
The current state of browsers is that they act as a client as well as a server, which makes all of this possible.
[1] http://blog.watchfire.com/wfblog/2008/06/cross-environ-1.html
