Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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:

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="“ width="0" height="0" />

If the victim visits any of the attacker’s sites while already authenticated to, 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 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?

share|improve this question
up vote 8 down vote accepted

When you log in to, your browser stores a session token in a cookie. This session token uniquely identifies your logged-in session with Every time your browser makes any request to, that request includes your 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, 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 user account).

If the fetch of the 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 page open; you only need to have a valid session token in your cookies.

share|improve this answer

The victim does not need to have that site open.

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

In viewing this answer, your browser has made a request to, 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

share|improve this answer

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.

share|improve this answer
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 9 '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 9 '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 9 '14 at 11:42

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.