We are working on an existing application where web services (tomcat) as well as UI (nginx) applications are hosted on separate containers. One of the service application is used for sending login request (SAML request) to identity provider (ping). Here are the steps for user login to the system:
User loads the application (domain URL: https://ui.domain.com), it loads the UI where it checks for logged in user (JWT token string generated for user/role) on local storage and when not found, it redirects to ping (IDP) for authentication.
Once authenticated with ping, it calls the spring controller which is configured for the success URL on service application (https://api.domain.com/auth-service/auth).
This controller service (/auth), gets the SAML response sent by ping and processes it further to get user details and generates the JWT token for the user and redirects the user to UI (https://ui.domain.com).
Problem Statement:
To pass the token to UI, the JWT token string is added to URL by using
redirectAttributes.addAttribute(“auth-token”, token);
With the above, it shows up in the address bar like: https://ui.domain.com/?auth-token=
This has raised a concern with respect to security as the token is displayed on address bar and exposed which can be decoded to get user information.
Current Approach (tried):
Before redirection from controller to UI, tried to set cookie
Cookie cookie = new Cookie(“auth-token”, token);
cookie.setMaxAge(-1);
cookie.setPath(“https://ui.domain.com”);
response.addCookie(cookie);
However we couldn’t find the cookie from UI.
We tried to set it to response header too.
response.addHeader(“auth-token”, token);
Since it is a redirection, the adding to response doesn’t help.
Further trials:
We are also putting a thought about changing the approach of authentication controls where after ping authentication is done, the success URL can be replaced with UI url rather than service URL, i.e.
Current: saml.sso.default-success-url= https://api.domain.com/auth-service/auth
Proposed: saml.sso.default-success-url= https://ui.domain.com/
With the above, the SAML response supposed to go directly to UI (after ping authentication is successful).
However we couldn’t get the response in UI and it also behaves like ping is doing a redirection to UI and due to the same reason, UI doesn’t get it.
Any ideas and suggestions over this would be great.
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 have a grails server and an iOS client that communicate over HTTPS via POST messages. I'm using PersistentTokenBasedRememberMeServices to ensure that the user doesn't have to enter his password all the time. This doesn't seem to work as the session is lost continuously and the user has to login again. The server logs show that a CookieTheftException has occurred with message "Invalid remember-me token (Series/token) mismatch".
Not all server actions require a logged in user. Some can be accessed anonymously and this may be the root of the problem. When the user accesses restricted server actions, the session is maintained, but not when accessing unrestricted actions.
Here's my config in Config.groovy:
grails.plugins.springsecurity.rememberMe.cookieName = 'SomeRememberMeName'
grails.plugins.springsecurity.rememberMe.persistent = true
grails.plugins.springsecurity.rememberMe.alwaysRemember = true
grails.plugins.springsecurity.rememberMe.persistentToken.domainClassName = 'com.myapp.PersistentLogin'
grails.plugins.springsecurity.rememberMe.tokenValiditySeconds=31*24*60*60
I added some traces in the iOS client and noticed a couple of things. First of all the JSESSIONID cookie doesn't have an expiration time, which means it isn't saved in the client like the rememberMe cookie. Can I force it to have an expiration time or is that even a good idea? Secondly I noticed that sometimes the rememberMe cookie that I receive from the server is empty. That may be just because a CookieTheftException was thrown.
Since all of the post message bodies are encrypted with 256-bit AES, I'm not really worried about cookie theft at this time. I just need to get this to work.
I tried adding the following to my config to ensure that the session would be always updated even when accessing unrestricted actions:
grails.plugins.springsecurity.useSessionFixationPrevention = true
grails.plugins.springsecurity.SessionFixationPrevention.migrate = true
grails.plugins.springsecurity.SessionFixationPrevention.alwaysCreateSession = true
I don't even know what these all mean. I just liked the "alwaysCreateSession" part and figured that I need to enable session fixation prevention in order for that setting to have any effect. Will it still always create a session if I set useSessionFixationPrevention to false?
Any help is appreciated.
If you are using PersistentTokenBasedRememberMeServices, your "remember me" token will change after every HTTP request.
Unfortunately that means that requests will only authenticate if your browser makes exactly one request at a time, and browsers often don't do that. If there are 4 few images on a page, the browser will send out 4 simultaneous requests, each with the same "remember me" token. Only the first request will authenticate, because after Spring Security processes the first request, it changes the token. When Spring Security tries to process the next request, it throws a CookieTheftException.
That's the typical scenerio for the CookieTheftException when using PersistentTokenBasedRememberMeServices.
Here's a link that explains some things you can do about it: Grails Cookie Theft Exceptions
There's also an open issue with the Grails Spring Security Core plugin that discusses this problem: Remember me functionality fails intermittently with CookieTheftException: Invalid remember-me token
The JSESSIONID stuff is probably a red herring. If you're using PersistentTokenBasedRememberMeServices, your authentication won't need a session.
I'm trying to access a REST service via a server-to-server GET request that is secured by OpenSSO/Spring Security and am unable to. It's like my Spring Rest Template client is not stateful to hold the cookies it should as I get redirected through the authentication workflow.
When doing this with a browser, the initial request is redirected to OpenSSO, I'm challenged for my cert (PKI), I present it, get a response with my authentication cookie header. Then I am redirected back to my original destination, I present my auth cookie in the request header and I'm on my way.
This isn't happening in my server-to-server invocations.
I've searched for quite a while now and can't seem to find any solutions that hold onto this state across redirects!
Following the link in zagyi's comment may have worked, but I spent some more time and found the following solution, which does not involve overriding anything:
To handle the authentication cookie in the REST controller, you have to explicitly tell it to accept cookies. Before handling the call, add the following line of code:
CookieHandler.setDefault(new cookieManager(null, CookiePolicy.ACCEPT_ALL));
I've been reading up on REST and there are a lot of questions on SO about it, as well as on a lot of other sites and blogs. Though I've never seen this specific question asked...for some reason, I can't wrap my mind around this concept...
If I'm building a RESTful API, and I want to secure it, one of the methods I've seen is to use a security token. When I've used other APIs, there's been a token and a shared secret...makes sense. What I don't understand is, requests to a rest service operation are being made through javascript (XHR/Ajax), what is to prevent someone from sniffing that out with something simple like FireBug (or "view source" in the browser) and copying the API key, and then impersonating that person using the key and secret?
We're exposing an API that partners can only use on domains that they have registered with us. Its content is partly public (but preferably only to be shown on the domains we know), but is mostly private to our users. So:
To determine what is shown, our user must be logged in with us, but this is handled separately.
To determine where the data is shown, a public API key is used to limit access to domains we know, and above all to ensure the private user data is not vulnerable to CSRF.
This API key is indeed visible to anyone, we do not authenticate our partner in any other way, and we don't need REFERER. Still, it is secure:
When our get-csrf-token.js?apiKey=abc123 is requested:
Look up the key abc123 in the database and get a list of valid domains for that key.
Look for the CSRF validation cookie. If it does not exist, generate a secure random value and put it in a HTTP-only session cookie. If the cookie did exist, get the existing random value.
Create a CSRF token from the API key and the random value from the cookie, and sign it. (Rather than keeping a list of tokens on the server, we're signing the values. Both values will be readable in the signed token, that's fine.)
Set the response to not be cached, add the cookie, and return a script like:
var apiConfig = apiConfig || {};
if(document.domain === 'example.com'
|| document.domain === 'www.example.com') {
apiConfig.csrfToken = 'API key, random value, signature';
// Invoke a callback if the partner wants us to
if(typeof apiConfig.fnInit !== 'undefined') {
apiConfig.fnInit();
}
} else {
alert('This site is not authorised for this API key.');
}
Notes:
The above does not prevent a server side script from faking a request, but only ensures that the domain matches if requested by a browser.
The same origin policy for JavaScript ensures that a browser cannot use XHR (Ajax) to load and then inspect the JavaScript source. Instead, a regular browser can only load it using <script src="https://our-api.com/get-csrf-token.js?apiKey=abc123"> (or a dynamic equivalent), and will then run the code. Of course, your server should not support Cross-Origin Resource Sharing nor JSONP for the generated JavaScript.
A browser script can change the value of document.domain before loading the above script. But the same origin policy only allows for shortening the domain by removing prefixes, like rewriting subdomain.example.com to just example.com, or myblog.wordpress.com to wordpress.com, or in some browsers even bbc.co.uk to co.uk.
If the JavaScript file is fetched using some server side script then the server will also get the cookie. However, a third party server cannot make a user’s browser associate that cookie to our domain. Hence, a CSRF token and validation cookie that have been fetched using a server side script, can only be used by subsequent server side calls, not in a browser. However, such server side calls will never include the user cookie, and hence can only fetch public data. This is the same data a server side script could scrape from the partner's website directly.
When a user logs in, set some user cookie in whatever way you like. (The user might already have logged in before the JavaScript was requested.)
All subsequent API requests to the server (including GET and JSONP requests) must include the CSRF token, the CSRF validation cookie, and (if logged on) the user cookie. The server can now determine if the request is to be trusted:
The presence of a valid CSRF token ensures the JavaScript was loaded from the expected domain, if loaded by a browser.
The presence of the CSRF token without the validation cookie indicates forgery.
The presence of both the CSRF token and the CSRF validation cookie does not ensure anything: this could either be a forged server side request, or a valid request from a browser. (It could not be a request from a browser made from an unsupported domain.)
The presence of the user cookie ensures the user is logged on, but does not ensure the user is a member of the given partner, nor that the user is viewing the correct website.
The presence of the user cookie without the CSRF validation cookie indicates forgery.
The presence of the user cookie ensures the current request is made through a browser. (Assuming a user would not enter their credentials on an unknown website, and assuming we don’t care about users using their own credentials to make some server side request.) If we also have the CSRF validation cookie, then that CSRF validation cookie was also received using a browser. Next, if we also have a CSRF token with a valid signature, and the random number in the CSRF validation cookie matches the one in that CSRF token, then the JavaScript for that token was also received during that very same earlier request during which the CSRF cookie was set, hence also using a browser. This then also implies the above JavaScript code was executed before the token was set, and that at that time the domain was valid for the given API key.
So: the server can now safely use the API key from the signed token.
If at any point the server does not trust the request, then a 403 Forbidden is returned. The widget can respond to that by showing a warning to the user.
It's not required to sign the CSRF validation cookie, as we're comparing it to the signed CSRF token. Not signing the cookie makes each HTTP request shorter, and the server validation a bit faster.
The generated CSRF token is valid indefinitely, but only in combination with the validation cookie, so effectively until the browser is closed.
We could limit the lifetime of the token's signature. We could delete the CSRF validation cookie when the user logs out, to meet the OWASP recommendation. And to not share the per-user random number between multiple partners, one could add the API key to the cookie name. But even then one cannot easily refresh the CSRF validation cookie when a new token is requested, as users might be browsing the same site in multiple windows, sharing a single cookie (which, when refreshing, would be updated in all windows, after which the JavaScript token in the other windows would no longer match that single cookie).
For those who use OAuth, see also OAuth and Client-Side Widgets, from which I got the JavaScript idea. For server side use of the API, in which we cannot rely on the JavaScript code to limit the domain, we're using secret keys instead of the public API keys.
api secret is not passed explicitly, secret is used to generate a sign of current request, at the server side, the server generate the sign following the same process, if the two sign matches, then the request is authenticated successfully -- so only the sign is passed through the request, not the secret.
This question has an accepted answer but just to clarify, shared secret authentication works like this:
Client has public key, this can be shared with anyone, doesn't
matter, so you can embed it in javascript. This is used to identify the user on the server.
Server has secret key and this secret MUST be protected. Therefore,
shared key authentication requires that you can protect your secret
key. So a public javascript client that connects directly to another
service is not possible because you need a server middleman to
protect the secret.
Server signs request using some algorithm that includes the secret
key (the secret key is sort of like a salt) and preferably a timestamp then sends the request to the service. The timestamp is to prevent "replay" attacks. A signature of a request is only valid for around n seconds. You can check that on the server by getting the timestamp header that should contain the value of the timestamp that was included in the signature. If that timestamp is expired, the request fails.
The service gets the request which contains not only the signature
but also all the fields that were signed in plain text.
The service then signs the request in the same way using the shared
secret key and compares the signatures.
I will try to answer the the question in it's original context. So question is "Is the secret (API) key safe to be placed with in JavaScript.
In my opinion it is very unsafe as it defeats the purpose of authentication between the systems. Since the key will be exposed to the user, user may retrieve information he/she is not authorized to. Because in a typical rest communication authentication is only based on the API Key.
A solution in my opinion is that the JavaScript call essentially pass the request to an internal server component who is responsible from making a rest call. The internal server component let's say a Servlet will read the API key from a secured source such as permission based file system, insert into the HTTP header and make the external rest call.
I hope this helps.
I supose you mean session key not API key. That problem is inherited from the http protocol and known as Session hijacking. The normal "workaround" is, as on any web site, to change to https.
To run the REST service secure you must enable https, and probably client authentification. But after all, this is beyond the REST idea. REST never talks about security.
What you want to do on the server side is generate an expiring session id that is sent back to the client on login or signup.
The client can then use that session id as a shared secret to sign subsequent requests.
The session id is only passed once and this MUST be over SSL.
See example here
Use a nonce and timestamp when signing the request to prevent session hijacking.