F5 ASM – Cookie and HTTP Header Tampering

Many web applications set cookies for user tracking, shopping cart functionality, and other reasons related to the user experience. These cookies have to be secured because if they are not properly protected, a malicious hacker could steal or modify cookies for unauthorized access or unrequested purchases. Today, Web Application Firewalls (WAF) help us to secure cookies adding cookie attributes such as the secure attribute, the HttpOnly attribute, Domain and Path attributes, Expire and Max-Age attributes, etc as well as WAFs are also able to sign cookies which are useful to protect web applications from attacks like Cookie Tampering or HTTP Request Header Tampering.

Next, we can watch a video where there is a vulnerable web application to Cookie Tampering. First, I have modified the cookie and sent to the web application successfully. Afterwards, I have protected the web application from Cookie Tampering attacks with F5 BIG-IP ASM. Finally, cookie tampering attacks are unsuccessfully because ASM blocks modified cookies which has been enforced and signed by the WAF security policy. Therefore, it will be a good idea to know what cookies web applications use to enforce those which should not be modified on the client side.

Next, there is another video where the web application is also vulnerable to HTTP Request Header Tampering. First, I have modified the referer HTTP Header to take advantage of the ShellShock vulnerability, which is not blocked. Afterwards, I have enforced the attacks signatures “bash Shellshock execution attempt” and “/bin execution attempt”. Finally, HTTP Request Header Tampering attacks are unsuccessfully because ASM detects malicious strings, which are used to exploit the Shellshock vulnerability, into the referer HTTP Header. Therefore, it will be a good idea to enforce attack signatures in the WAF security policy.

To sum up, we can use a WAF to protect web applications from Cookie Tampering and HTTP Request Tampering which are attacks difficult to block by a traditional network firewall. In this post, we have seen that a manually security policy with Selective Learning for Cookies and Attack Signatures enforced in the WAF security policy is the best configuration to block sophisticated attacks, which want to take advantage of Cookies and Other HTTP Headers to get into web applications.

Regards my friends. Keep reading and keep studying!!


  1. David,
    We want to secure one of our custom web apps with ASM. Our F5s are running LTM/ASM version 12.x. We are not looking for 100% level of security as most of the logic/security is already done at the app layer. What we are looking for is mostly to protect against OWASP top 10.

    In general, we want ASM to do the learning for us and suggest us what we should apply, however we don't want to introduce many false-positives which will end up breaking the application. We don't have the people/time to learn everything regarding the application and we also don't expect the app/devops teams to assist us on a great extent.

    I'm at a point where i haven't understood 100% which deployment scenario to use for our ASM policy. I have read a good bit of documentation, operations guide, online blogs, devcentral, etc. but it looks like i don't have the experience to determine and choose the best option for our requirements.

    Should i just proceed to create a manual policy (Rapid Deployment with Manual learning) to see what suggestions i will get over time and work from there? Do you suggest to opt for automatic policy (Fundamental type with Medium speed)? How would you approach this situation? Any further documents to better understand ASM?
    Happy holidays,

  2. Hi,

    Rapid Deployment Policy (RDP) is the best option to start protecting applications with attack signatures.

    You can check this link. It's really useful.
    - https://support.f5.com/csp/article/K07359270


Enregistrer un commentaire