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!!

F5 BIG-IP ASM – Positive Security Policy

I wrote about Policy Tuning and Violations last week where I created a Negative Security Policy, named Rapid Deployment Policy (RDP), to protect web applications from attacks. This kind of policies are useful to protect web applications from known attacks. However, I want to write about Positive Security Policy this week where I’m going to create a security policy manually to customize and accept what file types, URLs and parameters will be used by my web application. This kind of policies are more difficult and complex to configure than Negative Security Policies but they are able to defeat sophisticated and complex threats better than Negative Security Policies.

When we configure a security policy manually, we can choose Never (Wildcard Only), Selective and Add All Entities for file types, URLs and parameters. For instance, if we choose Add All Entities, we’ll have a comprehensive whitelist policy that includes ALL of the website entities. Add All Entities will form a large set of security policy entities, which will produce a granular object-level configuration and high security level. However, it may take more time to maintain such a policy.

On the other hand, the Never (Wildcard Only) option is the most easy security policy to manage because many application objects will share the same security settings driven from the global or wildcard level. In addition, when false positives occur the system will suggest to relax the settings of the wildcard entity. Therefore, it may result in overall relaxed application security. From my point of view, this is a good option for URLs entities because most applications usually have lots of URLs which are difficult to manage from a security policy.

The third learning option is Selective which offers intermediate protection between Never (Wildcard Only) and Add All Entities. This is an option that when false positives occur, the system will add/suggest to add an explicit entity with relaxed settings that avoid the false positive. In other words, Selective mode is suitable for applications containing entities which use similar or identical attributes. However, if some the entities need special handling, the policy can be expanded to include exceptional explicit entities just for those outliers. Therefore, this option serves as a good balance between security, policy size, and ease of maintenance.

To sum up, if we want a comprehensive security policy to defeat sophisticated and complex threats, we’ll have to configure a positive security policy, along with a negative security policy as well, with the Add All Entities, Selective and Never (Wildcard Only) option for file types, URLs and parameters. However, we always have to take into account that the Add All Entities mode is time-consuming but offers high granular protection of entities while the Never (Wildcard Only) mode is easy to manage but offers low protection of entities.

Regards my friends. Keep reading and keep studying!!

F5 BIG-IP ASM – Policy Tuning and Violations

Web Application Firewalls (WAF) should be configured properly to understand web applications logic because if it’s not well-configured, intruders will be able to get access to applications. This is the main reason why developers should take part into WAF deployment projects. However, developers sometimes want to add lots of security codes into applications or even worse, they don’t want to know anything about security. From my point of view, developers should take part into WAF deployment projects but security should be managed by security engineers. I mean, developers should improve applications with new features and enhancements while security engineers should protect applications.

Organizations don’t take advantage of lots of security tools like Antivirus, network firewalls, Web Application Firewalls (WAF), Security Information and Event Management (SIEM) systems, Network Access Control (NAC) systems or Vulnerability Assessment Tools because these tools are time-consuming, companies don’t have security staff and IT engineers never have enough time to configure properly these tools. Therefore, security tools tuning such as firewall policies tuning is most of the time difficult to accomplish.

When I talk about Policy Tuning and Violation, for instance, for a WAF deployment, I’m talking about choosing the right learning mode, defining learning suggestions, defining the Learn, Alarm and Block settings or defining the Enforcement Readiness Period. Next, we can watch how I create a negative security policy based on Rapid Deployment Policy (RDP) and I accept learning suggestions for false positive as well as I block XSS attacks. A negative security policy configuration like this should be the first phase in a WAF deployment.

Once we are protecting web applications with a negative security policy, we should take the plunge to a positive security policy. This will be more difficult because we need the developers participation. What’s mean, developers have to know what entities are used by applications. For instance, we have to know about file types, URLs redirections, cookies, static and dynamic parameters, etc, etc. Therefore, negative security policy along with positive security policy will be a real protection for your web services.

Regards my friends. Drop a line with the first thing you are thinking.

WAF vs IPS

Organizations are wondering whether IDS/IPS is enough for protecting their services or it’s much better to deploy a Web Application Firewall (WAF) solution. They are always wondering if deploying a WAF solution, they’ll able to save money because IDS/IPS infrastructure will not be necessary. However, attacks occur at different layers thus web application protection is not enough for network attacks. For instance, malicious intruders may start with DoS attacks, and later, launch a layer 7 attack like SQLi or XSS attack. Therefore, we should provide security at all layers. Otherwise organizations have a closed gate with no fence around it.

IDS were developed in the mid-80s by the U.S. Air Force because they needed a behavioral analysis to increased computer security awareness. First, they only analysed system logs to detect anomalies and attacks. Next, they started analysing network traffic as well. However, IDS was improved to IPS in the 90s which was also able to find and stop attacks in real time. Snort was one of the first open source IDS/IPS available. Today, most NGFW have built-in IDS/IPS based on signature attacks, which are able to intercept files and network activity for preventing malicious attacks.

As web applications became publishing to Internet, secure internet gateways and network firewalls became more used in the late 90s because web applications were designed without thinking about security and most of them had serious vulnerabilities. WAFs have greatly matured since then. Today, WAFs can understand the web application logic to block everything which not match the application logic. Therefore, WAFs can block malicious attacks matching traffic against signature attacks (negative security) but WAFs can also block malicious traffic matching the application logic (positive security).

IPS don’t understand underlying applications thus they don’t know about entities like parameters, URLs, file types, cookies or redirections. However, WAFs can protect entities to block sophisticated attacks like web-scraping attack, SQLi, XSS, CSRF, etc, etc. For instance, IPS can analyse HTTP traffic to look for most common web application vulnerabilities but WAFs can also analyse HTTP traffic to look for parameters value, parameters size, cookies signatures, etc.

The best security protection involve both an IPS and a WAF. Although some commercial WAFs like F5 BIG-IP WAF or Imperva WAF have IPS features, it’s much better to deploy both separately for a comprehensive protection because IPS are going to protect the most commonly used Internet protocols, such as DNS, SMTP, SSH, Telnet and FTP, while WAFs are going to protect applications against web-based threats.

WAFs solutions are mainly designed to prevent attacks against web applications while IPS are purely designed to inspect network traffic. Therefore, both may block known and common attacks. However, if we want to protect companies from sophisticated attacks, we’ll have to deploy IPS and WAFs, as well as IDS. This is a best practice of layered defenses. Nevertheless, if your company has neither, the WAF would provide the best application protection overall.

Regards my friends. Let me know what you are wondering!!