Cookie Tampering Protection using F5 Distributed Cloud Platform
Introduction:
It’s well known that browsers use HTTP protocol and as its stateless, user session requests don’t have details about user information. This is where cookies come as savior as they are small chunks of information created by web applications for user session tracking stored on user's web browsers. Cookies may remain stored for a long time but can be deleted by the user for additional privacy. Cookies provide critical functions for web applications, including state persistence and identifying users. When developers utilize cookies to store data used by applications, they sometimes overlook including input validation to prevent tampering with that data. Cookie tampering is a method of infiltrating the information stored on a user’s web browser and manipulating it to hack the user’s session on the application.
Below are some of the reasons for misuse of cookies:
- Manipulating cookies to influence application behavior
- Introducing new cookies to create application vulnerabilities
- Hijacking user sessions
For example, as per this link, hackers tampered saved user details of "keep me logged in" & "remember me" cookie preferences and tricked web browser into telling Yahoo that user already logged in thereby stealing millions of user’s personal data.
This link tells about how a third party trojan acquires superuser root permissions on the target device, and finally transfers stolen cookies of multiple apps like Facebook, Chrome, etc. to a remote server operated by attackers.
Cookie Tampering protection prevents attackers from modifying the value of session cookies. Cookies arrive in HTTP requests in cookie headers, which The F5 Distributed Cloud (F5 XC) WAF service scans for string violations. F5 XC WAF can enforce cookies by detecting if any attackers manipulated cookie values and then optionally blocking the corresponding requests. Cookie protection is highly recommended for cookies that contain sensitive data and influence application behavior.
The SecOps team can get a list of application cookies from developers and then apply cookie protection rules on the identified cookies appropriately in the F5 XC Cookie Protection section.
NOTE: wildcard and all cookies protection are not supported as it may cause issues with browser content, so SecOps must carefully go through list of cookies and decide which ones should be protected in F5 XC.
Use case:
For today’s demonstration, we have already deployed a flask application that creates a session token cookie and is passed on to simultaneous requests. If we open the browser and try to access this application “/set” URL, we can see that the below token cookie is generated, and these will be passed on to other requests for ex. “/get” endpoint.
This token cookie is visible in data packet trace which can be captured by hackers to gain access to user preferences. This cookie can also be modified via proxy tools to create instability in the application results.
Mitigation Steps:
- Login to F5 XC console and navigate to “Distributed Apps” menu
- Expand “Manage” menu and open “Origin pools” section under “Load Balancers” drop-down
- Onboard your application. Since my application is running on a VM, I have used my machine IP and port on which flask app is running as part of onboarding configuration
- Next navigate to “HTTP Load Balancers” section and create a load balancer of your choice using above origin pool as shown below
- Next, open the above LB in editing mode and apply WAF configurations in blocking mode. If monitoring mode is set in WAF, only security events will be generated but requests will not be blocked.
- For the same load balancer, navigate to “Cookie Protection” section and create a rule as per the needed configurations.
Below are some details on these cookie protection flags:
1. Secure – This is used to send cookies only in an encrypted and secure channel. For ex Load Balancer using https protocol
2. HttpOnly – This flag when set will make sure only browsers or agents using http or https protocol to access protected cookies. Bots which run mostly using JavaScript's would not be able to access these protected cookies
3. SameSite – This is mainly used to protect cookies by sending them only if request is generated from same-site
For ex, I have enabled multiple options and tampering protection as shown below.
NOTE: Since I'm using HTTP load balancer, I have not added secure flag. If users are using HTTPS load balancer, a secure flag can be added. - Next open browser in incognito mode and access your app URL (in my app “/set”) to check if these flags are set appropriately as shown below
- Open Postman and generate a GET request to above URL, next click on Cookies button & modify token cookie value and finally send a GET request to another URL (in my app “/get”).
- Validate illegal request is blocked as shown below and a security event is generated for this cookie tampering attempt.
- Since we have added HttpOnly flag for this token cookie, protected cookie shall not be visible if we try to access using JavaScript as shown below
Conclusion:
In this article, we have covered the basics of cookies and then we also demystified how intruders can tamper cookies to modify application behavior. Finally, we also showcased how F5 XC cookie tampering protection can be used to safeguard our sensitive cookie workloads.
For more information or to get started check links below: