Modified Domain Cookie blocking

Hi David,

 

 

By design for security reasons, a browser should never include a cookie in a request to one domain which was set for another domain. Is it possible that the cookies are being set on a different subdomain that is part of your root domain? If so, you could add them as allowed modified domain cookies in the ASM policy to tell ASM to ignore them.

 

 

Can you post some anonymized examples of the requests? If you're not able to reproduce the issue, it might help to add an iRule which logs the cookies in requests and responses. You could modify a version of one of the Codeshare logging examples:

 

 

http://devcentral.f5.com/wiki/default.aspx/iRules/LogHttpHeaders.html

 

 

This rule would use a lot of CPU time, so be careful about adding it to a production virtual server.

 

 

Also, there have been a lot of significant issues fixed in the latest version and hotfix (9.4.5 hotfix 2), so it would be a good idea to upgrade when possible.

 

 

Aaron

Heres a couple of examples.

 

First example:

 

 

Cookie name = Finjan-Auth

 

 

GET /savingapps/html/forms/savings_app_help/empdetails.html HTTP/1.0

 

Accept: */*

 

Accept-Language: en-gb

 

Cookie: Finjan-Auth=57lMEvEiJ4m0fM7nn5lHEVOBbvP6PdULKtwOztu7Ksq+w/0MRxa/uQoLytSjnmc0; SIVISITOR=MjIuNzIyLjExNzk5NTI2NjYxNTguMTIyNjUwMDI0ODIyMQ__; s_cc=true; s_sq=britbscoukprod%3D%2526pid%253Dhome.c_savings.product.notice_accounts.premsav.sav_app.html%2526pidt%253D1%2526oid%253Djavascript%25253Aaccounttype%252528%252527premsav%252527%252529%2526ot%253DA%2526oi%253D72; TS4b6c63=c278badda7d8ed901729b76101906803d9f41bcef991d297491ae896; IV_JCT=%2Fhome; JSESSIONID=0001dD8eCt-Apy_8TnmT9_u0G2c:-DG1FS6; PD_STATEFUL_1ebd5b44-3ba1-11dd-aa70-c0a84102aa77=%2Fsavingapps

 

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

 

Host: www.britannia.co.uk

 

Connection: Keep-Alive

 

 

Second example:

 

 

Cookie names (3 of them)

 

L6289

 

_mkto_trk

 

__utma

 

 

GET /mortgageapp/css/layout/mbox.css HTTP/1.1

 

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_5; en-gb) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1

 

Referer: https://www.britannia.co.uk/mortgageapp/mac_safari.html

 

Accept: text/css,*/*;q=0.1

 

Accept-Language: en-gb

 

Cookie: camp=sageampFFJUF584%60%60Mon%2C%2010%20Mar%202008%2014%3A26%3A03%20GMT%7CsageampPCJWO184%60%60Mon%2C%2010%20Mar%202008%2014%3A26%3A03%20GMT%7C; sageamp=sageampFFJUF584%7CsageampNLVOD421%7CsageampPCJWO184%7CsageampVUQND682%7CsageampLLOEC769%7CsageampUQGLM194%7C; s_pers=%20s_favsn_paypalglobal_1%3D1100029004737%7C1522106457646%3B; __utma=186137275.938163156.1209930838.1209930838.1209930838.1; s_vi=[CS]v1|48AD3FD4000045C0-A000BAF000009E1[CE]; AMOS_PREF=sac%3Dg3%252Ck36; _mkto_trk=id:841-CMW-048&token:_mch-co.uk-1223594949213-99427; L6289=1.1226588030336; SIVISITOR=NS43NjEuODM3MDI2NTY5OTkyMy4xMTk4NDA4MDk1NTQ2; IV_JCT=%2Fhome; s_cc=true; s_sq=britbscoukprod%3D%2526pid%253Dhome.mortgage.index.html%2526pidt%253D1%2526oid%253Djavascript%25253AmtgcalcquotepopUp%252528%252529%25253B%2526ot%253DA; PD_STATEFUL_125df088-1d16-11dd-9e46-c0a84102aa77=%2Fmortgageapp; TS4b6c63=fbbf9a6f4814833639a68c5e3589440e1d0f7873d98da270491aed97

 

Connection: keep-alive

 

Host: www.britannia.co.uk

 

 

 

Do these help?

 

 

 

It would be most helpful to see the response(s) where these cookies are being set. They may not be from your application, but could be from other applications on the britannia.co.uk domain. The __utma cookie is a Google Analytics cookie. The _mkto_trk cookie looks to be from a marketing company, Marketo. I couldn't find any info on the L6289 cookie. I'd guess it's something custom.

 

 

If you're not worried about the client modifying these cookies, you could either configure them individually as allowed modified domain cookies, or you could disable checking of domain cookies altogether. Unless we know of a specific issue in the application we're configuring a policy for with badly encrypted cookies we normally disable this check anyhow.

 

 

Aaron

Thanks for the response Aaron

 

 

Where would I get the response information from that you seek?

 

 

For information, the cookies are not from our applications - I've checked with our developers who confirm this. Therefore I'm confused as to why they are being presented to our F5s ?

 

 

We do have the Modified Domian Cookie disabled at the moment - because we are getting hundreds of them (therefore hundreds of potential customers) blocked by the F5 policy.

 

 

However, what level of risk are we running in not having this feature enabled?

 

 

An independent consultant who reviewed our F5 policy recommended that it be enabled again as soon as we managed to sort out why we were seeing so many 'foreign' cookies.

 

 

 

 

 

What can be a workaround is an iRule that cleans all non-application/BIG-IP cookies from an HTTP request to this VS

The cookies could be set by any web application that is on the britannia.co.uk domain or the www.britannia.co.uk subdomain. I don't think you can tell where they're being set just by looking at the requests being made to the VIP.

 

 

As Ido suggested, you could use an iRule to remove the cookies, but that might break the application that set them. You could potentially remove all but the cookies you want to check in HTTP_REQUEST and then reinsert them in HTTP_REQUEST_SEND using 'clientside {HTTP::cookie insert name $original_cookie_name value $original_cookie_value}'. I haven't tested this, but it seems like it would be possible.

 

 

If there aren't any known issues where a client could tamper with the application cookie values, I'd just disable the check. It means that ASM won't check to see if the application cookies have been modified by the client.

 

 

Thanks,

 

Aaron

Nevermind that suggestion... it shouldn't break your app if you removed the other application's cookies. The client would continue to submit the cookies to other applications on the same domain if they were set with a valid domain value by the other application.

 

 

And the cookie validation ASM provides with the modified domain cookies is good protection against cross site script attacks, so it would be ideal to leave the check enabled if you can fix the "non-local" cookies. This could be done by finding the app that is setting them or by removing them with an iRule in the HTTP_REQUEST event before ASM parses the request.

 

 

Aaron

I am seeing similar problems to those being described here. We receive numerous cookies, which I believe get added by the client's web proxy. One example of this is "BCSI-CS0A84E644", which I believe originates from a BlueCoat proxy. I think it's poor form of these proxies to add a cookie, but I have to work around it. Ideally, I would like to allow all cookies that start with BCSI, but I can't find a way to do that.

 

I could add an iRule to delete all such cookies, but I am concerned about how the proxy will behave if the response does not contain its cookie. I suppose it might be possible to strip the cookie when recieved and then re-attach it when sending the response, but that's starting to sound like a complex solution.

 

Any suggestions?

A good proxy wouldn't leave its cookies in requests it sends out as it opens itself up to session hijacking. In 9.4.2+, you can ignore the cookies which start with BCSI using the modified domain cookies setting. The field accepts wildcards, so you can configure BCSI-*. Also, you could use an iRule to remove these cookies from requests. This would not affect the proxy functionality and it would be a secure option. Your web app should ignore these cookies. And it definitely should not set any BCSI- cookies in its response.

 

 

Aaron

Thanks for the prompt response.

 

Like you, I am really surprised by the behaviour of these proxies, but it seems to be quite commonplace. At least 3 of our customers (large corporates) have caused this problem for us, which is why I need a generic solution.

 

Sadly, we're still on version 9.3.1, so the Wildcard option is not available. Howevever, I am coming around to the idea of an iRule that simply dumps any cookies matching this pattern.

 

I will test this approach and let you know how I get on.