Tag Info

New answers tagged

1

So BREACH is an attack specifically against response bodies, not headers. Since cookies are sent as headers, they aren't susceptible to the technique described by BREACH, but have been vulnerable to other compression side-channel attacks such as CRIME. What they mean by: (2) Reflect user-input in HTTP response bodies, AND (3) Reflect a secret (such ...


0

chrismsnz here... Long story short, DarkLighting is pretty much right. Input::get() usually reads from request parameters, but if the request is JSON then it reads from the JSON body. JSON allows you to specify the type of data so instead of a CSRF token string, I sent an int(0) which will pass that loose comparison most of the time. The other trick is ...


0

You seem confused the concepts of Same Origin Policy, CSRF, and what can be done with HTML forms; and you aren't alone! The Web a complex mix of many technologies developed without sufficient security evaluation, with subtly different policies. An interactive website can provide different content to different users, using tokens sent by the browser and ...


3

You seem to misunderstand both the same-origin policy and CSRF. The same-origin policy is crucial for any kind of browser security. It makes sure that client-side scripts from one website cannot access information from another site. Without this, we'd have much bigger problems than CSRF: Any website could read our e-mails with our webmail account (while ...


0

This is the problem you are trying to prevent by validating the token: As a simplified example, imagine there are two apps: (1) FileStore, a legitimate file storage app, and (2) EvilApp. Both apps use Google's authentication process for client-side apps. Alice is an innocent end user, and her Google user ID is XYZ. Alice signs into ...


1

Generally speaking, no. CSRF protection and session authentication are typically supposed to be separate concepts entirely. The responsibility of a CSRF token is supposed to be a one-time key for a request - nothing more, while a session ID or session token is supposed to merely identify a user that has permission to perform the action in the first place. ...


1

An interesting one. If the CSRF token identifies the user as well, then I can't see it being a vulnerability in itself. Some systems can work without cookies (although you mention this one is designed to work with cookies) and can pass around an auth token in a hidden form field that is used as both a session identifier and an anti-CSRF token. In your case, ...


1

I think that the way to solve it is to use Anti-CSRF Tokens and not to relay on referrer header. There are different implementations that can give Anti-CSRF Tokens out of the box, so you don't have to write it yourself. http://www.asp.net/web-api/overview/security/preventing-cross-site-request-forgery-(csrf)-attacks ...


4

According to OWASP: Although it is trivial to spoof the referer header on your own browser, it is impossible to do so in a CSRF attack. Checking the referer is a commonly used method of preventing CSRF on embedded network devices because it does not require a per-user state. This makes a referer a useful method of CSRF prevention when memory is scarce. ...



Top 50 recent answers are included