6

This is an example attack scenario of OWASP for CSRF

The application allows a user to submit a state changing request that does not include anything secret. For example:

http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243

So, the attacker constructs a request that will transfer money from the victim’s account to the attacker’s account, and then embeds this attack in an image request or iframe stored on various sites under the attacker’s control:

<img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#“ width="0" height="0" />

If the victim visits any of the attacker’s sites while already authenticated to example.com, these forged requests will automatically include the user’s session info, authorizing the attacker’s request.

I do not understand the last paragraph though. If I log into an account on example.com and then leave the webpage without log off, and now I visit the attacker's site, does this attack work? Or in order to work, it needs that I be on the site?

Adi
  • 44,095
  • 16
  • 138
  • 170

3 Answers3

9

When you log in to example.com, your browser stores a session token in a cookie. This session token uniquely identifies your logged-in session with example.com. Every time your browser makes any request to example.com, that request includes your example.com cookie data, including your unique session token.

With that in mind, consider the fact that a Web page can make your browser attempt to fetch any resource on the Web, e.g., through <img> or <iframe> tags. If a page includes a tag that asks your browser to fetch a page from example.com, the fetch will include your session info. The request is done in the context of your logged-in session (i.e., the fetch is being done as your logged-in example.com user account).

If the fetch of the example.com resource causes some action, then you (and the site) have fallen victim to a CSRF attack.

To answer your question directly: no, you do not need to have an example.com page open; you only need to have a valid example.com session token in your cookies.

apsillers
  • 5,820
  • 28
  • 33
4

The victim does not need to have that site open.

The victim has a cookie that authenticates him to example.com; when the victim's browser requests the URL in the img tag, it will send the example.com cookie in the header to the request.

In viewing this answer, your browser has made a request to wikimedia.org, regardless of whether you are separately browsing that site or not:

A Forge

It's the same principle at work in the OWASP example, but rather than an image, you're carrying out some (authenticated) action on example.org.

techraf
  • 9,159
  • 11
  • 45
  • 63
Michael
  • 2,138
  • 17
  • 26
0

If the cookie is a persistent cookie the target site doesn't need to be opened.

If the cookie is a session cookie the user has to authenticate with the target site once to create the cookie. Each time the user closes his browser the session cookie is lost.

In general the browser needs the cookie for the target site.

techraf
  • 9,159
  • 11
  • 45
  • 63
Rookian
  • 151
  • 5
  • This is really awkwardly put, session cookie can be persistent, why not? Did you mean in case the user session token is stored in HTML5 sessionStorage? – TildalWave Jan 09 '14 at 10:19
  • I mean that there are different kinds of cookies. A session-based cookie lives as long as the browser is not closed. A persistent cookie is still alive even though the user closed the browser. Therefore a session based cookie is more secure than a persistent cookie. – Rookian Jan 09 '14 at 11:34
  • No, a session cookie is valid for the duration of the user session, which might or mightn't be related to when the browser is closed (browser session), depending on where you're storing the session cookie, or use browser session specific server-side user token validation. You're confusing here user session with browser session, which aren't necessarily the same things. – TildalWave Jan 09 '14 at 11:42