Could someone shed light on "Modified Domain Cookie" violations?

 

Hi Chris,

 

 

Which ASM version are you running? The functionality has changed somewhat across several versions.

 

 

The modified domain cookie violation would be triggered whenever the client presents a non-ASM cookie with an ASM cookie that doesn't contain matching data. The violation would not be triggered when the server sets a cookie with a new value.

 

 

ASM checks response headers for the Set-Cookie header. If it sees the app set a cookie that is not in the "allowed modified domain cookie" list ASM creates a hash of the app's cookie and saves the hash as part of the the ASM cookie. On subsequent requests, ASM checks the hash of any cookie the client presents which is not in the "allowed modified domain cookie" list against the hash value in the ASM cookie. Another factor that comes into play is the expiration time. In versions prior to 9.4.(~2?), ASM would set the cookie with a max-age property of 900 seconds. It would also check the hash to determine if the cookie timer had expired. In more recent versions I think this has changed to a session cookie.

 

 

Here are a few related solutions:

 

 

SOL6850: Overview of BIG-IP ASM cookies.

 

https://support.f5.com/kb/en-us/solutions/public/6000/800/sol6850.html

 

 

SOL5907: Error Message: Modified domain cookie

 

https://support.f5.com/kb/en-us/solutions/public/5000/900/sol5907.html

 

 

SOL7354: The BIG-IP ASM sets persistent cookies for some web browsers

 

https://support.f5.com/kb/en-us/solutions/public/7000/300/sol7354.html

 

 

Aaron

Thanks a lot Aaron, I am using V9.4.5, most of the errors I am getting are "New Cookie" with referrer obj "Entry Point". Could they be coming from book marked requests? But looking at the amount of these errors, it looks like it is more than bookmarks!!

 

 

Some of our requests go back and forth between few app servers, each app servers are creating their own cookies and we do use content based routing with iRules. So we are using the same VIP for all these applications.

 

 

-thanks

 

Is the cookie that's generating the violation set by the app with an expiration time? If so, it's possible that clients get the cookie from the app (along with a corresponding session cookie from ASM), close their browser, lose the ASM cookie, reopen the browser and then make a new request to the VIP with just the app cookie.

 

 

Can you reproduce the errors by browsing the site? If so, you could try using a browser plugin like HttpFox for FF or Fiddler for IE to trace the cookies being sent/received.

 

 

Aaron

Hello cpaulrag,

 

 

I guess you already have tried this.. but.. have you checked from which domain the cookie is set.

 

 

Browsers do allow cookies for the domain you are browsing and for higher domains. For example: if you are browsing for devcentral.f5.com , your browser will allow setting and viewing cookies for the domain devcentral.f5.com and also, cookies for the domain f5.com .

 

 

However, F5 ASM only allow cookies from the same exactly domain. If you are browsing devcentral.f5.com , it won't allow you to use f5.com domain cookies and it will trigger the "Modified Domain Cookies".

 

 

regards,

 

Javier.

Thank you Javier, You are right on, we do see those violations. Does it also flag when the protocol is switched? We get Bigip affinity cookie from our public site using HTTP and when we switch to HTTPS at the time of login, it is flagging both affinity cookies with Modified Domain cookies violation. (two different pools - one for HTTP and one for HTTPS)

 

 

thanks again

 

Chris

Aaron, I am able to reproduce the problem, all our application cookies are created with Session expiry and so are the F5 cookies (affinity & ASM). I also see a problem with the way ASM is reporting on these cookies, cookie name & value are misplaced on the alerts, it is reporting cookie values as cookie name for some of our cookies (not all of them). However they all show up right on cookiespy & IEWatch.