Working with SQL injection and cross-site scripting conditions

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:

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.

1. Next, select the SQL Injection option from the navigation pane and, within that, select the Create condition to get started.
2. 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:

1. 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:

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.

1. Next, select the Cross-site scripting option from the navigation pane and, within that, select the Create condition to get started.
2. 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.
3. 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.
4. 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.