losing jsessionID when making cfhttp call?

Report · Sep 10, 2012

For years, I've used <cfhttp url="http://myserver.com/myFile.cfm?#session.urlToken#"> to do screengrabs and use the currently-logged-in user's session scope. This has not been a problem under CF8/IIS6 environment. I've recently moved the application to a CF10/IIS7 environment and it does not like this call. The entire application is managed by cflogin, so it just returns my login screen. After doing some digging, I can tell that the jsessionID the cfhttp response header contains is not the same jsessionID I am sending via the url. Of course, this causes the server to think it's a new session and return the login screen.

I know setting this up with SSL is a pain and I've wrestled with it a lot in the past, but this setup is strictly http over port 80.

Things I've tried:

* uncheck "Use UUID for cftoken" in cf admin

* uncheck "Enable Global Script Protection"

* parsed the session.urlToken variable to send each variable (CFID, CFTOKEN, JSESSIONID) as a url/cookie via cfhttpparam

* turned off "HTTPOnly" for session cookies

I've even looked at the resulting #session.urltoken# variable and tried to hijack the session from another machine - no dice. It still just returns the login screen. On my CF8 box, I can hijack the session with this information.

Any clues as to things to try? My hunch is that it is a security thing and I thought for sure unchecking "Enable Global Script Protection" would solve it, but it did not. I know the jsessionid format is a little different with CF10 (CF9?) as it is "XXXXXXXX.cfusion". I thought the ".cfusion" might have been causing confusion somewhere in the setup - IIS thinking it was a file type and denying it via request filtering? But, that wasn't the case either.

Any help is greatly appreciated.

Report · Sep 10, 2012

When you say: "parsed the session.urlToken variable to send each variable (CFID, CFTOKEN, JSESSIONID) as a url/cookie via cfhttpparam"

Do you mean that you tried sending the values using <cfhttpparam type="cookie" name="JSESSIONID" value="#SESSION.jsessionid#" />?

jason

Report · Sep 11, 2012

Yes, that's basically what I mean. I took the session.urltoken, which is in the format of "CFID=XXX&CFTOKEN=YYY&JSESSIONID=ZZZ" and broke it down into individual variables so I could send each of the three as <cfhttpparam> parameters. I tried sending them as type="cookie" and type="url".

Report · Sep 11, 2012

You know that the variables are already broken down in the session for you, right? No need to use session.urltoken.

Are you sending the requests to a server where the sessions already exist (the server you are making the request from)? Or are you sending the request to a different server?

jason

Report · Sep 11, 2012

I see there is a session.sessionID that contains the jsessionID value, but I don't see a session.cfid or session.cftoken when I dump the session scope. No biggie either way. I have verified the parsing is getting done correctly.

Yes, the <cfhttp> url parameter is pointing at the same server the code is residing on. Ultimately, it's to generate a PDF display of the requested screen - basically wrapping the cfhttp.filecontents in a <cfdocument> tag, but all of that is beyond the scope of this problem. The cfhttp.filecontents variable contains the html for the login screen.

I just sent:

When I dump the cfhttp structure, the response header shows a "Set-Cookie" property of "JSESSIONID=8A823...; Path=/; HttpOnly"

I appreciate your effort on this, BTW. This is not in my actual production environment, but one that I've setup to mimick it. I'm going to move it later today and hope it goes away in the new environment. The production environment is a fresh install, whereas my test environment has been used and abused.

Report · Sep 11, 2012

Forgot to ask one other thing. Are you sending the request to the same domain? Same Application?

Some updates were made to CF8, CF9, and CF10 (CF8 and 9 updates were security hotfixes) that broke some insecure functionality that many people used to create sessions that didn't previously exist. That is what I suspect is going on.

I would expect the sessions to work more reliably as cookies. You should be sending them as cfhttpparams of type COOKIE.

Here is what I would expect to work.

</cfhttp>

The reason that CFID and CFTOKEN are not showing up in your session scope is because you are using JEE sessions and you do not need them. DOn't waste any time parsing them out and sending them too. JSESSIONID is all you need. The only reason CF still generates them and includes them in the URL token is because they would be needed if you were using the client scope. But nobody uses the client scope anymore, right

Jason

Report · Sep 11, 2012

Yes - sorry, I should have been clear about that from the start.

The code resides at \\myserver.domain.com\wwwroot\file1.cfm and it uses cfhttp to call to http://myserver.domain.com/file2.cfm?#session.urlToken#.

I have made a breakthrough this morning. I've never used this, so it may be a major no-no. I have passed the session.cfauthorization_[applicationname] as a cookie via cfhttpparam. This "works" in a sense. It gets me past the login screen, but clearly the cfhttp brower doesn't share the same session scope as the user's browser that is running file1.cfm. The cfhttp.filecontents contains an error screen saying it can't locate a particular session variable. That code should have been looking for the variable in the arguments scope anyway, so I fixed that and all is well.

When I pass the cfauthorization variable, it doesn't seem to matter if I pass the jsessionid or not.

Thanks again for your help!

Report · Dec 19, 2012

I'm still struggling with this. I upgraded another server from CF8 to CF10 and I can't pass the session scope over my cfhttp call. This application does not use cflogin, so my cfauthorization workaround doesn't help.

For 5+ years, it has worked fine using <cfhttp url="http://www.myserver.com/myfile.cfm?#session.urltoken#"> The cfhttp.filecontents variable would contain the results of "myfile.cfm" as run by the logged-in user. This has worked for CF7, CF8 and CF9. When I upgraded to CF10, it broke.

I have a simple cfhttp example running on both CF8 and CF10 boxes. CF8 works, CF10 does not. I've gone over all of the cfadmin settings many times trying to spot any differences.

http://www.myserver.com/file1.cfm:

-----------------------------------------------------------

<cfoutput>#session.sessionID#</cfoutput>

</cfhttp>

<cfoutput>#cfhttp.filecontent#</cfoutput>

-----------------------------------------------------------

http://www.myserver.com/file2.cfm:

-----------------------------------------------------------

<cfoutput>#session.sessionID#</cfoutput>

-----------------------------------------------------------

On my CF8 server, the session.sessionID variables match. On my CF10 server, they do not. I've tried every iteration I can think of - passing the token(s) directly through the URL (as I have always done), passing cfid/cftoken/jsessionID/sessionID as a individual <cfhttpparam> params (type="cookie", type="url", type="header").

If I turn off J2EE session variables, the CFID/CFTOKEN information will persist across the call. But, I don't want to redesign the app because I can't get J2EE session variables working. As I said, it's been working fine for 5+ years in CF7/8/9. I can run the exact code in 2 environments, the only difference is CF versions. I know it can't be that this is a bug in CF10, otherwise it would be all over google and likely patched by now. I have updated the CF10 server to hotfix 6. But, I'm at my wit's end about why this isn't working. This makes 2 separate machines I've installed CF10 on (both fresh installs) and both have failed to pass the J2EE session variables.

Any help is GREATLY appreciated...

Report · Dec 19, 2012

Sorry, I don't have CF10 installed right now to test any of this. But the one thing I do see that doesn't seem right (though you claim it works in CF8) is this:

Shouldn't the name be equal to "jsessionid" not "sessionid"?

I will see about installing CF10 and trying this out.

Jason

Report · Dec 19, 2012

Guess i won't be doing it tonight. The download site is down.

Jason

Report · Dec 20, 2012

I can't say for sure that session.sessionID worked. I've tried a million different iterations of session.sessionID, session.jsessionID, cookie.sessionID, cookie.jessionID, etc. I know url=http://myserver/myfile.cfm?#session.urltoken# worked in CF8.

I have stumbled across a thread that makes sense - http://stackoverflow.com/questions/8934498/coldfusion-session-fixation

It claims that, as of CF 9.0.2, CF no longer allows you to do this by default. That makes sense in that I know it works up through 9.0, but I never tried any other 9x version. It also claims you can supply an argument to the jvm startup command to allow it. I was unable to make it work in limited testing yesterday evening, but I'll play with it some more today.

Thanks for the help!

Report · Dec 20, 2012

@Ericbegins

There is one good reason why all those familiar session hacks you attempted don't work anymore on CF 10. It also happens to be the reason why sending session tokens is futile. Namely, ColdFusion's session apparatus has been completely revamped in CF 10.

One consequence is that, if a user attempts to make a new request in the context of a new client, for example, a new browser request, the ColdFusion server simultaneously invalidates the existing session and creates a new one. This is relevant to you because cfhttp is essentially a browser.

In any case, I find it unnecessary to send session tokens by cfhttp, as you have done. Especially, given that the http client and server are one and the same! I would just do

and send no session parameters, nothing.

Report · Dec 20, 2012

I do not think this is a session fixation issue (I am the one who reported the session fixation vulnerability). Session fixation vulnerabilities occur when you can force a non-existent session token on a server.

For example, in versions of CF without session fixation protection I can pass http://domain.index.cfm?cfid=1&cftoken=2 to the CF server. If the session matching those tokens does nto exist, CF will create the session with those tokens and continue working.

There are two things that tell me this is not a session fixation protection issue:

1. The fixation issue never occured with JEE tokens

2. The sessions you are working *do* exist on the server in the same application.

Jason

Report · Dec 20, 2012

Ignore any emails you just got, I am reporting my response soon

Report · Dec 20, 2012

Yes, I did notice that. I should have probably mentioned that at some point. That was initially breaking my myfile.cfm?#session.urlToken# solution because it didn't like the period in the url. Even wrapping it in #urlencodedFormat()# didn't help. However, I could send the variable via <cfhttpparam type="url" name="jsessionID" variable="#cookie.jsessionID#">. It didn't error out, it just didn't work.

Report · Dec 20, 2012

God damn you Adobe forums. You just hosed up 15 minutes of typing.

Starting over:

After 10 minutes of researching this (so please take it with a grain of salt) I found something unique with CF10 and JEE tokens and that is the dot in the session token. This dot is getting encoded when you try to pass it as a cookie. I found that the following allowed me to persist the session.

Note that I also foudn that Tomcat (which is handling the JEE sessions) is case sensitive as well. So the JSESSIONID cookie you pass MUST be in uppercase letters.

I was NOT able to get the session to persist by passing the token on the URL. Regardless of encoding. This may be a bug in CF10. If it is the session fixation causing it, then using the JVM argument combined with using uppercase JSESSIONID should resolve that.

Hope this helps,

Jason

Report · Dec 20, 2012

Reading back to the beginning of this thread and looking at the bug report that BKBK referenced I see that this concerns CFLogin. Please not I did not test this using CFLogin, I tested it using regular old CFSessions. If somethign in CFLogin has changed then it would not be reflected here, but I do NOT believe that cfsessions have been completely revamped, though it is possible that something in CFLogin has changed that may cause different issues.

Jason

Report · Dec 20, 2012

SWEET MERCIFUL CRAP - YOU'RE A GENIUS!!!! encoded=false worked!

Thanks a ton for your help on this! You are a gentleman and a scholar.

Report · Dec 20, 2012

BKBK,

Can you cite that change? I have not heard of that change. You're saying that CF10 is actually doing browser detection to protect against session hijacking?

Jason

Report · Dec 20, 2012

12Robots wrote:
BKBK,
Can you cite that change? I have not heard of that change. You're saying that CF10 is actually doing browser detection to protect against session hijacking?

I wouldn't yet call it a change in the sense of a new feature. It is more a consequence of the new session apparatus in CF 10.

In fact, it has been reported as a bug. I have just been searching the forum to find a thread that discussed a problem similar to this, in which you and I both participated.

Report · Dec 20, 2012

I'm not sure I follow. Are you saying that, if myfile.cfm needed access to, say, the user's session.username variable, that it should be able to access it by default? Or that there's no way to access it?

The main way I utilize this is to produce printouts/pdfs of a screen. If the user presses the Print button, I do a <cfhttp> to the screen in question, return the results and wrap the cfhttp.filecontents in a <cfdocument> tag. If I don't somehow pass the user's information, the cfhttp call is just going to return the login screen since it sees the request as a new user/browser request.

losing jsessionID when making cfhttp call?

1 Correct answer