we have been using whmcs for a long time now and all was grate recently we started to get strange complaints from certain people but not all that when they login to client area they are getting invaild csrf security token
This does not happen on admin panel only client aide
This only happeneds with some people on and off
We tried following links here such as disabling csrf tokens, this did not fix.
We also tried disabling the IP save option I made sure our session path is correct, and we are now at a loss not knowing what's happening any ideas or support would be grate.
Related
I have a single-page static app hosted at example.com. My server for the app is hosted at server.com. I keep these two services completely separate and they can scale differently this way. When the user wants to login their username and password is passed to yoyoma.com and a cookie is set on server.com with the access_token. The user is then redirected to example.com and is now logged in.
From the static app at example.com, we can now make AJAX requests to server.com setting withCredentials=true so that the access_token we set is passed along to server.com. This works perfectly in every browser but Safari. The only way I've gotten Safari to work is by going to preferences -> privacy -> disabling "Prevent cross-site tracking". I know that the cookies are getting set on server.com, but they don't get passed with the AJAX request. It seems to be some Privacy feature that Apple thinks is just wonderful, but how are you supposed to get around this issue. I'm not an ad service, I'm not doing anything evil, just trying to get my app to work. I specifically want to build a single page app where the server is on a different domain. Is this possible in Safari or has their privacy setting made this impossible?
Note: I should also mention to security fanatics that when the access_token cookie is set, the user is then redirected to example.com with a CSRF token. This csrf token is passed in every AJAX request by a header to prevent Cross Site Request Forgery.
Assuming you're set on keeping different domains - which is not at all unreasonable there are some ways to tackle it, but they come with compromises
1
Have example.com redirect to a server rendered server.com/login for creating the httpOnly cookie and then redirect them back to their logged in state in your SPA.
As I understand it, when Prevent cross-site tracking is enabled in Safari, the intention is to have the user interact with the other domain before cookies are allowed to be sent.
By redirecting them, that intent has been created and you should have no issue setting a cookie and have it be sent by example.com.
However it does come it its own set of limitations
Read more
2
Look into the discussion related to StorageAccess as the idea here is to work with third party auth solutions that rely on cookies from different domains. Safari ITP has sorta made those harder to use, so the idea is to work with vendors for a better solution than LocalStorage.
3
Store your key in LocalStorage, and vet all running javascript code coming from you and make sure to follow best practices when it comes to dealing with user created values.
LocalStorage exposes your to potential XSS, but Cookies expose you to CSRF attacks. You have to mitigate those and it's not too hard, but keep in mind you introduced those vectors when cookies were used.
Any XSS that happens is game over, even with httpOnly cookies. Forget your auth key, running the attackers code can do so much more damage.
Keylogger to take username/password
If the attack happens after an authed state, they could pop up a modal asking re-auth.
Submit a request to change email and then ask for password reset
Don't get me wrong, it's easier to dump LocalStorage as a generic attack versus the attacks listed above
That being said, in the end the resources you spend on dealing with cookie issues, could be better spent hardening down your javascript running on the users browsers to ensure they aren't running malicious code
You can't protect them from extensions though, and a httpOnly cookie would at the very least ensure that their keys aren't leaked. Know your compromises.
Edit: Keep in mind that whatever approach you're taking, any further reliance on browser needs to think through the different versions of browsers out in the wild. As an example, don't assume using httpOnly cookies and setting a sameSite policy negates the need for a CSRF token. Any addition of cookies might s till need a CSRF token as a header as of today unless it's a controlled environment.
Personal Opinion held loosely.
Do no harm. Cookies add "harm"/work that you have to mitigate.
Cookies might protect attacks leaking access tokens but why would an attacker care about the access token when they can run any code they wish?
LocalStorage weakness is XSS, but Cookies does not protect against that.
What prevents them from just taking the password?
Popping up a login modal to an unexpected user that won't think twice, hell Github does that from time to time for good reasons, it's not unheard of.
App was developed in Web API. We are using AntiForgery Token validation for all the POST calls in xyz.com. Registered xyz.com users get email alerts for the contents they are signed up for. Users click item from email to view the content details. On click of item first click event is being saved in SilverPop and silverpop redirects to actual content in xyz.com. Details page is being loaded with out any issues after authenticating the user based on few query string parameters. Issue is when user make a post call(to saving for later, book mark etc) App is throwing Antiforgery token mismatch error. Sorry for bad English and long question. Strange part of this issue is We are unable to replicate this error and its not occurring consistently. We have two server and 1 load balance hosted in AWS not using sticky session enabled. Using Forms cookie authentication. finally, this issue kept occurring though we run with 1 server. Thanks for reading and appreciate if any one could help.
*User must be Authenticated to validate CSRF token ? This xyz.com makes few api get and post calls.
I've been building an app (ios and web app) on Parse over the last few months and have only just discovered how their session tokens work. This is what I have learnt so far:
Each user has their own session token
The token is used to replace the user credentials (for authentication) when making requests to the server
The token never changes (even when password is reset) and never expires
The token is stored locally on client side when logged in
User can be logged in using the Parse.User.become(sessiontoken, options) method, with only the session token
This seems very insecure to me, or am I missing something? It seems that if anyone manages to get this token they have eternal access to the users account, even if username and/or password are changed?
Thanks,
Mario
Looks like they have just updated their systems to use revocable user sessions. Nice one Parse!
http://blog.parse.com/2015/03/25/announcing-new-enhanced-sessions
I have also double checked the session token returned from REST API & Android Client. It is the same. Even after I changed the password.
This is definitely a potential security issues. Anyone who's mobile device is stolen, the hacker could get the session token if the session is not encrypted and the security of user data is in jeopardy forever.
As the hacker could use the session token from any client forever. You will never know when the hacker will do the evil.
I am seriously concerned about the issue. Hope somebody will address it.
PS: Hi Mario, I have logged an issue on the Facebook Developer Platform.
https://developers.facebook.com/bugs/309490399239393/
Hope somebody will track it and resolve it eventually.
I have a grails server and an iOS client that communicate over HTTPS via POST messages. I'm using PersistentTokenBasedRememberMeServices to ensure that the user doesn't have to enter his password all the time. This doesn't seem to work as the session is lost continuously and the user has to login again. The server logs show that a CookieTheftException has occurred with message "Invalid remember-me token (Series/token) mismatch".
Not all server actions require a logged in user. Some can be accessed anonymously and this may be the root of the problem. When the user accesses restricted server actions, the session is maintained, but not when accessing unrestricted actions.
Here's my config in Config.groovy:
grails.plugins.springsecurity.rememberMe.cookieName = 'SomeRememberMeName'
grails.plugins.springsecurity.rememberMe.persistent = true
grails.plugins.springsecurity.rememberMe.alwaysRemember = true
grails.plugins.springsecurity.rememberMe.persistentToken.domainClassName = 'com.myapp.PersistentLogin'
grails.plugins.springsecurity.rememberMe.tokenValiditySeconds=31*24*60*60
I added some traces in the iOS client and noticed a couple of things. First of all the JSESSIONID cookie doesn't have an expiration time, which means it isn't saved in the client like the rememberMe cookie. Can I force it to have an expiration time or is that even a good idea? Secondly I noticed that sometimes the rememberMe cookie that I receive from the server is empty. That may be just because a CookieTheftException was thrown.
Since all of the post message bodies are encrypted with 256-bit AES, I'm not really worried about cookie theft at this time. I just need to get this to work.
I tried adding the following to my config to ensure that the session would be always updated even when accessing unrestricted actions:
grails.plugins.springsecurity.useSessionFixationPrevention = true
grails.plugins.springsecurity.SessionFixationPrevention.migrate = true
grails.plugins.springsecurity.SessionFixationPrevention.alwaysCreateSession = true
I don't even know what these all mean. I just liked the "alwaysCreateSession" part and figured that I need to enable session fixation prevention in order for that setting to have any effect. Will it still always create a session if I set useSessionFixationPrevention to false?
Any help is appreciated.
If you are using PersistentTokenBasedRememberMeServices, your "remember me" token will change after every HTTP request.
Unfortunately that means that requests will only authenticate if your browser makes exactly one request at a time, and browsers often don't do that. If there are 4 few images on a page, the browser will send out 4 simultaneous requests, each with the same "remember me" token. Only the first request will authenticate, because after Spring Security processes the first request, it changes the token. When Spring Security tries to process the next request, it throws a CookieTheftException.
That's the typical scenerio for the CookieTheftException when using PersistentTokenBasedRememberMeServices.
Here's a link that explains some things you can do about it: Grails Cookie Theft Exceptions
There's also an open issue with the Grails Spring Security Core plugin that discusses this problem: Remember me functionality fails intermittently with CookieTheftException: Invalid remember-me token
The JSESSIONID stuff is probably a red herring. If you're using PersistentTokenBasedRememberMeServices, your authentication won't need a session.
I've just realized that if I log out from facebook.com, the access token in my app is no longer valid (fbSessionInvalidated gets called).
I don't understand why logging out from the Facebook website would invalidate the access token in my app. Is this normal behaviour, and if so why is it happening?
it's normal, you need to ask a offline token.
But be carefull Since 2nd of may.
This is in place http://developers.facebook.com/roadmap/offline-access-removal/
I just enabled "Remove offline_access permission" in my app's advanced settings and this problem is fixed (I also get 60 days access tokens now).