Forum Discussion

Simon_Waters_13's avatar
Simon_Waters_13
Icon for Cirrostratus rankCirrostratus
Feb 24, 2016
Solved

Cookie Encryption - duplicate cookies

TL;DR has anyone written code to deduplicate cookies before the cookie encryption feature is used?

 

We had a ticket C1649037 to do with the Cookie Encryption breaking if the cookie was duplicated in the server's response headers.

 

e.g. Server says:

 

set-cookie A hello

 

set-cookie A hello

 

F5 told to encrypt A says:

 

set-cookie encrypted gfddsgde34fwqf34

 

set-cooke A hello

 

e.g. F5's Cookie encryption was only encrypting one copy of a set-cookie header in the server's response.

 

Its a minor edge case, although for the vendor we spotted it with duplicate the session cookie in response to a successful login request so the session cookie doesn’t get encrypted. Also leaking the plain text of some cookies may make cryptanalysis even easier ;)

 

Since the ticket was raised, we mentioned it to PortSwigger Web Security, who write BurpSuite security testing tool, and they added a duplicate cookie test (they are really good with these kinds of requests).

 

Since then it has become clear:

 

1) the vendor is not going to remove the duplicate cookies any time soon.

 

2) duplicated cookie headers are very common in web applications, although usually it is deletion where it goes wrong as the session headers are written and then the deletion.

 

3) HTTP/2 header compression makes it all the more complicated to diagnose as you need to ensure you have the same protocol version as the browser seeing the issue, since HTTP/2 effectively dedups cookies for you.

 

As such I’m minded to finally address the issue by fixing the F5's behaviour. Presumably de-duplicating cookie headers before encryption.

 

Has anyone written this already? Should be easy, but I vaguely recall at the time that the cookies were presented as an associative array.

 

The “best” solution would be for a supported change to the F5 Cooke Encryption feature, that always prefers later cookies headers with the same name when encrypting a request from the server to the client, as this is the RFC compliance resolution that the browser should do.

 

Cookie encryption is notoriously tricky to do right and generally shouldn't be relied on. Here we are treating it as an additional measure to discourage poking at cookies, and to avoid the issue with sensitive data in the cookies being stored in the browser for long duration. Rather than trying to obscure a known cookie parsing weakness (down this road lies madness and being hacked).

 

BIG-IP
cookie
iRules
security
set-cookie

2 Replies

Sort By
  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Feb 25, 2016

    Hi Simon,

    below are two quick codings to sanitize duplicated instances (any number) of a given Set-Cookie...

    when HTTP_RESPONSE {
    if { [HTTP::header value "Set-Cookie"] ne "" } then {
        set cookie_name "MyCookie"
        set cookie_count [llength [lsearch -all -glob [HTTP::header values "Set-Cookie"] "$cookie_name=*"]]
        while { $cookie_count > 1 } {
            set cookie_count [expr { $cookie_count - 1 }]
            HTTP::cookie remove $cookie_name
        }
    }
}

    ... or ... 

    when HTTP_RESPONSE {
    if { [HTTP::header value "Set-Cookie"] ne "" } then {
        set cookie_name "MyCookie"
        set cookie_values [lsearch -inline -all -glob [HTTP::header values "Set-Cookie"] "$cookie_name=*"]
        set cookie_count [llength $cookie_values]
        while { $cookie_count } {
            set cookie_count [expr { $cookie_count - 1 }]
            HTTP::cookie remove $cookie_name
        }
        HTTP::header insert "Set-Cookie" [lindex $cookie_values end]
    }
}

    Note: The first iRule will keep the first instance of "Set-Cookie" (better performance) and the second iRule would keep the last instance of "Set-Cookie" (according to RFC 6265).

    Side Note: F5 uses AES to encrypt Cookie information and one of the major design goals of AES was to become somewhat resilent against differential cryptanalysis attacks (unlike DES). So your cookie will be pretty much secured against any (known) form of chosen- or well-known plaintext attacks...

    Cheers, Kai