ASM violation: Modified domain cookie(s)

Modified domain cookie is the minimal violation that we should really catch - that is actually tampering the actual web application cookie like your jsession, php_session etc. There are more to track (see below link) but personally, that is mandatory since it is user appl and specifically configured to track the trusted session. The moment session cookie is tampered, quite a few abuse cases can happened like session replay, hijack etc. Even XSS like to reveal session cookie

 

 

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

you may be interested in this DC discussion

 

https://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/39/aft/2161411/showtab/groupforums/Default.aspx

thank you for the links, they cleared some things up for me. could you guide me a bit more to what im seeing in the ASM Reporting output, because it seems there the issue lies with some basic cookie behaviour.

 

 

when i go to the Reporting entry for the violation i get Modified domain cookie(s) when i click on that i get the Cookie Name, Cookie Value and Reason. the Reason is New, wouldn't that just mean that the cookie value has just been set, so it changed from empty to the value?

 

 

the cookies which have issue are the ones from google analytic it seems __utmX and one from addthis __atuvc.

 

 

is there a more extensive list of messages from ASM then the online help on the box?

if you take a look at the ASM policy>blocking>settings, those violation is alerted as you enable it under the option " Modified domain cookie(s)", or even subsequent for other cookie violation " ASM Cookie Hijacking", and "Modified ASM cookie". importantly, they are triggered as you configured in the Headers : Cookies : Cookies. There is the two type of cookie which will trigger the violation. Esp on the Enforced cookie

 

a) Enforced cookies - may not be changed by the client

 

b) Allowed cookies - may be changed by the client.

 

 

As for the extra msg, owasp has good info on Session Management Schema. Cookie manipulation is a key component for bypass and tamper. not sure if this is what you are expecting though @ https://www.owasp.org/index.php/Testing_for_Session_Management_Schema_(OWASP-SM-001)

actually if you look into ASM attack signature db, do a custom search with string like cookie, you can find the various web attack related attempt e.g. one of them is document.cookie (Headers) as XSS attempt. There are more notes to other online resources and more info...There is info titled with

 

 

Summary, Impact, Detailed Information, Affected Systems, Attack Scenarios, Ease of Attack, False Positives, False Negatives, Corrective Action....

i understand the risks of clients changing a cookie, but apparently it also is a regularly used way to achieve certain functionality right?

 

 

so is there some way for me to determine what is expected to be fine or not? or will this require having full understanding of what the cookie is used for?

 

 

and one final question, does this really only trigger when the cookie is changed by the client not when the cookie is first set by the server and then returned by the client?

the cookie itself when generated by web server will already be signed and recognised as legit ones when passed back to client. So during client session, the cookie presented will have to be the same one and that is verified by ASM. Client will not intentionally tamper with it since it is not even obvious ... The challenge will be more from if attacker try to steal cookie, replay session and copied session cookie but that can be handled by having secure cookie, session timeout and even CSRF preventive measures.