Forum Discussion
Multiple Secure and HttpOnly attributes seen for cookie
Hi,
I ran a curl command from a linux machine to a URL (on https) which is hosted on our BIG IP LTM. This virtual server has been set to add Secure, HttpOnly attributes to the cookie.
However, I see below response from BIG IP (in HTTP response) :
< Set-Cookie: JSESSIONID=3D7E79C494B64F4EB8D2D4FF862AFB0C; Path=/wcc-web/; Secure; HttpOnly; Secure; HttpOnly
< Set-Cookie: BIGipServerpl_wcc-pst.dhl.com_8443=1369786533.64288.0000; expires=Mon, 01-Feb-2016 07:56:08 GMT; path=/; Secure; HttpOnly
As seen above two Set-Cookie are seen and in Set-Cookie JESSIONID we could see Secure and HttpOnly twice.
Issue here is the end user is able to login to the URL in question successfully but after that the page redirects to the same page on entering the details and therefore its not working as expected. This application hosted on BIGIP LTM load balances two backend servers.
Application is working as expected when the user tests by accessing directly to the backend servers. I have a feeling that this issue is because of JESSIONID that is being sent by server in cookie but I may be wrong.
Please provide some pointers to troubleshoot this further.
Thanks,
Sai
20 Replies
- Hi Sai, please show us the iRule which is currently inserting the Secure and HttpOnly options... Cheers, Kai
- MSK_222682
Nimbostratus
Hi Kai, Below is the configured iRule: when HTTP_RESPONSE { set unsafe_cookie_headers [HTTP::header values "Set-Cookie"] HTTP::header remove "Set-Cookie" foreach set_cookie_header $unsafe_cookie_headers { HTTP::header insert "Set-Cookie" "${set_cookie_header}; Secure; HttpOnly" } } - Brad_Parker
Cirrus
Try using this iRule. It will not try to set secure or httponly if it is already set. What you are doing to manually changing the cookie payload without inspecting what is already there.
when HTTP_RESPONSE { foreach mycookie [HTTP::cookie names] { HTTP::cookie secure $mycookie enable HTTP::cookie httponly $mycookie enable } }- Brad_Parker
Cirrus
Apparently edit isn't working today. You probably also want to ensure your cookie is at least version 1 using this: when HTTP_RESPONSE { foreach mycookie [HTTP::cookie names] { HTTP::cookie version $myCookie 1 HTTP::cookie secure $mycookie enable HTTP::cookie httponly $mycookie enable } } - MSK_222682
Nimbostratus
Hi Brad, Thanks for the quick response. I shall update my iRule with above one and test again with the user. Also, do you think the presence of JSESSIONID in the server response cookie is causing the problem here ?? I'm of the impression that if server uses JESSIONID for maintaining persistence then we need a explicit iRule to support JESSIONID persistence and override the default persistence mechanism configured at pool level. Do let me know if my understanding is correct ? If so, I may have to create another iRule for this virtual server. Thanks, Sai - Brad_Parker
Cirrus
You don't necessarily have to persist on JESSIONID, but if you want to you can using universal persistence. https://support.f5.com/kb/en-us/solutions/public/7000/300/sol7392.html
- Brad_Parker_139
Nacreous
Try using this iRule. It will not try to set secure or httponly if it is already set. What you are doing to manually changing the cookie payload without inspecting what is already there.
when HTTP_RESPONSE { foreach mycookie [HTTP::cookie names] { HTTP::cookie secure $mycookie enable HTTP::cookie httponly $mycookie enable } }- Brad_Parker_139
Nacreous
Apparently edit isn't working today. You probably also want to ensure your cookie is at least version 1 using this: when HTTP_RESPONSE { foreach mycookie [HTTP::cookie names] { HTTP::cookie version $myCookie 1 HTTP::cookie secure $mycookie enable HTTP::cookie httponly $mycookie enable } } - MSK_222682
Nimbostratus
Hi Brad, Thanks for the quick response. I shall update my iRule with above one and test again with the user. Also, do you think the presence of JSESSIONID in the server response cookie is causing the problem here ?? I'm of the impression that if server uses JESSIONID for maintaining persistence then we need a explicit iRule to support JESSIONID persistence and override the default persistence mechanism configured at pool level. Do let me know if my understanding is correct ? If so, I may have to create another iRule for this virtual server. Thanks, Sai - Brad_Parker_139
Nacreous
You don't necessarily have to persist on JESSIONID, but if you want to you can using universal persistence. https://support.f5.com/kb/en-us/solutions/public/7000/300/sol7392.html
Hi Sai,
the problem is caused by those cookies, who already have the "; Secure" and/or "; HttpOnly" option set.
To flush any existing cookie options, you could use a
while substituting the new options...[substr ${set_cookie_header} 0 ";"]when HTTP_RESPONSE { set unsafe_cookie_headers [HTTP::header values "Set-Cookie"] HTTP::header remove "Set-Cookie" foreach set_cookie_header $unsafe_cookie_headers { HTTP::header insert "Set-Cookie" "[substr ${set_cookie_header} 0 ";"]; Secure; HttpOnly" } }Update: My update is still working... hehe^^ You should take a look to Brads approach. Although my iRule would work (in most cases), Brads approach is even more safe to use....
Cheers, Kai
Hi Sai,
this is the iRule i was refering to...
when HTTP_RESPONSE { foreach mycookie [HTTP::cookie names] { HTTP::cookie secure $mycookie enable HTTP::cookie httponly $mycookie enable } }Note: The backend doesn't have to deal with those additional flags. Those flags are only send to the client to instruct the browser how to protect the cookie. But it has still the potential to break your application in the case you're not using HTTPS to access the application (Secure flag) or if your Application uses JScript or other client side features to read the cookie values (HttpOnly flag).
Cheers, Kai
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
