I am facing a peculiar problem. The problem is, my webapp is being installed behind a proxy. The request gets submitted to the proxy which forwards the request to the original host that is running the websphere web application.
The problem I am facing is, when I access the webapp, its URL looks like the below
http://www.myproxy.com
Lets say I get a form on this URL, when I submit the form, it is getting submitted to another URL - http://10.1.2.87
Since the URL is changing, application server thinks it is a different session and throws the login page again. The login page comes thru a filter which checks whether user is already authenticated in the session or not.
I do not have much knowledge on proxy settings .. where do you think is the problem?
Thus, you're using a reverse proxy. You need to configure it to manage the sessions as well. To the point, it should send the HTTP Cookie and Set-Cookie headers forth and back as well. Consult the documentation of the proxy in question for details or ask at serverfault.com for detailed assistance (don't forget to mention which proxy you're using).
Related
I have very little experience with APIs which is something that I'm trying to change so I'm trying to get started with the Tumblr api. I've installed the tumblr_client gem (documentation here) and am following the instructions. I've created an application on a new Tumblr account and have the necessary OAuth information (consumer_key, consumer_secret, ect.) Actually getting it to do something is proving difficult, so like a good little programmer I'm trying to get the console going to explore a bit.
This requires a bit of setup, so I'm following the instructions here:
The first time that you go to use the irb console, if you have no
.tumblr file, it will walk you through the process of generating one.
You will be prompted for your consumer_key and consumer_secret (which
you can get here: http://www.tumblr.com/oauth/register) and then sent
out to the site to verify your account. Once you verify, you will be
redirected to your redirect URL (localhost by default) and copy the
oauth_verifier back into the console. Then you're all set!
I'm prompted for my key and secret, then I go to the URL where I'm supposed to give authorization. Tumblr gives me a popup which reads "Is it alright for this application to access some of your data and make posts to your account? You are logged in as example#example.com" and the options to cancel or allow. I hit allow and it just takes me into the account itself, at no point am I ever given any kind of verification code that I can put in to get the console working.
At this point I'm stuck and can't go any further so I'm activating the network. Any ideas as to where I'm going wrong?
Did you specify a redirect or callback url at any point in the oauth config process? It's probably done on tumblr's API website. This url would be your app's endpoint to which Tumblr sends a request to with the user's data. By the way, oauth can sometimes be confounding to set up. You won't be able to use localhost as a callback url, for example, though you can get a temporary domain name with a free local tunneling app.
edit To go into more detail on some of these points ...
callback url: To reiterate, this cannot be localhost. Setting the correct callback url will get you unstuck from your current predicament. Instead of redirecting to the tumblr homepage, you want the confirmation page to redirect to your app. Anyway, I think you're totally sensible to want to test it out before you deploy. But unless you deploy or use a local tunnel, your local application doesn't actually have a URL that can be reached from anywhere except your computer.
local tunnelling services: ngrok, localtunnel. To give an example with ngrok: Say you have a Rails server running on port 3000. Then in another terminal you run ngrok 3000 and you get a url which exposes your local server to the real internet. Note that this changes every time you restart ngrok (unless you pay them). In your application, you should make a unique route for the callback. Say you have a route which matches /oauth_callback to the oauth_callback controller action. Then the route you'd provide as your callback url would be http://MY_CUSTOM_NAME.ngrok.com/oauth_callback.
The controller action: I don't specifically know how Tumblr sends user data to the callback. Perhaps the information is in the headers or maybe it's in the body. It might be JSON or XML. Whatever it is, you can explore the data by placing a breakpoint in your controller action. You can inspect the params, headers, etc. I'd expect that they'd give you some token credentials and probably a user name/email as well.
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
I'm using basic authentication on my site, which does a simple windows popup asking for username and password. I'm wondering if there's a way to redirect http traffic to https traffic before this popup? Currently, i'm using a custom redirect error page, so when someone goes to http://www.mysite.com/ the popup comes up and asks for username password, and after they enter it the page redirects http traffic to https. But i'm assuming that password is sent in clear text, since the redirect is happening after the login attempt.
I've tried playing with IIS, and javascript on the page itself, but it seems the popup is happening before any of that comes into play. Is there anyway to redirect before that popup comes up?
Thanks!
I know this is old but here is how I managed to achieve this for anyone who would need the same.
Remove the HTTP bingind on the target domain's virtual server
Create a second virtual server for the same domain with only HTTP binding
Add a rewrite rule to the new virtual server that redirects all trafic to the HTTPS version of the domain
This is the only straight forward way i found and it is probably the simplest.
Voila!
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...
I am currently working on the authentication of an AJAX based site, and was wondering if anybody had any reccomendations on best practices for this sort of thing.
My original approach was a cookie based system. Essentially I set a cookie with an auth code, and every data access changed the cookie. As well, whenever there was a failed authentication, all sessions by that user were de-authenticated, to keep hijackers out. To hijack a session, somebody would have to leave themselves logged in, and a hacker would need to have the very last cookie update sent to spoof a session.
Unfortunatley, due to the nature of AJAX, when making multiple requests quickly, they might come back out of order, setting the cookie wrong, and breaking the session, so I need to reimplement.
My ideas were:
A decidedly less secure session based method
using SSL over the whole site (seems like overkill)
Using an iFrame which is ssl authenticated to do secure transactions (I just sorta assume this is possible, with a little bit of jquery hacking)
The issue is not the data being transferred, the only concern is that somebody might get control over an account that is not theirs.
A decidedly less secure session based method
Personally, I have not found using SSL for the entire site (or most of it) to be overkill. Maybe a while ago when speeds and feeds were slower. Now I wouldn't hesitate to put any part of a site under SSL.
If you've decided that using SSL for the entire site is acceptable, you might consider just using the old "Basic Authentication" where the server returns the 401 response which causes the browser to prompt for username/password. If your application can live with this type of login, is works great for AJAX and all other accesses to your site because the browser handles re-submitting requests with appropriate credentials (and it is safe if you use SSL, but only if you use SSL -- don't use Basic auth with plain http!).
SSL is a must, preventing transparent proxy connections that could be used by several users. Then I'd simply check the incoming ip address with the one that got authenticated.
Re-authenticate:
as soon as the ip address changes
on a time out bigger than n seconds without any request
individually on any important transaction
A common solution is to hash the user's session id and pass that in with every request to ensure the request is coming from a valid user (see this slideshow). This is reasonably secure from a CSRF perspective, but if someone was sniffing the data it could be intercepted. Depending on your needs, ssl is always going to be the most secure method.
What if you put a "generated" timestamp on each of the responses from the server and the AJAX application could always use the cookie with the latest timestamp.
Your best bet is using an SSL connection over a previously authenticated connection with something Apache and/or Tomcat. Form based authentication in either one, with a required SSL connection gives you a secure connection. The webapp can then provide security and identity for the session and the client side Ajax doesn't need to be concerned with security.
You might try reading the book Ajax Security,by Billy Hoffman and Bryan Sullivan. I found it changed my way of thinking about security. There are very specific suggestions for each phase of Ajax.