Content rewriting protects from inadvertent outbound information flow: Error and status messages, which give important information to a hacker for additional attacks, are filtered and re-written as neutral messages. This functionality also allows masking sensitive data, e.g. credit card numbers, protecting such data from inadvertently being displayed by an application.
A dynamic whitelist filtering method that protects web application users from unauthorized access to cookie content. Additionally, it also protects applications from cookie content modification: Cookies are stored by the Web application firewall, in a cookie store, and never even reach the client. But if needed, cookies can still be passed to the client, dynamically encrypted to protect them from any manipulation.
Cookies are files stored on a user’s computer which allow a Web application to later identify a returning user, and to store a user’s actions and settings for a particular application. Cookie tampering may be used as a method for session hijacking, where cookies containing session identification information are stolen or modified.
Cross-site request forgery
Attack where the victim is forced to execute unwanted actions on a web application in which he or she is currently authenticated. Through social engineering (like sending a link via email or via chat), an attacker may force the users of a web application to unwittingly execute actions of the attacker's choosing.
Attack where the attacker injects malicious scripts into an otherwise harmless and trusted web site. Other visitors to this site then involuntarily execute these scripts and open themselves up to further attacks such as identity stealing.
Dynamic whitelist filtering
A group of whitelist filtering measures, which are created at the application’s runtime and can constantly adapt to the current usage scenarios. In Airlock, dynamic whitelist filtering is achieved through URL encryption, smart form protection, upstream authentication as well as on-demand whitelist filtering.
Attack where the attacker tries to enumerate and access resources which are not referenced by the attacked Web application, but are still accessible.
A protocol for the communication between proxy servers and their external services. The protocol is related to HTTP and is mainly suited for filtering and modification of data transmitted by reverse proxies. Malware scanners are typically connected to Web application firewalls via ICAP. External filters and other WAF value added services are usually based on ICAP.
Distribution of load over several identical systems. A Web application firewall can perform this task: An application runs on several servers in parallel. As a reverse proxy, the WAF can distribute incoming requests over these servers. Health checks constantly evaluate each server’s availability. Asymmetric load distribution is possible as well.
The filtering of requests to a Web application, offering several levels of maximum protection, while maintaining maximum convenience for the protected Web application’s users. Airlock allows filtering over six levels:
1. Blacklist filtering
2. Static whitelist filtering
3. Dynamic whitelist filtering
4. Filtering of structured data (XML, SOAP, AMF)
5. Malware filtering
6. Application specific filtering.
Attack which aims to access files and directories stored outside the web root folder. Similar to a forced browsing attack, the attacker here uses one or multiple instance of the sequence “../” and its variations to access arbitrary files on the Web server.
A proxy server that retrieves data on behalf of a client from one or several servers. This data is then returned to the client as if it originated from the reverse proxy itself. Reverse proxies are being used to achieve typical Web Application Firewall functionality: SSL termination, upstream authentication, multi-level filtering, as well as load balancing.
Attack where the attacker impersonates another user of a Web application after exploiting the application’s session control mechanism. The attacker compromises the session token by stealing or predicting a valid session token to gain unauthorized access to the application.
Smart form protection
A dynamic whitelist filtering method that protects from form modifications. When activated, it protects drop-down menus, hidden fields and other defined form attributes from unnoticed changes on the client side. Additionally, the server is protected from receiving additional, unwanted form fields.
Attack which consists of insertion, or "injection", of a SQL query via the input data from the client to the application. Such a query may expose confidential data the attacker, or manipulate data in the application’s database.
Sensitive data is usually encrypted for transfer between browser and server – making use of the HTTPS protocol. HTTPS is based on the encryption method SSL. Only the two end points of an HTTPS connection can read the actual data, all intermediaries have no access to this content. Because this encrypted content might be part of an attack, it is essential that safety equipment, like for example a Web application firewall, terminates the SSL protocol. Its goal is to gain access to the data transmitted by the browser. This allows detecting and blocking attacks. Safe transmissions can be re-encrypted if necessary, and then passed on to the server.
Structured data (XML, SOAP, AMF, JSON)
Samples for structured data formats are XML, SOAP (Web service calls, based on XML), AMF and JSON.
A dynamic whitelist filtering method that protects a Web application from forceful browsing: The application’s Web addresses are encrypted before being sent to the client. This prevents an attacker from gaining access to insufficiently protected parts of the application by simply modifying these addresses. This also hides an application’s topology and technology (e.g. PHP) from a potential intruder.
A dynamic whitelist filtering method that protects Web applications from unauthorized access: Before any requests from a user are passed on to an application, upstream authentication ensures that the user is authorized for this access in the first place. This neutralizes the biggest threat to Web applications – attack by an unknown attacker – completely. Delegating authentication to an upstream system, for example a Web Application Firewall, offers an easy way to implement single sign-on scenarios across multiple Web applications.