I have a web application running on JBoss server based on JSF framework.
I need to redirect my request to an entirely new web application running on some other server and on some other machine geographically located.
My doubt is if I redirect the request from my web page to another web application web page will it expose the session parameter at the other end.
I have some very critical information stored in the session and I cannot afford to expose the details to another web application..
Along with the redirect request I would be sending some parameters to the remote web application which will use these parameters for certain mathematical computation.
Can anyone guide me on this?
Is it possible for the other web application to see what is present in the session
No. That would have been a huge security hole throughout the current world wide web. Think about it once again, are you able to see what for example google.com and stackoverflow.com have in its session? No? Then the other web application definitely also can't. All which the web application can see from outside is the sole incoming HTTP request in its entirety.
This problem/question has at least nothing to do with JSF.
If you invalidate the session before the redirect then it doesn't matter if the external web application sees your session cookie. They couldn't turn around and emulate requests on your session anyway because the session is no longer valid.
request.getSession().invalidate();
I don't think this will be an issue though because I doubt that the request header to another web application would include the same session cookie.
Related
I have developed a web application in Java Spring Boot. After login to the web application JSESSIONID is stored in browser cookies, now when I copy this cookie details from my current browser and create same cookie in some other browser then I'm able to login to the system without asking me for login.
Please let me know how can we prevent this Session hijacking threat. Is there anything I need to do at application level or anything on server level.
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
we have a problem in our web application and I'm looking for some opinions.
The following scenario:
We have a Java EE Server Application deployed on a JBoss Application Server
Our Web Application is also deployed in the AS
The Web Application communicates with the server via JAX-RS
The Web Application needs authentication
Currently we are using 'form-based authentication', which is directly provided by our Application Server.
The advantage of this approach:
List item
We don't have to do anything, but just specify the auth-method 'FORM' and specify a login page
We can design our login page by ourselves -> the page looks awesome
The disadvantage and also the problem I'd like to discuss:
Our webapplication makes calls (inital-page-load/ajax) to our server application.
If the user is authenticated, it will receive JSON responses. But if the user is not authenticated, the form-based auth will intercept the call and return a html page.
(this looks fishy: WebApp makes a ajax call and expects json, but will receive a http redirect to a html page [login.html]).
The current problem:
At some point the session cookie (of the form-based auth) will timeout, and then the complete application breaks, because each ajax request will not receive any json (as expected), but will receive the login.html page.
Would be really thankful if people who solved that problem could report about their approach and architectural design decisions.
Current Ideas:
Switch from form-based to something else (and provide a /login rest resource)
React on the client code on possible wrong responses (if http code 301 -> redirect on login page)
Something else I can't think of right now
I intentionally wrote 'session aware' instead of 'session shared' applications. Following is a scenario:
I have a webapp (WA1) deployed in one instance of Tomcat.. Assume that all apps are deployed on root and we are not dealing with contexts. This application allows users to login, do their thing on site and logout.
There is another webapp (WA2) on another tomcat instance. This application handles a service, lets say, it reads some files and streams to the browser.
WA1 serves a page which has a link that links to WA2.
Now I have a valid session in WA1 which identifies who the user is and if the session is a valid session. I would like WA2 to know it before honoring the request from the page served by WA1.
What is the best way to handle this?
I have ruled out sharing sessions (unless that is the better way, please explain), due to the reason that WA1 could be itself load balanced and WA2 could be load balanced, and to keep shared sessions over two load balanced instances of the app may get overwhelming.
I am leaning towards a 'token' mechanism.. where WA1 creates a token associated with every session and makes it available to every url to WA2 from any page served from WA1. WA2 would first inspect the token, and see if it is a valid token (many ways to do this: A: make a web-service call to WA1 to ask if token is a valid session token.. B: WA1 persists to DB or file system and WA2 seeks from there.. ), and if it is valid, then honor the request. The issue here would be to make sure that the token is invalidated when a session in WA1 expires.
I would like to know if this approach is good enough, or are there better ways to do this?
Thanks
M. Rather
By default, the servlet API uses a cookie, typically named jsessionid, to store a session ID in each browser. Then, the browser passes the cookie to the server with each request. As long as both instances of tomcat are within the same domain, they should both have access to that cookie. Unless I'm missing something, it's just a matter of testing for that cookie in the second application.
Update: Even if each instance of tomcat runs in a different domain, they can still share these cookies by calling the setDomain(String domainPattern) method of the Cookie class.
I just thought about writing a GWT app that just works as a client for a RESTful web service. The web service requires HTTP basic authentication for each call.
Since the client is not 'connected' with the server over a session, I have to remember the authentication credentials on the client side. I could do this within the GWT application, but with this, the client has to log in after every reload, which is not very beautiful. I also don't think it's a good idea to write this information to cookies, since everyone could read them.
So, who knows what I am looking for? :-)
Browsers save the username/password information for a given server/port/domain. So if the client has to login once (at least via the browser standard BASIC http dialog) it's preserved over the reloads.
I don't know if you can do that. Maybe forcing the user to navigate to a page inside the domain (or realm) and then using GWT...