Besides restricting access to a specific set of IP addresses, WAF additionally provides defense capabilities against more exploitative attacks, such as SQL injections and cross-site scripting. In this section, we will take a closer look at both of these conditions and how you can leverage them for protecting your own applications.
To start off, let's have a closer look at SQL injections. An SQL injection basically consists of the insertion of an SQL query within a request that is made from a client to your application.
SQL injections, if successfully implemented, can read as well as modify sensitive data from the database, and are even capable enough to execute administration operations on your database, such as restoring from a previous backed up file, shutting the database down completely, and much more.
Here's a list of some common conditions and their associated configurations that you can choose to apply in your web ACL rules:
|
HTTP request component to match |
Relevant input transformations to apply |
Justification |
|
QUERY_STRING |
URL_DECODE, |
The most common component to match. Query |
|
URI |
URL_DECODE, HTML_ENTITY_DECODE |
If your application is using friendly or clean URLs, then parameters might appear as part of the URL path segment, and not the query string. |
|
BODY |
URL_DECODE, HTML_ENTITY_DECODE |
A common component to match if your application accepts form input. AWS WAF only evaluates the first 8 KB of the body content. |
|
HEADER: Cookie |
URL_DECODE, HTML_ENTITY |
A less common component to match. But, if your application uses cookie-based parameters in database lookups, consider matching on this component as well. |
|
HEADER: Authorization |
URL_DECODE, HTML_ENTITY_DECODE _DECODE |
A less common component to match. But, if your application uses the value of this header for database validation, consider matching on this component as well. |
To configure your own SQL injection conditions and rules, log in to your WAF dashboard once again by navigating to https://console.aws.amazon.com/waf/home.
- Next, select the SQL Injection option from the navigation pane and, within that, select the Create condition to get started.
- In the Create SQL injection match condition page, start off by providing a Name for your new condition. You can additionally select whether you want to enable this condition for your CloudFront CDNs (Global) or for your individual Application Load Balancers. In this case, I've opted for the Global (CloudFront) option, as depicted in the following screenshot:
- Next, in the Filter settings section, select the appropriate Part of the request to filter on as well as the associated Transformation section. You can refer to the SQL injection common conditions table, as discussed previously, for the same. Once the values are provided, click on the Add filter option to complete the process.
Now, here's a really handy tip! There will definitely be cases where you will be writing more than one filter for your SQL injection condition based on different parts of the request you wish to filter, such as URI, query string, and so on. In such cases, it is always recommended to create multiple filters within the same SQL injection condition and then attach that one condition to a web ACL rule. The reason? A web request needs only to match one of the filters in the SQL injection match condition for WAF to allow or block the request based on that condition. On the other hand, if you add only one filter per SQL injection match condition, and you create more than one such SQL injection condition, the request has to match all the conditions in order for WAF to allow or block it.
The same can also be applied for protection against cross-site scripting or XSS. Cross-site scripting generally occurs when web applications include user-provided data in web pages that is sent to the browser without proper sanitization. If the data isn't properly validated or escaped, an attacker can use those vectors to embed scripts, inline frames, or other objects into the rendered page. These, in turn, can be used for a variety of malicious purposes, including stealing user credentials by using keyloggers, installing system malware, and much more. The impact of the attack is magnified if that user data persists on the server side in a data store and is then delivered to a larger set of users.
Here's a list of some common conditions and their associated configurations that you can choose to apply in your web ACL rules:
|
HTTP request component to match |
Relevant input transformations to apply |
Justification |
|
BODY |
URL_DECODE, HTML_ENTITY_DECODE |
A very common component to match if your application accepts form input. AWS WAF only evaluates the first 8 KB of the body content. |
|
QUERY_STRING |
URL_DECODE, HTML_ENTITY_DECODE |
Recommended if query string parameters are reflected back into the web page. An example is the current page number in a paginated list. |
|
HEADER: Cookie |
URL_DECODE, HTML_ENTITY_DECODE |
A common component to match if your application accepts form input. Recommended if your application uses cookie-based parameters that are reflected back on the web page. For example, the name of the user who is currently logged in is stored in a cookie and embedded in the page header. WAF only evaluates the first 8 KB of the body content. |
|
URI |
URL_DECODE, HTML_ENTITY_DECODE |
Less common, but if your application is using friendly URLs, then parameters might appear as part of the URL path segment, not the query string (they are later rewritten server side). There are similar concerns as with query strings. |
To configure your own cross-site scripting conditions and rules, log in to your WAF dashboard once again by visiting https://console.aws.amazon.com/waf/home.
- Next, select the Cross-site scripting option from the navigation pane and, within that, select the Create condition to get started.
- In the Create cross-site scripting match condition page, start off by providing a Name for your new condition. You can additionally select whether you want to enable this condition for your CloudFront CDNs (Global) or for your individual Application Load Balancers. In this case, I've opted for the Global (CloudFront) option for now.
- Next, from the Part of the request to filter on section, select the part of the request you wish WAF to filter on. You can choose between Header, HTTP method, Query string, URI, and Body as valid parameters. Note, however, that by selecting the Header option, you will be provided with an additional field in which you can either select the header from a list of headers or, alternatively, type in the name of the header.
- Finally, select the appropriate Transformation operation you wish WAF to perform over the request before it is actually inspected. Once done, remember to select the Add filter option before completing the condition's creation process.
You now have two additional conditions that you can add to your existing web ACL, or even, go ahead and create a new web ACL. In this way, you can create different filters and conditions based on your requirements and keep attaching them to your web ACL as and when required. But this manual way of setting up rules and conditions can get a bit tricky after some time, especially when you don't have a dedicated security team and need to deploy the ACLs a lot faster into your environment. That's precisely what we are going to cover in the next section.