Forum Discussion
iRule : BIGipServer cookies HttpOnly generating Improper version errors
Hi,
The following iRule is working fine to encrypt and set secure flag. Currently running on 11.2.1 HF13.
When adding HttpOnly flag we are receiving the following errors:
- Improper version (line 9) invoked from within "HTTP::cookie httponly $cookie_name enable" ("foreach" body line 18) invoked from within "foreach cookie_name $cookie_names { if {$static::ck_debug}{log local0. "Cookie Name unencryted : $cookie_name"} Encrypt the cookie value ..."
Which causes overall failure and errors. Version is added before enabling HttpOnly.
Is there a bug? Code issue?
How can I ensure HttpOnly flag is also being set on the all BIGipServer cookies (We have multiple due to web and app layers)?
Thanks J
when RULE_INIT {
Cookie name prefix
set static::ck_pattern "BIGipServer*"
Log debug to /var/log/ltm? 1=yes, 0=no)
set static::ck_debug 1
Cookie encryption passphrase 20 chars
The default key length is 128 AES
set static::ck_pass "XXXXXXXX"
}
when HTTP_REQUEST {
if {$static::ck_debug}{log local0. "Request cookie names: [HTTP::cookie names]"}
Check if the cookie names in the request match our string glob pattern
if {[set cookie_names [lsearch -all -inline [HTTP::cookie names] $static::ck_pattern]] ne ""}{
We have at least one match so loop through the cookie(s) by name
if {$static::ck_debug}{log local0. "Matching cookie names: [HTTP::cookie names]"}
foreach cookie_name $cookie_names {
Decrypt the cookie value and check if the decryption failed (null return value)
if {[HTTP::cookie decrypt $cookie_name $static::ck_pass] eq ""}{
Cookie wasn't encrypted, delete it
if {$static::ck_debug}{log local0. "Removing cookie as decryption failed for $cookie_name"}
HTTP::cookie remove $cookie_name
}
}
if {$static::ck_debug}{log local0. "Cookie header(s): [HTTP::header values Cookie]"}
}
}
when HTTP_RESPONSE {
if {$static::ck_debug}{log local0. "Response cookie names: [HTTP::cookie names]"}
Check if the cookie names in the request match our string glob pattern
[lsearch -all -inline [split [HTTP::cookie names]] $static::ck_pattern]
if {[set cookie_names [lsearch -all -inline [HTTP::cookie names] $static::ck_pattern]] ne ""}{
We have at least one match so loop through the cookie(s) by name
if {$static::ck_debug}{log local0. "Matching cookie names: [HTTP::cookie names]"}
foreach cookie_name $cookie_names {
if {$static::ck_debug}{log local0. "Cookie Name unencryted : $cookie_name"}
Encrypt the cookie value
HTTP::cookie encrypt $cookie_name $static::ck_pass
if {$static::ck_debug}{log local0. "Cookie Name encryted : $cookie_name"}
Secure Cookie flag
HTTP::cookie secure $cookie_name enable
if {$static::ck_debug}{log local0. "Add secure : $cookie_name"}
HttpOnly flag - v11+ only
HTTP::cookie version $cookie_name 1
HTTP::cookie httponly $cookie_name enable
if {$static::ck_debug}{log local0. "Add httponly : $cookie_name"}
}
if {$static::ck_debug}{log local0. "Set-Cookie header(s): [HTTP::header values Set-Cookie]"}
}
}4 Replies
- sfuerst_116779Historic F5 Account
The HTTP::version command changes the value of the "version" cookie attribute string. It doesn't actually change the type of the cookie from Netscape-style to RFC 2109 or RFC 2965 style cookies. So if the cookie doesn't support the "HttpOnly" attribute, attempting to set it will not work.
What's worse, is that RFC 6265 style cookies will be miss-detected as Netscape style cookies. Until this is fixed, you are unfortunately better off using HTTP::header commands to manually edit HTTP cookies.
- you know if there is a bug ID for this?
- StephanManthey
Nacreous
Hi,
after testing both TMOS v11.2.1 and TMOS v11.5.1HF10 I found the command
working under a specific condition only. In v11.2.1 you may see an error message "Illegal argument (line 1)" in /var/log/ltm and clientside connection will be resetted by the virtual server. In v11.5.1HF10 you may see no error message in /var/log/ltm and clientside connection will be resetted by the virtual server as well. The RST cause logged in the tcpdump (using options "-i 0.0:nnnp -s 0") is as follows:HTTP::cookie version 1rst_cause="[0x19a15c8:1288] {peer} iRule execution error"In both cases no response will be delivered to the client. The command works fine as long as the cookie to be modified has at least an additional attribute. If the cookie just consists of name and value (with and without a trailing semi colon) you will observe the behavior described above.
If the cookie to be modified has additional attributes (i.e. "Path=;Domain=") the conversion works fine in both TMOS versions. You can verify it by using the following iRule as reflector to force differently formatted cookies:when HTTP_REQUEST { set my_content [subst {cookietest plaintext page}] set my_cookie [subst {myCookie42=value42;Domain=[getfield [HTTP::host] ":" 1];Path=[HTTP::path]}] set my_cookie [subst {myCookie42=value42}] set my_contype [subst {text/plain; charset=us-ascii}] HTTP::respond 200 content ${my_content} Set-Cookie ${my_cookie} Connection Close Content-Type ${my_contype} }The iRule above can be bound to an additional virtual server referenced by the command
in your current iRule. Just play with the my_cookie variable for evaluation, please. From my perspective it is a bug preventing us from using thevirtual
command. In case you already have an open support case on the subject, please let us know. Otherwise I will open one. Thanks, StephanHTTP::cookie version - StephanManthey
Nacreous
It turns out, that other cookie related commands fail as well, as long as the cookie sent by the server does not have any additional attributes (tested in TMOS v11.5.1HF10.). I tried to add path, domain and comment attributes to a cookie received in the context of HTTP_RESPONSE using the HTTP::cookie commands. It always failed, as long as it was consisting of the name=value pair only. As soon as the server adds at least a single attribute, modifications can be applied.
Whenever the operation is successful, the new attribute=value pair will be inserted at the beginning of the additional attributes list. And if there is no attribute yet, the algorithm cannot put the new attribute in front of it ...
Thanks, Stephan
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)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
