Tag Info

New answers tagged

3

Yes you should protect against Login CSRF. Without this protection an attacker can effectively reverse a CSRF attack. Rather than the victim being logged in to their own account and the attacker tries to ride the session by making requests to the site using the victim's cookies, they will be logging into the site under the attacker's credentials allowing the ...


0

If the CSRF vulnerable application allows itself to be embedded in an Iframe, then yes. How does it help the attacker? Iframes can be made invisible by setting size to zero. So as against the normal csrf where victim might get an idea of something suspicious, in case of invisible iframe, he won't see anything. The attacker will submit the form on victim's ...


1

Login? Yes. Logout? No. Why login? There is this funny CSRF login attack, where the attacker logs in the victim under aa attacker-controlled account, and then can "gain control over content created by the victim while logged in under that account". The impact is pretty lame IMO, but they started to see this as a problem now that more juicy attack vectors ...


0

That seems a right way to protect against CSRF attack. Although, you may want to generate a fresh token on each request and invalidate the previous used tokens.


2

From your question it is not clear if you are vulnerable or not. Is the token fixed or is it a cryptographically strong random generated token? if it is fixed it is of no value. Are you using SSL? if not your token can be sniffed and stolen - it is highly recommended that you use SSL. Note also that it is not recommended to pass the token in the url. URL's ...


2

No you are not vulnerable in that scenario. The reason is exactly as you explain - a third-party site could generate a request to your site, but the authentication details will not be attached.


-1

Answering my own question. Yes, I believe it is possible and safe to differentiate between browsers and non-browsers using the presence of cookies if and only if: The attacker cannot read cookie values (guaranteed by SOP) The cookie values are mandatory (preventing the attacker from making requests without them). I propose splitting the server-side ...


2

The reason is that this allows the main session cookie to be marked HttpOnly (so it won't be accessible to Javascript). There is some debate about how much value this adds, but HttpOnly seems to make some kinds of attacks harder so is arguably a useful hardening measure. If you didn't use a separate cookie, but just re-used the session ID for these ...


3

JavaScript cannot read the content of other sites due to the same-origin policy. This is one of the most fundamental principles of web security and goes way beyond CSRF protection. Without the same-origin policy, any website could read our e-mails through our webmailer, have a look at our PayPal account, get our private information from Facebook etc. So ...


1

CSRF is for forms mostly and it is not used for REST APIs at all. When REST API is implemented with API keys and nonce, you could say that these 2 act as your cross-site request forgery protection. Also, when designing REST API it's usually best to avoid such things as cookies at all. Use per-user API Keys, this will also solve your identification problems. ...


1

I'd like to propose a variant of the Encrypted Token Pattern which works as follows: When a client requests an HTML page needing CSRF protection... The server checks for the existence of a sessionId cookie. If it is missing, the server sets a new HttpOnly cookie containing a cryptographically-strong pseudorandom value. Note this value is not stored on the ...


0

http://stackoverflow.com/a/11423778/14731 makes a very important point: the Same Origin Policy (SOP) is concerned with preventing the reading of cross-domain responses, not with the writing of requests. Meaning, while you might be able to write custom headers in the future, it is extremely unlikely that you would ever be able to read the response of a ...


0

CSRF can happen anytime your server services POSTs† that don't originate from a form served by your server‡. Not using cookies for authorization doesn't mean CSRF can't happen. An embedded iframe can still POST to any guessable URL with guessable parameters. A custom user-agent can still send guessable headers. It is one time authentication through ...


0

Yes, they are submitted. See the W3C spec. HTTPOnly is intended to mitigate attacks like XSS, but if an attacker has an XSS in your site, they don't need a CSRF. Have you considered the Encrypted Token Pattern?


2

There are a couple of reasons I can think of: If the CSRF token is leaked, it doesn't leak the authentication cookie. It allows you to set the authentication token as HTTP-only and still have a CSRF value that can be read by JavaScript to build AJAX Requests Personally, I don't believe the double-submit cookies technique is very effective. While it's ...


2

Combining the best of both answers: The token length needs to be proportional to the number of victims and the number of requests per victim. If an attacker convinces X victims to navigate to his page (by way of spam or phishing attacks) and each such page attempts Y different tokens then you need to protect yourself against 2x*y attacks. For example, if ...


1

According to a paper published in Blackhat 2013, it isn't enough for you to implement Double-Submit Cookies in its own sub-domain (e.g. secure.host.com). You really must control all sub-domains: 2.1.1 Naïve Double Submit Double submit cookie CSRF mitigations are common and implementations can vary a lot. The solution is tempting because it’s ...



Top 50 recent answers are included