We are integrating Form Runner/Builder into a project with a custom persistence layer.
Right now we have emptySessionPath="true" set to keep Orbeon and our Java app on the same session.
Orbeon is passing the jsessionid cookie in the persistence CRUD calls... except for the following instance....
User connects to our Java app and logs in, jsessionid cookie is set
User visits an existing form instance at /fr/OurApp/formtest/edit/3eb4ddcf03f2410084e5578adb1e2a7b (Session Cookie is present)
Persistence call is made to our custom persistence layer, but cookie is not forwarded
But, if the user was to first edit the form itself with a call to /fr/orbeon/builder/edit/f40efbe298204d16b6474fcdfea4c9fd which does pass the cookie to the persistence layer
At this point the user can go visit step 2 to complete the form instance and the cookie will persist. It seems that for some reason starting form builder is required to get the cookie to forward to the persistence layer when completing the form?
Any ideas on why the cookie isn't getting passed on step 2?
FYI this is on Orbeon 3.9 CE, also same behavior in 3.8. Using VMWare TC Server (Tomcat). Our java app is a Spring/Grails app.
I am wondering if this might be what's described in this bug (see in particular the comments). Basically, it doesn't seem like you can always reliably produce a JSESSIONID cookie. And as the bug says, we don't have a solution right now.
Do you think the bug corresponds to your case?
Related
I am running an MVC site along side Umbraco. The MVC site handles its own authentication completely separate to Umbraco, and ASP.NET Forms authentication for that matter. It sets a cookie and uses that internally to keep track of things.
Everything works fine for the most part, but if I am logged into my MVC site with the aforementioned cookie set, I try to login to the Umbraco admin section using the correct Umbraco credentials, it authenticates me and redirects me to the admin section but the WebAPI calls start to fail. The first is a call to: /umbraco/backoffice/UmbracoApi/UpdateCheck/GetCheck which returns a 417 Missing token null HTTP error response.
If I delete my custom cookie and refresh the page everything works fine.
I don't understand how my cookie can interfere with Umbraco's. It's not using ASP.NET Forms authentication or anything.
This error occurs because your request is not sending up the required angular CSRF headers + cookie. I'm not sure why this would be the case but it does seems strange if it is a fault of your custom cookie. Perhaps you can tell us some more information about your issue: Cookie name/value, steps to reproduce, specific version of Umbraco, hosting environment, etc....
Some info as to what is going on, the code that returns this error is here:
https://github.com/umbraco/Umbraco-CMS/blob/dev-v7/src/Umbraco.Web/WebApi/Filters/AngularAntiForgeryHelper.cs#L94
This is where the CSRF cookies are set:
https://github.com/umbraco/Umbraco-CMS/blob/dev-v7/src/Umbraco.Web/WebApi/Filters/SetAngularAntiForgeryTokensAttribute.cs
and this attribute is applied to two actions, one for login and one when we retrieve the current user data:
https://github.com/umbraco/Umbraco-CMS/blob/dev-v7/src/Umbraco.Web/Editors/AuthenticationController.cs#L103
https://github.com/umbraco/Umbraco-CMS/blob/dev-v7/src/Umbraco.Web/Editors/AuthenticationController.cs#L84
This is where the header is set in the JS:
https://github.com/umbraco/Umbraco-CMS/blob/5b9a98ad6ae9e63322c26f7b162204e34f7fcb54/src/Umbraco.Web.UI.Client/src/init.js#L11
Depending on your hosting environment/setup there has been strange reports of some firewalls stripping/changing data, for example:
http://our.umbraco.org/forum/umbraco-7/using-umbraco-7/47340-Umbraco-7-plus-ISA-Server-2006
Hopefully given the info above you might be able to pinpoint where the problem starts.
My initial thought is that you by accident used a key value for your cookie that is reserved by Umbraco, which could result in the wrong cookie being read, causing issues. The solution to this would be to simply rename your cookie.
If this is not the case I have another theory:
HTTP requests will always include all cookies which path/domain matches the domain of the resource you are requesting. They are sorted by path length primarily, and secondarily by creation time. If Umbraco backend for some reason finds the cookie used for authentication by its index number (wouldn't even be surprised) in the list, rather than key value, your custom cookie would cause the index to shift, thus making Umbraco look at the wrong cookie
So, if renaming the cookie didn't do anything, a fun thing to try could be to set path of the cookie to the shortest possible path, which would make your browser put the cookie further down the list, so the index won't shift.
It's just a theory though, so I'm interested in hearing how it goes :)
Orbeon is integrated into another webapp. oxf.http.state is set to none.
When loading a form in form runner, external session cookies are not forwarded to the persistence. Despite that oxf.http.forward-headers and oxf.http.forward-cookies are set to according values.
When loading a simple form which isn't rendered by form runner the cookies are nicely forwarded with the requests in preprocessing step to the same server.
And after loading a simple form and forwarding session cookie atleast once, all the request from form runner also contain that cookie till the session expires.
So the question is - is it possible to forward external session cookies to the same server from form runner to custom persistence layer?
Or the only way is to make a dummy request each time to add the cookie to the http client?
As mentioned in a comment, this looks similar to issue #1070, that was marked fixed for 4.3, as the problem wasn't happening with that version. So I recommend you upgrade to 4.3.
If the problem persists with the latest version, I'd recommend you update your question with specific steps we can follow to reproduce this.
We have a JSF2.1.7 application ,our IT security found an issue as below
In Browser:
1) Get login Page.
2) Post Login Page with UserName/Password & submit&JSFViewStateId_1&JSessionID_1
3)Successful login.
Within minutes , if we make the same http request as below with old ViewState and new JSession.
1) Post Login page with UserName/Password & submit&JSFViewStateId_1&JSessionID_2
2) Successful Login
Wondering ,how the old view state is accepted by the server ,when the second request is made ,should it not report view expired?
Does the server validate the ViewSTate and JSession ID as the combined authentication.
That's only possible if the javax.faces.STATE_SAVING_METHOD is set to client. The javax.faces.ViewState does then not represent the unique view state identifier referencing a view state which is stored in the user session, but it represents instead the whole view state itself, in serialized flavor. The session ID is then not relevant anymore.
The webapp being tested has apparently client side state saving enabled. Whether that's a security problem is a second. It would only be possible to extract and send the view state to a malicious server when there's a XSS hole. JSF has by itself very strong builtin XSS prevention which the developer can only disable by explicitly using escape="false" while redisplaying user-controlled data. Even if there was a XSS hole, then it would also be possible to send the session ID along. It wouldn't have been more secure with server side state saving.
I am using Spring Security 3.0.5 and Camel 1.5 (yes, very old but we don't have time to update right now).
In this particular scenario I am uploading a file which hits a Spring Controller which then redirects the request body (which is XML) to an endpoint which is a method in another class. Here is the issue: I had a tester perform an upload but when the GUI listing of files came back it had another person's name as the person who uploaded the file. During debugging I found that in the first Spring Controller the SecurityContext is correct in that it is indeed the credentials for the person performing the upload. After the Camel redirect though the SecurityContext was for another user who happened to have a session in the web app. Obviously this is not good.
So two questions:
Does anybody know what to do or if there is anything I can do using Camel 1.5 to fix this issue?
Why would the credentials of another user from another session be in this session? This question is regardless of Camel.
What http are you using? Can you check if there is a single thread only processing the request at all time, or is multiple threads involved?
And btw Camel 1.5 is EOL, and not support at all anymore.
I'm using symfony 1.4 and it appears that every time a user is authenticated symfony recreates a session for the user. For example, if I visit a site and am not logged in I have a different session id then if I log in I have a new one, then when I log out I have yet another new one. This wasn't so in symfony 1.0 and I am wondering if this is how it's supposed to be?
I just checked 1.0's source code, it did not exist there.
Versions 1.1 and above regenerate the session ID every time the authentication is changed, or a credential is added/removed.
This is a very good security measure, prevents session fixation attacks.
Here's a link to the relevant changeset in trac.
This is a correct behavior. It's rather related to PHP sessions than how symfony handles them. I don't think it used to be different in symfony 1.0.
Session id should be unique and hard to guess. If you would always get the same session id than someone who once sniffed it could use it every time he wants (store it in a cookie and use website with your credentials).