While load testing using loadrunner all my virtual users are getting logged off from application after 30 min. Looking in detail came to know that authentication cookie is getting expired even though we have continuous activity performed by users.
Now we are trying to update the cookie explicitly after each action to prevent expiration, but not sure how server identifies that authentication cookie is expired. The cookie has only encrypted text and no explicit title mentioning expiry time.
What information in cookie should be updated in authentication cookie to prevent it from expiring?
Cookie Information:
Cookie:
.ASPXAUTH=66DD4AB74239F00D553BA9640D3AD3F284F47DEC315FD6789AE3FB8D67D2A46A4E89EDB45845C921A7557BD6B39A12EE07188D1009D581AA7AAF6743710653AE44EEF2733CC16082C595D7AE7C73D3E7E3D44BA1BAEEFEB1BF5F98B35C5F8429670FFDD5586E03BB3138C5B78945D82702BDD7C4;
path=/; HttpOnly
Tell us how you are managing session state in your script. Generally if you are cleaning all cookies and instantiating a new session for each iteration you should not run into this. If you are attempting to maintain some sort of singular session state for the entire length of your test I could see how the server would potentially kick you out after your original session technically logged out of the system (as part of a business process).
Also, do you have explicit cookies noted in your script? If so, you may want to consider commenting these statements out as LoadRunner will manage cookies automatically. As part of your burn in consider running a singular virtual user for 30 minutes to an hour to see if you experience this on a single virtual user level. It's a lot easier to fix for a single user and then projecting to load than it is to try and figure out what is happening across dozens or hundreds of users experiencing a similar issue.
From what I can gather the Server keeps track of the expiry time of the cookies, and it's also the server that updates the expiry time, meaning you as the client have no control over this.
I assume the flow is this:
The browser or LoadRunner Script will always send the cookie and the
server then verifies it's expiry time on the server side, redirecting
you to the login page if it has expired.
I've had this happen to me, and solved it by visiting a special page on the server that "updated the client session expiry time". Perhaps you have a similar situation?
Related
I've successfully used cookies before and I'd like to begin using JWT. My biggest question is how to pass your token to a website during the initial GET operation, for example when a user types your domain into their address bar or clicks on a link from some other website like google.
When using cookies for example, if you type stackoverflow.com into your web browser, the persistent cookie is sent to the website which seamlessly allows your own stackoverflow session to be automatically authorized.
I am aware that I can programatically pass my JWT token via a javascript GET through the HTTP headers but how do you pass the token when a visitor types in your URL into their web browser?
Possible solution #1
My thoughts have been to have javascript code check if 'authorized'. If not, check for a JWT token in local storage. If found, redirect to the same address. The problem of course would be that there is no way to pass the token during a redirect.
Possible solution #2
Similar to above but not issuing a redirect, I would update the current page to reflect the 'authorized' state.
Possible solution #3
Use a permanent cookie containing the JWT token. I am thinking that this 3rd option would be the best. If I did this, there would be no need to pass the JWT via an HTTP header.
I've thought about this for a few days, read up on JWT and here are my conclusions for avoiding JWT in my particular case:
No easy way to authorize a user who opens their browser and types in your website. With cookies, your server immediately knows how to respond to this headerless GET request.
No way to easily change the JWT token signature. All users are immediately affected by such a change, essentially forcing everyone to authenticate again.
No way to easily invalidate a specific JWT token. The best you can do is to maintain and check a banned signature list on the server. This of course would require a centralized or distributed server method almost identical to a cookie session management system. This would force a coupling between the token and the server, no longer stateless as intended by JWT.
SUMMARY
Cookie management requires more server infrastructure but you have much greater session control. State is seamless (in the case of #1 above). You can instantly invalidate state. For example, the user can log out (deleting the session at the server level) or the session can be instantly banned by an administrator by simply deleting the session.
I also see the benefits to JWS:
no need to hit the db or cache system when authorizing.
simple authorization between multiple servers having the secret key.
simple authorization, no session management programming and no db session state storage required.
...but the drawbacks stated previously are too great for my particular needs.
If an application redirects the user to the Keycloak login page, and it sits there for more than the "Login timeout" (default 5 minutes), then when the users enters a username and password, instead of a login, she is greeted by:
You took too long to login. Login process starting from beginning.
To avoid this, one can change "Realm Settings → Tokens → Login timeout" to e.g. 10000 days which is 27 years, which should ensure this never happens in reality.
But before we go ahead and effectively disable this timeout, we'd like to ask: What is the purpose of this timeout? Somebody apparently went to the trouble of implementing it, but what is it protecting against? What are the (security?) consequences of disabling it?
As far as I know, it is mostly used as an additional mechanism to avoid session fixation attacks. For instance, in a company a user goes for a coffee and leaves the computer on, and then the hacker sees the opportunity and manually sets in the Browser URL the
current login session ID (or just copies it). Now if the system is configured in a way that the session ID does not change in-between the pre and the pos login phases. Then after the victim has successfully authenticated, the hacker will be able to use, without having to insert any authentication, the session that the victim is currently on;
The higher the timeout is, the wider will be the window of opportunity for such attacks to happen. Login timeout is just another layer of protection to avoid such issues, as it is session expiration, changing the Session ID between the pre-login and pos-login phase, among others.
More formally one can read in (source).
Initial Login Timeout
This extra protection mechanism tries to force the renewal of the
session ID pre-authentication, avoiding scenarios where a previously
used (or manually set) session ID is reused by the next victim using
the same computer, for example, in session fixation attacks.
And from the OWASP.org
Session Fixation is an attack that permits an attacker to hijack a
valid user session. The attack explores a limitation in the way the
web application manages the session ID, more specifically the
vulnerable web application. When authenticating a user, it doesn’t
assign a new session ID, making it possible to use an existent session
ID. The attack consists of obtaining a valid session ID (e.g. by
connecting to the application), inducing a user to authenticate
himself with that session ID, and then hijacking the user-validated
session by the knowledge of the used session ID. The attacker has to
provide a legitimate Web application session ID and try to make the
victim’s browser use it.
A fairly good explanation on how the session fixation attacks works and how to prevent it here and here.
Now I am not a security expert, but I would say that if you have other preventing mechanisms in place such as change the session ID, you should be fine. However, on the other side of the coin, do you really need that much time to login? And is that much of an annoyance to just refresh again?
I have been reading up on how CSRF Tokens are implemented to prevent CSRF attacks. The OWASP page (https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet) and various articles state that one can generate a random unique token either on a per page basis or a per session basis. (of which they recommend generating it once per sessions)
If only one token is generated per session, then wouldn't that mean that all form pages using tokens for that session will have to have the same token every time the page is loaded (whenever say it is refreshed)? But in most implementations I have seen each load for the form has a different random token.
How does it work? After every successful check at the server side, is the CSRF token present in the session invalidated?
I just wanted to know if I am understanding this right. I read many similar questions on Stackoverflow and other blogs but I am still confused.
Thanks !!
I haven't read the OWASP page, but I believe in this context a session starts when a visitor first arrives at a site, and continues until the session expires (whether through inactivity or other generally server-defined criteria) or the visitor closes their browser.
When a session is first started, there won't be a CSRF token present in the session, so the server will generate one, and store the token in its internal data. A session handle is returned to the browser, and when the visitor loads or reloads another page on the site, it returns the session handle to the server, the server finds it has a CSRF token already set, and uses the existing one, rather than creating a new one. Thus, you don't need to worry about the token being invalidated as long as you only create a new one only if there isn't one already present in the session.
Even if the CSRF secret is only generated once per session, it's possible for each form to get a different token, by salting and hashing the secret (similar to how passwords are salted and hashed) that's sent to the browser. On form submission, the server can verify the salted token against its secret (again, similar to how passwords are checked). That way, each form can get its own unique token, without the server needing to remember or invalidate anything other than the per-session secret.
Once passwords match my login script on Apache do print this cook:
my $session = new CGI::Session();
$session->param("~user", $user_name);
my $cookie = CGI::Cookie->new(-name=>$session->name, -value=>$session->id, -domain=>'');
print $session->header(-cookie=>$cookie, #_);
Then on every other script, after checking that session is not expired or empty i do give access and i check for login USERNAME with this code:
my $session = CGI::Session->load();
$loggd_user = $session->param("~user");
Then $loggd_user has access to all the data related to his username. But what happens if one modifies the cook to another username? Is it possible? Will one have access to someone else data? Any other security issue with this code or is it ok?
There's an explanation of the security on the back end which can answer some of these questions at:
https://metacpan.org/pod/CGI::Session::Tutorial#SECURITY
The only thing passing back and forth with CGI::Session is a session ID. All of the information about the session is saved on the server (wherever you choose -- please make it somewhere that the web server will not serve!). The security of that data depends on how the server is configured, what options you're using with CGI::Session, etc.
It's not clear if you're verifying the IP. If you aren't, and anyone gets a hold of the session ID of a valid session, they can hijack it and pretend to be that person. It's trivial to fake cookies because they're just header fields, which can explicitly be set. The difficulty is faking a valid session ID in the cookie.
Since you're using cookies for the session, the browser keeps track of them for the client and re-sends them to the server every time you visit the page. This opens the door for cross site request forgery if you don't have a secondary means of identifying the client aside from the cookie. Even checking the IP doesn't prevent against CSRF.
You should expire these cookies at some point, and I don't just mean on the server side. The cookie should have an expiration date so the client deletes it's cookie about the session so it will stop sending it. I'm not sure how that's done in CGI::Session, but I didn't look at more than the tutorial.
And, if your server is accepting unencrypted connections for things that require authentication where you send a password, or when you're passing the session token back and forth, you're begging for trouble.
This is not to be interpreted as a complete list of potential security issues with this method.
I'm creating an iphone app where the user logins once (when they open the app for the first time), then will never have to login again (like how instagram does it). The app will automatically log them in the next time they open it up. However, the app makes a bunch of requests to a web server.
What is the best way for the server to issue session tokens? How long should the session tokens be valid for? How can I ensure the user never has to log in again, while still providing secure session tokens.
One approach is for the server to issue a token to the user when the user logs in for the first time, and make that token permanent. That, however, does not seem secure.
Thanks for the help!
Well, generally the session is already handled through session cookies. Unless you're planning to have third parties connect to your service, I think it's a bit overkill to do anything besides basic http authentication. I would definitely send all of your connection requests over an https connection though.
As far as persisting the session on the iPhone side, you can save the user and password in the Keychain, and then automatically retrieve and send it to the server when it requires you to log in again, without having to prompt the user to log in again. How often you want the sessions to last on the server end is really up to you.
What is the best way for the server to issue session tokens?
One way to do it is using OAuth. It is more complex than cookies but it has more features.
A token is granted to each application and can be revoked by the user from a page in the server. This token can be permanent or temporary. You can store it as plain text or inside the iPhone keychain, depending on the level of security you need. There is open free code for server and client implementations. Another benefit is that clients can log in your service using their Twitter/Facebook/... account so they don't need to register on your site.