http_to_https http profile rule question

Hi Kelly

 

 

If you're only redirecting the client from HTTP to HTTPS using a class or iRule, the request is never going to get to the web app, so no cookie could be set insecurely there. But if a client received a cookie from the app via HTTPS or from any other app on the same domain, they would potentially include the cookies in the request to the HTTP VIP.

 

 

One way to handle this issue is by setting the secure flag on all sensitive cookies when they're sent to the client. This assumes that you never need to get the cookie(s) for HTTP requests. This is one reason to only use HTTPS for web apps which pass sensitive data.

 

 

 

http://www.w3.org/Protocols/rfc2109/rfc2109

 

 

Secure

 

Optional. The Secure attribute (with no value) directs the user

 

agent to use only (unspecified) secure means to contact the origin

 

server whenever it sends back this cookie.

 

 

The user agent (possibly under the user's control) may determine

 

what level of security it considers appropriate for "secure"

 

cookies. The Secure attribute should be considered security

 

advice from the server to the user agent, indicating that it is in

 

the session's interest to protect the cookie contents.

 

 

 

 

Aaron

I'm understanding more, I think. Setting cookies to Secure in our asp.net code wouldn't help, because that only says "only transmit cookies over ssl", right? It doesn't actually help because between the F5 and our web servers, you can only do SSL.

 

 

So what are my options? How can I tell the F5 not to return cookie data over non-ssl? Or can I turn on cookie encryption on the F5?

No cookie should be set in a response generated from LTM unless you explicitly configure it. Nor could the app set a cookie if the request is never load balanced by LTM. I was assuming the client was sending a cookie in the request to the HTTP VIP.

 

 

Can you use a browser plugin like HttpFox for Firefox or Fiddler for IE to check what cookies are being sent/received on a request to the HTTP VIP? Or did the pen test report contain examples of the issue? Either way, if you can post an anonymized copy of the HTTP request/response headers the client sees it would help identify the issue.

 

 

Aaron

Was the original Location header value http://something? Or was it just a path like /anon/anon.aspx? If it's the former, that might be the issue that WebInspect is reporting. If it is an http:// reference in the Location header value, you can have LTM rewrite it to HTTPS using the rewrite redirects option on a custom HTTP profile you add to the VIP.

 

 

That request is most likely to the HTTPS VIP as the response shows a persistence cookie for an HTTPS pool. Also, the redirect is coming from IIS--not LTM--as evidenced by the Server and X- headers in the response. LTM won't insert response headers like that in a response it generates itself.

 

 

Aaron

Nope, the original location header value was /anon/anon.aspx.

 

 

Thanks for catching the redirect thing - truth is stranger than fiction and I totally missed our other redirect. There's actually two redirects going on - the F5's redirect all http to https. Second, I'll redo the block to show the pages better. I named the url they are going to Anon01, and the url our code redirects them to as Anon02.

 

 

Attack Request: GET /Anon01/Anon01.aspx HTTP/1.1

 

 

 

Attack Response: HTTP/1.1 302 Found

 

 

Location: /Anon02/Anon02.aspx

 

 

Set-Cookie: BIGipServeranon.com_https=180882442.47873.0000; path=/

 

Object moved

 

Object moved to .

 

 

File Names: https://anon.com:443/Anon01/Anon01.aspx

 

 

----

 

 

What's VIP stand for, sorry? Virtual IP? What I was calling a listener?

 

 

In the end, what am I looking at? WebInspect seems to be confusing an initial http request with a 302 response (the 2nd 302 response, from our web site) with cookie data to be "insecure". I would challenge this I guess, that the product isn't smart enough to understand what it's getting into.

 

 

The gist is that they aren't doing traffic with our web servers non-ssl, I think that's safe to assume. The only VIP that connects to our web tier is SSL-only. Is there any reason, from the bit of response WebInspect is showing, to think we're not responding over SSL? The F5 redirect (to SSL) is over http, I get that. How else would you redirect from http to https? (not a real question).

What's VIP stand for, sorry? Virtual IP? What I was calling a listener?

 

 

 

Yeah, it's a bad shorthand for virtual server (IP and port). I guess it should be VS as VIP should mean virtual IP address.

 

 

I'm still not sure exactly what issue WebInspect is reporting. WI makes a request to an HTTPS VIP and receives a local reference redirect Location to /Anon02/Anon02.aspx. That's coming from the web app, not LTM. And even though RFC2616 states Location header URLs must be absolute (containing a full URL including the protocol), every major browser I've ever tested with will make a new GET request to the same host over the same protocol. So the client should make a request to https://anon.com:443/Anon02/Anon02.aspx. No cookies have been sent over HTTP in the two requests.

 

 

WebInspect seems to be confusing an initial http request with a 302 response (the 2nd 302 response, from our web site) with cookie data to be "insecure".

 

 

 

In past testing with WI, I haven't seen that problem, so I'm still not clear what the issue is. Can you post the full (anonymized) details from WI for this?

 

 

Aaron

Sure. You've seen the request and response block from WebInspect, here's the text accompanying it, with the url anon'd.

 

 

SSL Cookie Not Used

 

Summary: This policy states that any area of the website or web application that contains sensitive information or access to privileged

 

functionality such as remote site administration requires that all cookies are sent via SSL during an SSL session. The URL:

 

https://anon.com:443/Anon01/Anon01.aspx has failed this

 

policy. If a cookie is marked with the "secure" attribute, it will only be transmitted if the communications channel with the host

 

is a secure one. Currently this means that secure cookies will only be sent to HTTPS (HTTP over SSL) servers. If secure is not

 

specified, a cookie is considered safe to be sent in the clear over unsecured channels.

Okay, that's making a it more sense. WI is reporting that the client is receiving cookies from LTM/the app that do not have the secure flag set. Because there is an HTTP VIP defined that accepts TCP connections (regardless of what it does in terms of HTTP responses), if the client did make a request to the HTTP VIP, it would include the cookies which are not marked as secure by LTM/the app.

Now, if nothing references the HTTP VIP, a client should never make a request to the HTTP VIP after they've received a cookie from the app and this shouldn't be a problem. But it would still be a simple change to the app or with an LTM iRule to add the secure flag to the cookies to explicitly tell clients not to send the cookie in requests made via HTTP. Here is an example iRule:

 
 when HTTP_RESPONSE { 
  
     Insert a test cookie (remove this when done testing) 
    HTTP::cookie insert name test_cookie value test_value path / 
  
     Set the secure flag on the test cookie (remove this when done testing) 
    HTTP::cookie secure test_cookie enable 
  
     Loop through each cookie in the response by name 
    foreach a_cookie [HTTP::cookie names] { 
  
       log local0. "$a_cookie=[HTTP::cookie value $a_cookie], secure: [HTTP::cookie secure $a_cookie]" 
  
        Set the secure flag on the cookie. 
         The flag only seems to be set if it's not there already, so no need to check the original state first 
       HTTP::cookie secure $a_cookie enable  
    } 
 } 
 

Log output:

: BIGipServerGoogle_http_pool=1680702794.20480.0000, secure: disable

: test_cookie=test_value, secure: enable

Response headers received by the client:

Set-Cookie: BIGipServergoogle_http_pool=1680702794.20480.0000;secure; path=/

Set-Cookie: test_cookie=test_value;secure;path=/;

Aaron

Thanks!

Thanks Aaron, this took care of it. We passed a lesser scan (that we own) where this was marked low/informational, we're asking the client to rescan us with WebInspect but I have no reason to believe we won't pass.