It is my understanding, according to the MSDN, that regenerateExpiredSessionId="true" specifies that the session ID will be reissued when an expired session ID is specified by the client. However, this does not seem to be working as described.
Let's say you have an application configured as follows:
<sessionState
cookieless="AutoDetect"
regenerateExpiredSessionId="true" />
And somewhere else, you have a link to a page in that application in which an expired session ID is embedded:
<p>Here is a link!</p>
If a browser in which cookies are not enabled clicks on that link, the session ID is not reissued. It is recycling the expired ID from the URL and creating the new session with this old ID.
Of course, if several no-cookie browsers click on the link simultaneously, they ALL share that same expired session ID, which is obviously a security issue.
Isn't regenerateExpiredSessionId="true" supposed to prevent users from inadvertently sharing the same session state? If so, why isn't the framework generating new session IDs as expected in this case?
Are you sure your session is actually expiring ?
If you are using Forms authentication, its ticket can expire at different time than the session. (gets more confusing when you throw sliding expiration into the mix)
To check with cookieless enabled just look at the url when you think the session has expired... if the second part of the url ticket "F(xydUI....)" changes when you login again but the "S(dysXy...)" stays the same you know your session is just getting renewed and hasn't fully expired.
Hope this helps
Related
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.
I want to create a Chat Messenger for my chat website (because of Push notifications).
But the user has to log in. I want to have it like the Facebook app, that at the beginning the username and password is requested and if the "remember" field is checked you don't have to login every time (maybe once a month then). What's the best way to do that? A session on the Server or saving username and password local? If I make a HTTP-Request where Session Data is saved, is it still available or active when I make a HTTP-Request on the same server later? (like for getting the chat content, or something else?)
I searched the internet, but didn't find something useful. If someone could tell me how to do that, or post a link or something that could help..
Thanks a lot!
The web server identifies a client through a token (e.g. session cookie). With each HTTP request, session cookie is sent to the server and server knows that request is coming from a client who has authenticated before.
The time span of this authentication is of course equal to the validity of the token (cookie in this case). The token can be invalidated on either client or server. You may require special mechanism for keeping sessions valid for month. Defaults are usually like half an hour.
Second option of storing password is more of a security decision. If you store user credentials, then you have to make sure that you do it in a secure manner.
If the user checks the save password field you could save the password to NSUserDefaults.
Although that's not good for encryption, it works. You should also use some type of encoding (SHA-1). You could make it aks for your password after say 10. To do that you would want a data store. You would load it into an int and then you can simply do something like runTime = runTime + 1; and if it get to ten purge the password data
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.
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?