I've an MVC3 website in which I've to redirect the users to the login page if the session timeout expires. After some research, I've got that I have to add to the web.config
<sessionState mode="InProc" cookieless="false" timeout="1"></sessionState>
to set the user session timeout. In this case, if the user is idle it will clear the user session data after 1 min. I've added this
<authentication mode="Forms">
<forms loginUrl="~/Default/Login" timeout="1"/>
</authentication>
to redirect the user to the login page in case of session times out. Actually, It works but I've some questions to understand exactly what is happening:
What is the relation between these 2 tags? what is the dependency between them?
Is it mandatory to put the timeout attribute = 1 for both tags?
Is there a better approach that I can follow to accomplish what I need.
Thanks in advance.
The difference between SessionState and Forms Authentication is:
SessionState: A session is created for every request to your application. Which would have its own timeout.
Forms Authentication: Authentication is created when a user authenticates with your application. Which also would have its own timeout. This timeout value is stored as part of a Ticket, the Ticket is encrypted and stored in a cookie or URL (cookieless authentication), I believe.
If you want to end a users authentication based on the session, you will have to write that into your application. The only reason I would do this is if, I stored authenticated data in a the session, so to cross requests.
The sessionState element configures session-state settings for the current application.
When a new client begins interacting with a Web application, a session ID is issued and associated with all the subsequent requests from the same client while the session is valid. This ID is used to maintain the server-side state that is associated with the client session across requests. The element controls how the ASP.NET application establishes and maintains this association for each client.
This mechanism is very flexible and lets you host session-state information out of process and track state without using cookies, among other things.
Timeout: Specifies the number of minutes a session can be idle before it is abandoned. The timeout attribute cannot be set to a value that is greater than 525,601 minutes (1 year) for the in-process and state-server modes.
The session timeout configuration setting applies only to ASP.NET pages. Changing the session timeout value does not affect the session time-out for ASP pages. Similarly, changing the session time-out for ASP pages does not affect the session time-out for ASP.NET pages.
The default is 20 minutes.
Forms Authentication: - This is a cookie based authentication where username and password are stored on client machines as cookie files or they are sent through URL for every request. Form-based authentication presents the user with an HTML-based Web page that prompts the user for credentials.
All your questions are answered with above description
Related
Background: I have a javaee webapp deployed on tomcat which uses form based authentication. When the web server receives a login request, it sends the request to a dedicated authentication service which validates user login (User id and password). After successful authentication user's session is maintained in the web server.
Problem: I have written a simple webpp source code here, to simulate the scenario. On successful login the current HttpSession instance is invalidated and new instance is created. For each request for a post login page, the session is validated. A new JSESSIONID cookie is set which is used to identify the user during the session until session is expired or user logs out. This cookie can easily viewed in browser's dev tools. If I copy the cookie and set this in a different browser via JavaScript (document.cookie="JSESSIONID=xyzz") and then try to access a post login page, the server identifies it as a valid request and session is validated successfully. The post login page is served without user being challenged for user Id and password.
POC: User opens chrome and enter the URL http://localhost:8080/mywebapp/ and logs in with admin and pass1234. On successful log in the home page http://localhost:8080/mywebapp/home is shown. Now the JSESSIONID cookie is copied and set in FireFox. User enters http://localhost:8080/mywebapp/home in Firefox and is shown the home page without being challenged for userId and password.
Question: How can this be prevented wherein same session is getting replicated over multiple browsers?
You can't prevent this specific case of simply copying the cookie from your own browser (or by copying the cookie value from a HTTP payload copypaste/screenshot posted by an ignorant somewhere on the Internet). You can at most prevent the cookie getting hijacked by XSS or man-in-middle attacks.
This all is elaborated in Wikipedia page on the subject Session Hijacking of which I snipped away irrelevant parts (either already enforced by Servlet API, or are simply not applicable here).
Prevention
Methods to prevent session hijacking include:
Encryption of the data traffic passed between the parties by using SSL/TLS; in particular the session key (though ideally all traffic for the entire session[11]). This technique is widely relied-upon by web-based banks and other e-commerce services, because it completely prevents sniffing-style attacks. However, it could still be possible to perform some other kind of session hijack. In response, scientists from the Radboud University Nijmegen proposed in 2013 a way to prevent session hijacking by correlating the application session with the SSL/TLS credentials[12]
(snip, not relevant)
(snip, not relevant)
Some services make secondary checks against the identity of the user. For example, a web server could check with each request made that the IP address of the user matched the one last used during that session. This does not prevent attacks by somebody who shares the same IP address, however, and could be frustrating for users whose IP address is liable to change during a browsing session.
Alternatively, some services will change the value of the cookie with each and every request. This dramatically reduces the window in which an attacker can operate and makes it easy to identify whether an attack has taken place, but can cause other technical problems (for example, two legitimate, closely timed requests from the same client can lead to a token check error on the server).
(snip, not relevant)
In other words:
Use HTTPS instead of HTTP to prevent man-in-middle attacks.
Add a checkbox "Lock my IP" to login form and reject requests from different IP associated with same session in a servlet filter. This only works on users who know themselves they have a fixed IP.
Change session cookie on every request. Interesting at first sight, but breaks when user has same website open in multiple browser tabs/windows in same "session".
Not mentioned, but make sure you don't have a XSS hole anywhere, else it's very easy stealing cookies.
Last but not least, I'd like to make clear that this problem is absolutely not specifically related to Servlet API and the JSESSIONID cookie. All other stateful server side languages/frameworks such as PHP (PHPSESSID) and ASP (ASPSESSIONID) also expose exactly the same security problem. The JSESSIONID was previously (decade ago orso) only a bit more in news because by default it was possible to pass the session identifier along in the URL (which was done to support HTTP session in clients who have cookies disabled). Trouble started when ignorant endusers copypasted the full URL with JSESSIONID inside to share links with others. Since Servlet 3.0 you can turn off JSESSIONID in URLs by enforcing a cookie-only policy.
<session-config>
<tracking-mode>COOKIE</tracking-mode>
</session-config>
See also:
How do servlets work? Instantiation, sessions, shared variables and multithreading
How to prevent adding jsessionid at the end of redirected url
remove jsessionid in url rewrite in spring mvc
What you have stated is called session hijacking. There are many good answers on how to prevent it.
Using same Jsession ID to login into other machine
we can use Encryption or hide JSESSIONID using Browser control.
Thanks
In my application I use web services to get required information. To actually use this services you have to login first, you get your token - encrypted password, afterwards this token is attached to SOAP requests to identify current user. The thing is, when you do not use service for 15 minutes, your token changes and when you are trying to obtain another bunch of information from the server it denies old token. As a result app do not get required information and throws a heap of errors.
How to send user (load Login.axm) to Login page when token has been changed?
Thank you, Shay Shmeltzer for your answer.
How I solved this problem:
1) First I read how does sessions work in my particular case. I used stateless session which means -
A new session is opened for an initial request and the session remains
open for subsequent requests. Relogin occurs automatically
(transparent to the user) if the session is closed. UsernameToken and
PasswordText must be included as SOAP headers in the initial request
to open a stateless session.
Stateless session management is the best method to use for high-load
Web service applications. Using Stateless mode, the application
provides the username and password only once, that is for the initial
request. A session is opened on the server and is dedicated for this
user.
In the response Siebel Business Applications return the SessionToken,
which is an encrypted string containing the information about
username, password, and timestamp. For subsequent requests the
application must use the SessionToken to reuse the session.
For security reasons SessionTokens are regenerated for each response.
The application must provide the last received SessionToken for the
next request.
The SessionToken-Siebel session map is maintained in the Siebel Web
Server Extension (SWSE); based on the SessionToken value SWSE sends
the request to the correct Siebel session (task).
Although the session is persistent, authentication happens for each
request (SWSE decrypts the UserName and Password from the
SessionToken).
the main problem was :
NOTE: Reconnecting or automatic logging in again will only happen if
the token has not timed out. If it times out, then the user must
manually log in again. Token timeout must be greater than or equal to
session timeout. For more information on session token timeout, see
Session and Session Token Timeout-Related Parameters.
in my case standard session token live time was 15 minutes.
That is why I included counter in my code and checked it before each request. If counter time > 15 minutes, I sent log in request to the server to get new session token. The reason, I did not change current page to log in page straight away after the counter exceeds 15 minutes is: place in code, where I check counter is already initiated by the bindings to get required value to render it, so if your token has expired you will get a heap of errors. That is why firstly I renew the session sending log in request, get active session token and put it into the last request which is requested by binding. After app renders page without any errors, it shows pop up message "Session has expired" and goes to log in page.
You can programmatically set the soap header being sent to your SOAP service from ADF Mobile - http://docs.oracle.com/cd/E37975_01/doc.111240/e24475/amxwebservices.htm#CHDIBIIE
I don't really deeply understand of the session mechanism but just good enough as a casual user of the technology. I have a page implemented with jQuery ajax request. If I keep refreshing the page at a fast pace it would make the session expired and I have to login again. I would appreciate for an explanation of the phenomenon and solution to prevent that.
Sessions consists in to main parameters
Cookies and Server-side session data
In a very little explanation
cookies contains session ID, that references to the server to get session data. Server then fetchs data with the session ID and matches it inside a file with various parameters.
Your problem must be session timeout, it depends mainly on session timeout parameter configured.
Your ajax requests only works if the session timeout hasnt expired thats why it prompts you for login.
You can solve this by defining a service that does not require authentication, you can define your functions on a specific file with no session initialization so the request can bypass the security session, and your other pages that need security are secured at the same time. Like amazon mechanism.
Looking at the OWASP Session Management Cheat Sheet, every time a session expires, must a user go through the same Pre-Auth --> Auth --> ... steps to make a new session?
For example, if a session expires and the web app requires authentication, will the user have to log back into the web app before getting a new session?
Sessions are maintained with cookies.
Http is a stateless protocol. Every request to server works in isolation. No request has any information about previous request.
Say a user named A logs in to the site. This site works with session and sets session data for a user. Internally the server creates some value and associates with a particular user. A value 12345 is computed and associated with user A. The server decides to give this value's name as sessionId. It sends sessionId in the cookie and this cookie will be stored on the user's browser. Next time the user A makes a request this cookie will be sent to server. Server reads for cookie sessionId, and finds it. Then it sees with what user is the value in this cookie i.e 12345 is associated. It finds that this value is associated with user A and so its the user A, who is making the request.
Say this cookie expires, can be for various reasons. Either user deletes the cookie on his end. Or after certain days, server cleans this association between user and the session. In that case server will not be able to know who is the user making the request. And hence the entire flow of login by user, seesion generation will have to take place.
So, yes, if a session expires and the web app requires authentication, user will have to login again
Yes, the user has to log in again. Also, it's important that a new session gets a new session id, as an attacker could have gained the session id. If you re-authenticate the same session id, the attacker would gain access as well. See session fixation attack.
Depending on the safety requirements, you might also have to implement a maximum time to life for every session. Usually an attacker would take over a session and try to keep it alive as long as possible. Expiring the session after a certain amount of time, even if it is active, is an effective way to ensure that attackers can only have access for limited time.
How can i make something like this in MVC3 where i can still use [Authenticate] in the controller (or in a filter that is applied to all pages except the login page) ?
User enters username and password which gets sent to the server as a post request.
Application receives the posted information on the login page [httpPost]
Application creates a new unique SESSIONID and writes it to the database
Application requests that the browser writes a cookie with value SESSIONID=
The next time the user requests a page cookie with SESSIONID= gets send everytime. (until it expires or is deleted)
Application compares SESSIONID and IP address, which has been sent and checks if it exists as a valid session with that IP in the database. (Some session cleanup will be performed on login as well, users other sessions that exists will be removed)
This approach, seems to be rather difficult for me in ASP.NET. :-)
This is already build into Asp.Net. I think you should have a look at the Membership provider
=> http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx