Application Security - Web Application Firewalls

Web shops are faced with harsh competition. Apart from attractive products and prices, this means: Who has the most comfortable shop with the most appealing look and best security? In view the fact that the use of purchased frameworks (SAP, Oracle Suites) has become standard procedure and developers increasingly resort to composites and mash-ups due to the limited development time window,  complexity is on the rise. Extensive quality checks in the form of code reviews are not applied with the same thoroughness in every release cycle or only exist in theory.

High complexity and massive time pressure clash with the need for quality and security.  

In addition to economic damage and an image loss, an attack can also result in legal consequences if the policies of the Payment Card Industry Data Security Standard (PCI DSS) are not complied with. Violations can be expensive: penalties can be imposed depending on the transaction volume, restrictions can be issued, or the acceptance of credit cards can even be prohibited.

PCI Security Standards Council   

Web Application Firewalls (WAF) enable you to ensure a high, PCI-compliant security level for Web applications even under difficult development conditions. Classic security solutions like firewalls, reverse proxies, deep inspection, and IDS/IPS can only protect Web applications to a very limited extent, as they protect the traffic on transport layers and at most enable basic pattern detection, but cannot interpret the business logic layer. Thus, typical attacks on Web applications, such as form field tampering, SQL injections, parameter manipulation, cross-site request forgery, brute force login, cookie poisoning, or session hijacking, are not detected. The requests are not analysed at HTTP and business logic level. Information on this subject is available at the .Web Application Security Consortium

Significantly reduced risks and threat potential

In contrast, highly developed Web Application Firewalls (WAF) can handle all protocol layers, filtering known and unknown attacks on transaction-oriented Web applications. This also includes new types of attacks on the Web 2.0 technology, such as cross-site request forgery and malicious AJAX code execution. For this purpose, incoming HTTP/HTTPS requests are received, analysed (pattern detection, statistical methods), and classified (legitimate, attack, suspect) before they reach the Web application.  

Common request verification procedures: 

• Protocol termination, validation, and rebuilding
• Session tracking and anomaly detection
• SSL termination and protection of session and cookie handling
• Input validation to check user input/interception of command injections
• Malicious code detection by pattern and anomaly detection
• Phishing detection/referrer checking to prevent unwanted linking

WAF operation – cumbersome adjustments every time an application changes?

One of the core duties of a WAF is to ensure that only URL calls belonging to the application are permitted. In other words: resource accesses under the Web server root, e.g. to DLLs, file versions, or internal applications must be intercepted.  

But how does the WAF know what is good and right?  

Modern solutions are able to learn dynamically during runtime. When a permitted start URL is called, the WAF analyses all Web pages returned by the Web server and adds their URLs to the dynamic policy held in the main memory. The problem is that it will block all URLs not yet learned and thus also all linked URLs that have not yet been called. This problem can be solved with the help of URL crawlers that track all links.

The combination of a static start policy and dynamic learning has proved to be most practical. Due to their insufficient attack coverage and enormous operation overhead, we do not recommend security solutions that operate purely statically, such as the open source tool ModSecurity for the Apache Web server. 

Input Validation is another central task of a WAF. As the greatest potential for attacks lies in injection attacks (SQL/command injections, cross-site scripting), parameter checks (session IDs, value ranges) must be performed accurately. To configure the value and length of every individual parameter of the Web application one by one in the WAF borders on a Sisyphean task, especially if the application is subject to frequent changes. This issue can be solved by means of blacklists that address all kinds of injection attacks and that are updated very often. 

Apart from checking the user input, the WAF must also check the integrity of the read-only parameters. This can be done dynamically in that the WAF remembers the values of the parameters that the application first delivered to the user during the session.

Interested in a professional discussion and solutions for specific requirements? Please feel free to contact us.