This attack exploits server's session management system vulnerabilities. It is based on the assumption that the mainly used mechanism to trace sessions is the use of cookies.

When you log in to a web application, this web application sets a cookie on your browser and knows that no one can access that cookie (via browser) due to the Same Origin Policy. Every time the browser make a request to that web site, it appends the cookie, so the user session is identified.

These session cookies are deleted after a period of time or when the browser is closed (or never if the web application is done very badly!). The time the cookies are not deleted is a vulnerability time if the server uses only the cookie attached to the request to identify the session.

An example: The site www.good.com provide a service to paying registered users. Roberto is a registered user and he is visiting www.good.com and in the same time he has a browser window on www.dummy.com. The latter site is done by the attacker, Antonio, to use the service of www.good.com without paying. www.dummy.com contains a script like:

This way, www.dummy.com makes a request to www.good.com and, because Roberto is already authenticated there, the www.good.com's cookie is attached to the request that starts from www.dummy.com. If Antonio knows well the service offered by www.good.com he can build up a request that modify Roberto's data or much more.

SOLUTION: the solution in this case is based on a modification of the server side application, in order to make the session authentication system based on added informations and not only on the cookie. Usually the same cookie is passed as an explicit argument to the web application. This is a good solution because the cookie value can be read only from the page that sets the cookie.

Moreover, a best practice is to accept request for web application only via HTTP POST. This because even if GET is faster, a POST request is not possible by a third party page, because violates the Same Origin Policy.