I'm working on an OS X app where the user can connect to its accounts on different external services (in OAuth).
To do so, I need to open a page of my API (a Rails app) in a Webview, which will redirect the user to the service to connect. At the end of the process, the user will be redirected again on my API, which will tell him if the connection has worked fine or not.
Therefore, the user needs to be authenticated on my API, both before and after the OAuth process on the external service website.
When I open the Webview, the user is authenticated thanks to an access token as a parameter of the url, and the redirection to the external service works fine.
But very often, when the user is redirected on my API after the connection, he is not authenticated anymore (but sometimes it works).
When I check the existing cookies for my app through
[[NSHTTPCookieStorage sharedHTTPCookieStorage] cookiesForURL:]
I do have a session cookie for my API:
<NSHTTPCookie version:0 name:"_..._api_session" value:... expiresDate:(null) created:2014-02-12 19:16:00 +0000 (4.13925e+08) sessionOnly:TRUE domain:... path:"/" isSecure:FALSE>
It just doesn't seem to be sufficient to keep the user authenticated.
Where this can come from?
It somehow seems to be related to the Webview, because when I do this whole process by sending the user to an external browser, it works fine.
Does the Webview have a specific way to handle session cookies?
I don't know if I'm being specific enough, please ask if you want other details.
I finally found out what the problem was.
My app communicates with my API through a permanent sync process, and needs to be authenticated with an access_token. I use AFNetworking for that, which creates a session cookie in the app container.
When I authenticate again in the Webview, it also creates a cookie session. Somehow, the cookies are in conflict and break the session.
I just told AFNetworking not to use cookies to avoid that, and it worked.
Related
Using the OktaSignIn widget, I see I can get res.session.token. Can I use this (or some other attribute) in another app -- with the APIKey -- and validate that this is a valid session?
We just want a simple to use auth system and don't want to set up OpenAuth...
Can't seem to find any APIs that do what I need.. but could have missed it of course...
Edit. Basically... our front end uses the OktaSignInWidget... then we want to use this in a Bearer token our API Services layer can validate.
Thanks!
Looks like this will work...
/api/v1/sessions/me
Get id from this.
{"id":"102wtHeHhr4Q4q4rh2Fjy6pGA","userId":"00u9uwkfyfiz3Y7uk0h7",
Then... this can be passed and using the API key...Issue a GET to...
/api/v1/sessions/102wtHeHhr4Q4q4rh2Fjy6pGA
Returns...
Session...
The call to /api/v1/sessions requires the API key -- which is fine.
As you mentioned, you can use the session id to see if the session is still valid on the Okta server by:
Exchanging sessionToken for okta session
After redirecting back to your app, calling /api/v1/sessions/me to get the sessionId
Using that sessionId in the request to /api/v1/sessions/id with an apiToken to see if it's still valid
This will exist as long as the user has not logged out of Okta, but the browser state might be different - for example, the Okta session cookie will normally be deleted when the user's browser closes, while the session might still exist on the server.
Alternatively, to check if the browser session still exists, you could make the validation check on the client side by making the request to /api/v1/sessions/me - the one gotcha is to make sure that CORS is enabled for both the domains your apps are running on so they have permissions to make this request to Okta.
The above methods work, but it does sound like what you should be looking into is Okta's API Access Management (OAuth2) - it was designed for this type of flow (passing Bearer tokens to your API services layer).
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 are building a SPA application using Durandal and we are authenticating the users via Windows ACS in Windows Azure.
We currently have a problem with users who leaves their applications open for a long time. When they come back, the ACS token is expired and the application won't redirect to the ACS login (since it is a SPA application).
Is there a good way to detect on the client side when the Windows ACS session times out?
I don't know Durandal, but I know all Ajax calls feature (optional) error handlers in which you can test whether the server status code is 401 or 403.
(that's usually the case when the user tries to access a secure resource when he is not authenticated).
All you have to do is redirect the user to ACS with the correct parameters when this happens.
I'm maintaining a system built in ASP.
The login process is in SSL. Meaning, when the user clicks on "Login", his user name and password are sent securely to the server.
The login process produces a Session object, which is the ID of the now logged-in user.
After finishing the login process, the page redirects the browser to a non secure page. This page tries to access the ID Session object.
Until last week, this worked fine. Our system was running on IIS6.0, and the non-secure page could access this Secure ID Session object.
However, after switching over to IIS7.5, this inevitable security hole was closed(or so I assume). The non-secure page cannot access the Secure ID Session object anymore.
Access to the object is done simply like this:
string ID = Session(SESSION_USER_ID)
just to check things out, I tried access a non-secure Session object from the Secure login pages - this failed as well.
Is there any way to access a Secure Session object from a non-secure page?
BTW, I've probably mistaken with some of the terms here, but I think the scenario is more or less clear. Please tell me if this is not the case.
I've come across this problem before, I ended up getting around it by, when changing into or out of SSL, calling a function that would write the session variables to cookies, and then read back from the cookies into the SSL session variables.
Using Forms Authentication in ASP.Net MVC 3, it appears that the login cookie is cross-browser. When a user logs in in IE and then opens the site in Chrome, for example, they are already logged in. When they logout in Chrome and then refresh the page in IE, they have been logged out there as well.
Is this correct or am I moy loco?
How does this work? I didn't think browsers used a common cache for cookies.
They don't share cookies. Something else is going on. The logout can be explained in the way the server handles logouts though. If your server has a single cookie that is then invalidated all logins across all sessions will be invalidated making them all log in again.