Tag Info

New answers tagged

2

The reason that sites are able to impersonate users performing actions is because browsers will willingly submit a HTML <form> to any other domain specified using the action attribute without concern the origins being the same or any other restrictions provided by the target domain. The original domain has no way to read what was received by the user ...


2

Without the token check, the attacker wouldn't even need to inject javascript. For example, they create a form on https://evil.example/ that submits to an action at https://target.example/. Instead of injecting javascript on the target site, they can just place it directly on the site they control and trick you to visit that. The POST request will still ...


2

I'm not an expert on CSRF (please comment if I have misconceptions), but from wikipedia: Under the [same-origin policy], a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. An origin is defined as a combination of URI scheme, hostname, and port number. A ...


5

If the attacker is good enough to make me submit a form (as mentioned by OWASP) what would prevent him from getting the token before submitting? The only skill an attacker needs to have is the ability to write HTML and javascript and know what the request they are trying to attack looks like. These are all things that are easily accessible and are ...


0

CSRF Protection on Logout is a must ! Why? Assume the following scenario: You're on a trading page and prepare a buying order for e.g. 1000 Daimlers on an Exchange XETRA. Until you are preparing the order, somebody, who knows that you are logged on https://anybrokerpage.com/ , sends a phishing link to you. e.g. https://anybrokerpage.com/logout By ...


1

"Is the Origin not there? If not, OK. If it is, is it one one I trust (e.g. the same origin)? If so, OK." Although you can use the Origin header to reject a request. If the Origin header is missing, you cannot safely accept it, even for POST requests. As far as I know, an HTML form request doesn't include an Origin header, and neither do imgs, ...


17

What stops a malicious site from obtaining the anti-CSRF token is the Same Origin Policy. The Same Origin Policy, or SOP, is at the browser level, and defines where JavaScript is allowed to communicate. JavaScript on example.com cannot call example.org to get data. Also, JavaScript on http://www.example.com/ cannot call http://www.example.com:8080/ as the ...


0

It isn't very known fact, but normal string comparison is vulnerable to timing attacks (such as this one. Long story short, normal string comparison operations (== or ===) will compare two strings character-by character from left to right and return false once they've encountered any character that's not equal at a given position in both strings. This gives ...


-1

If the same token is used for the entire session then then there is probability of attacker can hijack the token using XSS and use the victim's session to do some malicious activities like changing the password . They can cange passwords by lodaing an iframe into the site you are using. So it is better to use one token per request to avoid the attacker to ...


0

I don't see any flaw in the method and I think it can be used to protect against CSRF. There is just one small issue: This method will work just fine as long as the cookie storing the CSRF token is NOT set as HTTPOnly. The problem is with this requirement: Application detects/places token. This implementation is similar to Double Submit Cookies. Double ...


-2

No, it's not. A cookie is sent by browser for every request. If the user or the attacker submits the form, the cookie will be sent with the cookie. If the attacker sends the cookie, the user loses. I would employ a hidden form field with a token that is synchronized once for session: User starts session. There are no token yet. Generate a secure token, ...


0

Given that the page is before login and is low risk I have taken the advice of @sliverlighFox and removed the CSRF from the form which resolves the issue.



Top 50 recent answers are included