Forum Discussion

MSK_222682's avatar
MSK_222682
Icon for Nimbostratus rankNimbostratus
Feb 01, 2016

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
  • 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" } }
  • 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
        }
    }
    

    https://devcentral.f5.com/wiki/iRules.HTTP__cookie.ashx

    • Brad_Parker's avatar
      Brad_Parker
      Icon for Cirrus rankCirrus
      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's avatar
      MSK_222682
      Icon for Nimbostratus rankNimbostratus
      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's avatar
      Brad_Parker
      Icon for Cirrus rankCirrus
      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
  • 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
        }
    }
    

    https://devcentral.f5.com/wiki/iRules.HTTP__cookie.ashx

    • Brad_Parker_139's avatar
      Brad_Parker_139
      Icon for Nacreous rankNacreous
      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's avatar
      MSK_222682
      Icon for Nimbostratus rankNimbostratus
      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's avatar
      Brad_Parker_139
      Icon for Nacreous rankNacreous
      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

    [substr ${set_cookie_header} 0 ";"]
    while substituting the new options...

    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