TECHNICAL FIELD

Embodiments of the invention relate to the field of computer network security, and more specifically, to predictively activating security rules to protect web application servers against web application layer attacks.

BACKGROUND

The content of Hypertext Transfer Protocol (HTTP) messages is transmitted within the application layer (“Layer 7”) of the Open Systems Interconnection (OSI) model (ISO/IEC 7498-1), and may also be referred to as web application layer data. The OSI model was developed to establish standardization for linking heterogeneous communication systems and describes the flow of information from a software application of a first computer system to a software application of a second computer system through a communications network. The OSI model has seven functional layers including a physical link layer, a data link layer, a network layer, a transport layer, a session layer, a presentation layer, and an application layer. A few examples of application layer protocols include, but are not limited to, HTTP for web application communication, File Transfer Protocol (FTP) for file transmission, Internet Message Access Protocol (IMAP) and Post Office Protocol (POP) for email, Simple Mail Transfer Protocol (SMTP) for transmitting email, Internet Relay Chat (IRC) for real-time Internet text messaging, Session Initiation Protocol (SIP) for voice and video calling, and Network File System (NFS) for the remote access of files.

Another model detailing communications on the Internet is known as the Internet Protocol (IP) suite and is sometimes referred to as “TCP/IP.” In contrast to the OSI model, the Internet protocol suite is a set of communications protocols including four layers: a link layer, an internet layer, a transport layer, and an application layer. The link layer of the Internet protocol suite, which provides communication technologies for use in a local network, is often described as roughly analogous to a combination of the data link layer (layer 2) and physical layer (layer 1) of the OSI model. The internet layer (e.g., IP version 4 (IPv4) and IP version 6 (IPv6)) of the Internet protocol suite, which provides for inter-networking and thus connects various local networks, is often described as roughly analogous to the network layer (layer 3) of the OSI model. The transport layer (e.g., Transmission Control Protocol (TCP), User Datagram Protocol (UDP)) of the Internet protocol suite, which allows for host-to-host communications, is often described as roughly analogous to the transport layer (layer 4) of the OSI model. Finally, the application layer of the Internet protocol suite includes the various protocols (e.g., HTTP, IMAP, FTP, SIP) for data communications on a process-to-process level and is often described as analogous to a combination of the session, presentation, and application layers (layers 5-7, respectively) of the OSI model.

Regardless of the model considered, many common attacks are targeted at aspects of the network layer, the transport layer, and the application layer. The network layer, which is under the transport layer and routes data supplied by the transport layer, manages delivery of packets between computing devices that may be connected to different networks and separated by one or more other networks. The network layer is responsible for logical addressing, which includes managing mappings between IP addresses and computing devices on a worldwide basis. The network layer is also responsible for ensuring that packets sent to computing devices on different networks are able to successfully navigate through the various networks successfully and arrive at the proper intended destinations. Network devices such as routers and gateways predominantly operate at the network layer. The transport layer, which is under the application layer, provides end-to-end communication services by providing reliable delivery of an entire message from a source to a destination, sometimes using multiple packets. While the network layer typically handles each packet independently, the transport layer manages the relationships between the packets to ensure that the entire message arrives at the destination and can be reassembled in the correct order to recreate the original message. The application layer typically operates as the top layer in networking models and carries application-specific data, such as HTTP request and response messages.

Application layer attacks typically target web applications implemented by web application servers (in which case, they are referred to as web application layer attacks). A web application server is system software (running on top of an operating system) executed by server hardware upon which web applications run. Web application servers may include a web server (e.g. Apache, Microsoft® Internet Information Server (IIS), nginx, lighttpd), which delivers web pages on the request of web application clients (e.g., using HTTP), and may also include an application server that executes procedures (i.e., programs, routines, scripts) of a web application. Web applications are computer software applications made up of one or more files including computer code that run on top of web application servers and are written in a language the web application server supports. Web applications are typically designed to interact with web application clients by dynamically generating web application responses (e.g., HTTP response messages) responsive to web application requests (e.g., HTTP request messages) sent by those web application clients. Many web applications use databases (e.g., relational databases such as PostgreSQL, MySQL, and Oracle, and non-relational databases, also known as NoSQL databases, such as MongoDB, Riak, CouchDB, Apache Cassandra and HBase) to store information received from web application clients and/or information to be displayed to web application clients.

Web applications clients access web applications by sending web application layer requests to web application servers, which execute portions of web applications and return web application data/content (e.g., HyperText Markup Language (HTML) page) in the form of web application layer responses (e.g., HTTP response messages) back to the web application clients, where the web application data/content may be rendered by the web application clients. The web application data/content may include, for example, public web pages (e.g., free content, store fronts, search services) and/or private web pages (e.g., username/password accessed web pages providing email services). Thus, web applications may be provided using a request-response protocol (e.g., HTTP) in a client-server computing model, where the web application servers typically act as the “server” and the web application clients typically act as the “client.” By way of an operational example, a web application client may request a web page from a web application server by sending it an HTTP request message. For example, to access the web page corresponding to the Uniform Resource Locator (URL) of “http://www.example.org/index.html”, the web browser may connect to the web application server at www.example.org by sending it an HTTP request message using a “GET” method, which may look like the following:

GET/index.html HTTP/1.1

Host: www.example.org

The web application server may reply by sending a set of HTTP headers along with the requested web page, which collectively is called an HTTP response message.

Many web applications use databases to store and provide data used by the web application, including but not limited to user data (passwords, user names, contact information, credit card information, web application history, etc.) and other site-specific data including but not limited to stories, comments, pictures, product information, sales information, financial records, and any other type of information used by or displayed by a web application. Because these databases often store confidential or private information, the databases are often configured to only provide access to the data stored therein to a limited number of users, geographic locations, and/or computing devices.

However, due to the sensitive and important data in these databases, they are often targeted by third parties seeking unauthorized, and possibly malicious access. For example, attackers may attempt access data of a web application by performing a variety of attacks on the web application servers such as SQL Injection attacks, Remote Code Execution (RCE) attacks, Remote File Inclusion (RFI) attacks, Cross-Site Scripting (XSS) attacks, Cross-Site Request Forgery (CSRF) attacks, file upload attacks, backdoor communication attacks, Remote File Inclusion (RFI) attacks, and directory traversal attacks.

Given this reality, security devices such as web application firewalls are commonly deployed to look for and prevent such attacks within web application layer traffic (e.g., HTTP traffic). In particular, a web application firewall can examine traffic (e.g., on a packet-by-packet basis) using a set of security rules to detect attacks of certain attack types. Each security rule typically includes a rule identifier (ID), which serves to uniquely identify that particular rule. Each security rule also typically includes a set of one or more conditions that define what to look for in traffic and a set of one or more actions to be performed when the conditions are satisfied. A condition may be specified using one or more attributes. An attribute is a combination of an attribute identifier and a set of one or more attribute values. Attribute identifiers can identify particular protocol headers (e.g., a TCP header, an HTTP header) and/or header fields (e.g., a source or destination port of a TCP header and a Referer HTTP header field) used within a packet. Attribute identifiers can also identify metrics or characteristics of traffic that an attribute value represents. For example, an attribute identifier may be a number of packets or HTTP messages received over a defined period of time, and the corresponding attribute value may be that particular number of packets or HTTP messages. Of course, the use of metrics or characteristics as attribute identifiers requires that the system have some way of determining the attribute values, such as by maintaining a separate table or database with relevant data necessary to perform the computation. Attribute identifiers may also identify portions of application layer data carried by packets, such as an HTTP request message, an HTTP response message, a SQL query, etc. A condition may be specified as an exact match of an attribute value with a specific value or a set of values (e.g., look for blacklisted IP addresses), a pattern match of an attribute value against specific patterns (e.g., using regular expressions), and/or a deviation of an attribute value from a baseline (e.g., non-digit characters appearing in a field that was learned to be an integer type field).

As noted above, each security rule also includes one or more actions to be performed when the conditions of the security rule are satisfied (a security rule is said to be “triggered” when the condition of the security rule is satisfied). Actions can indicate one or more forwarding actions (e.g., drop the packet or message, temporarily hold the packet or message for further analysis, transmit the packet or message to a particular module or IP address, forward the packet or message to the intended destination, etc.) or modification actions (e.g., insert a value into the packet or message at a particular location, strip out a value from the packet or message, replace a value in the packet or message, etc.). Additionally, many other types of actions are well known to those of ordinary skill in the art (e.g., generate an alert to notify an administrator), and thus these examples are not exhaustive.

A web application firewall typically sits in front of web application servers to protect the web application servers from attacks by web application clients. The web application firewall can see the traffic being sent between the web application clients and the web application servers, including web application layer requests (e.g., HTTP request messages) sent by the web application clients to the web application servers, and can scan these requests for attacks (e.g., based on applying security rules).

When a web application firewall sees a web application layer request being sent to a web application server, it scans the request for attacks (e.g., which may involve applying various security rules to the request, as mentioned above). If the web application firewall detects an attack in the request (e.g., a security rule is triggered), then it takes the appropriate security measures (e.g., perform the actions specified by the security rule that was triggered). Otherwise, if the web application firewall does not detect an attack in the request, then it sends the request to the web application server that the request is intended for.

A web application firewall typically applies security rules in “block” mode (e.g., block the traffic from proceeding towards the web application server) or “do not block” mode (e.g., generate an alert but allow the traffic to proceed towards the web application server). Some security rules are known to create false positives and thus a decision has to be made whether to apply such security rules in “block” mode, thereby harming usability (false positives will cause legitimate traffic to be blocked), or to apply such security rules in “do not block” mode (or not applying the security rule at all), which harms security (by allowing potentially malicious traffic to proceed towards the web application server). With web sites and web application layer attacks becoming more sophisticated, this problem is unlikely to disappear.

