Understanding HTTP And CSRF.

I've talked about CSRF before, but this time I wanted to show some of the underlying basics of it and explain why it isn't a new trick or something special. It is part of browsers and the way HTTP works, also to remove any argument that POST should be safer then GET. I know this is Internet basics, it still can be refreshing to read it over from time to time.HTTP is the core of all we talk about and use basically all day. Without it we could not hack the web application layer like we know. HTTP is a transportation protocol that allows use to connect to a webserver with the URI and makes it all possible. There is some history and misunderstanding about it. Back in the days that cookies where implemented people where very affraid about it's implications on privacy. Today you never hear any bad word about cookies, they are accepted. Still, they link up threats as in CSRF and could facilitate them.State management mechanisms for HTTP.HTTP requests are stateless. This means that no webserver can make up the difference between you and me if we connect to the server. In contrary with the use of cookies which allow the webserver to know who we are. Part of HTTP is the Uniform Resource Identifier (URI)Syntax:URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty The following are two example URIs and their component parts: foo://example.com:8042/over/there?name=ferret#nose _/ ______________/_________/ _________/ __/ | | | | | scheme authority path query fragment | _____________________|__ / / urn:example:animal:ferret:noseThe problem with CSRF is that the URI can perform an unverifiable transaction as we call it. This means that when you visit a website A, website A could make a completely legitimate image link to website B and include it to show it on website A. This is a feature of HTTP and browsers which allow this unverifiable transaction to happen. So, CSRF is standard behavior in browsers and we see it daily without concern. It gets problematic if the requests that are being made are somewhat hostile. An example to illustrate this:Website A:GET http://gmail.com/?logout=true HTTP/1.1So website A is requesting another HTTP instance from gmail through the browser itself, and thereby it is a legitimate request. If Gmail is vulnerable to CSRF it will happily answer the request because the request was made by the users browser itself. It only works to logout a user if he has an account, is logged in and uses a state management system, like cookies of course. While login users out isn't that big of an issue, these thing could get more dangerous when we consider the following inside a couple of hidden iframes or images:GET http://someblog.com/?spam=hello%20I%20csrf! HTTP/1.1GET http://someblog.com/?spam=hello%20I%20csrf! HTTP/1.1GET http://someblog.com/?spam=hello%20I%20csrf! HTTP/1.1GET http://someblog.com/?spam=hello%20I%20csrf! HTTP/1.1GET http://someblog.com/?spam=hello%20I%20csrf! HTTP/1.1....50 times.Which opens 50 instances of requests to someblog.com and tries to insert a spam comment. Now, this only works in this setting when the site owner allows GET to be used to insert a comment. GET http://shop.com/?cart=TVset HTTP/1.1GET http://shop.com/?cart=Hummer&amount=10 HTTP/1.1GET http://shop.com/?cart=Diamond_Ring HTTP/1.1Pay:GET http://shop.com/?checkout=yes HTTP/1.1Now we bought a TV set, 10 Hummers and a diamond ring for the girl. And we also checkout in the third request confirming the transaction. This would be devastating because you would never notice this happened. And could bring lots of trouble. Luckily a lot of shops know about these issues and protected them selfs, but not all shops did. Likewise Amazon was/is vulnerable to this kind of attack. POST or GET both are vulnerable.Usually the programmer uses $_GET['param'] or $_REQUEST['param']. So with it, it becomes possible to spam him with CSRF alone or buy products. The problem is even bigger because POST, or an actual submitted request could be exploited as well with hidden layers, Javascript anything that could trick the browser to post a form could be exploited this way. It does the same thing: Making an unverifiable transaction.A word from the RFC3986:A URI does not in itself pose a security threat. However, as URI's are often used to provide a compact set of instructions for access to network resources, care must be taken to properly interpret the data within a URI, to prevent that data from causing unintended access.