Tag Info

New answers tagged

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.


1

I see no problem with this. It is effectively the same as resetting the token when the user reloads the page. Assuming that you are using https and properly implement the ajax request and token generation, an attacker should still not know what the user token is. The same risks apply as do when normally generating a CSRF token without ajax, because to the ...


1

You don't need to set an independent expiry time for the CSRF token, the token needs to be unique and valid for the current user session, when the user session will expire the csrf token expires along with the session, and then you must generate a new token. This could be a simple solution.


0

In what scenarios would bin2hex be vulnerable to a timing attack? The timing attack discussed in the mailing list and blog post is a cache-timing attack, which was famously demonstrated by Daniel J. Bernstein against OpenSSL's implementation of AES here (PDF). In order for bin2hex() to be vulnerable to a timing attack, the following conditions must be met: ...


0

Related: CSRF protection for unauthenticated requests, actions, searches or comments?. This question is not a duplicate as you are asking how to test for it. In just the same way you would test for normal CSRF. Instigate a request to the server that would simulate the request arriving cross-domain. That is: Origin and referer headers appropriately set. ...


1

A CSRF attack can only happen when cookies (or other authentication mechanisms) are provided by the client automatically. That is, where the client has access to cookies from multiple domains (such as a web browser storing cookies for each site you visit). However, a mobile app containing a web viewer will typically only have the cookies for its own system. ...


3

The scenario you described, wherein, the login form doesn't not include a CSRF token may give rise to the situation where an attacker uses his own credentials to log the victim into the attacker's account and if the user is oblivious to which account he is logged in to, the attacker can see what actions the victim performed including as suggested above, any ...


1

Is it necessary to have csrf tokens for login forms? In reference to Wordpress - No, it is not. Login pages are not susceptible to CSRF. The whole premise of CSRF is that the user is already authenticated to the app when the unwanted data is submitted. Per OWASP: "CSRF is an attack which forces an end user to execute unwanted actions on a web ...


8

It is generally suggested that CSRF tokens are applied to login forms to prevent session donation attacks. The idea is that you can trick a user into visiting a link, and they become logged in under an account that you control. They then perform some action involving storing some secret information to the account, without noticing they're logged in as you, ...


1

You could do this with a Custom HTTP Module, written in ASP.NET. The ASP.NET is required to run the module, although the rest of your deployment need not be in ASP.NET. Note this code is untested, but should put you on the right lines. Of course this does not implement the full logic described in my other answer for dealing with CSRF using Origin, so it only ...


2

Simply put, the Origin header is not sent for same-origin requests by all browsers. This would make for complex logic when implementing CSRF protection. That is: Lack of Origin header = Old browser OR Lack of Origin header = Same Origin Origin header matches domain = Same Origin Origin header does not match = CSRF attack As you can see, it is not ...


0

It's mostly due to history. People have been aware of CSRF since the early 2000's, before the Origin header had been invented. The concept of "token in a hidden field" provided sites an immediate way to fix the flaw, without waiting for browsers to update. While the mechanism is a little messy, it turns out it is possible for frameworks to provide this ...


0

Any browser flaw for example where it allows Origin header being set client-side(highly unlikely with modern day browsers) will now enable CSRF attacks against your application. Additionally, from http://security.stackexchange.com/a/74526/66075 You can't currently depend on the Origin header, because it is not implemented in all browsers which are in ...


0

I hope i understood your question. As for the first part, Normally, as the attacker will be on a different origin than your server, so the browser wont allow it to read the response thereby preventing it from 'parsing the response' and sending the token in a subsequent request. But you have explicitly allowed all origins which renders this protection ...


1

XSS is usually an attack against a server. Unless your phone is serving Web pages to external connections this should not be a problem. If your server that is serving the pages to the phone is vulnerable then XSS is identical to a normal website - with the exception it may be harder to trick someone into following a link. Unless your application takes in ...



Top 50 recent answers are included