Some problems when using AWS WAF

“Honey, I did a search and it returned an error 403”, “Bro, I could not submit the registration form with the attached upload image”, …. is one of the recent questions I have encountered after when deploying web application on the Amazone Web Service (AWS) platform. Why? Due to bug or server problem, when everything is working properly under local machine and there is no error log on server? Finally, I “fell back” when I knew the reason lies in the WAF service (Web Application Firewall) is set up on the server.

WAF is a firewall service dedicated to web applications of AWS. Through ruleset, WAF helps to prevent security risks and some common types of network attacks such as XSS, SQL Injection, …

So why does a good service fail the application functionality? When I checked the WAF request log, I found out that a number of requests were blocked due to a violation of the AWF rule. And of course, the functionality of the application only fails in certain cases. From there it can be concluded that WAF detected some requests as malicious or “misunderstood” a request as false positive. The consequence is a response with a 403 status code returned to the client.

The simplest way in the above scenarios is to disable the corresponding WAF rule. However, security will need to be considered before you can disable it.

This article will go through some common WAF rules and the alternative security options for disabling these rules.

SizeRestrictions_BODY

Verifies that the request body size is at most 10,240 bytes.

Block requests with content more than 10MB.

For applications that involve large image uploads, we might consider disabling this rule and performing application layer validation. Alternatively, you can incorporate validate on the client side to reduce the load on the server side.

GenericLFI_QUERYARGUMENTS, GenericLFI_BODY

GenericLFI_QUERYARGUMENTS

Inspects for the presence of Local File Inclusion (LFI) exploits in the query arguments. Examples include path traversal attempts using techniques like ../../.

GenericLFI_BODY

Inspects for the presence of Local File Inclusion (LFI) exploits in the request body. Examples include path traversal attempts using techniques like ../../.

Block requests containing content with the risk of LFI attacks.

LFI is a type of attack where hackers can exploit a web application to access or execute sensitive files on the server by transmitting directory browsing code. For example ../..

For PHP applications, this type of attack can be prevented by disabling the allow_url_include option in the php ‘s config.

GenericRFI_QUERYARGUMENTS, GenericRFI_BODY

GenericRFI_QUERYARGUMENTS

Inspects the values ​​of all query parameters and blocks requests attempting to exploit RFI (Remote File Inclusion) in web applications. Examples include patterns like :// .

GenericRFI_BODY

Inspects the values ​​of the request body and blocks requests attempting to exploit RFI (Remote File Inclusion) in web applications. Examples include patterns like :// .

Block requests containing content with the risk of RFI attacks.

Similar to the LFI (Local File Inclusion) attack, this is also an attack that transmits malicious code to perform unauthorized actions.

• An example of a malicious script in the form of RFI: the content of the request contains the character ://
• The difference from LFI: instead of inserting malicious code to access system files, RFI will pass in the path of files on other systems:

  https://malicious.domain/bad-scripts.php

For PHP applications, this type of attack can be prevented by disabling the allow_url_include option in the php ‘s config.

Note: When this option is disabled, the ability to open remote URLs in PHP will not work. Therefore, it is necessary to check whether the current library or function uses fopen (for example, the AWS SDK for PHP library). An alternative solution is to use php-extension curl and use curl to retrieve data from remote URLs.

CrossSiteScripting_QUERYARGUMENTS, CrossSiteScripting_BODY

Inspects the value of query arguments and blocks common cross-site scripting (XSS) patterns using the built-in XSS detection rule in AWS WAF. Example patterns include scripts like <script> alert (“hello”) </script>.

Block requests containing content with the risk of XSS attacks.

This is the type of attack where hackers transmit scripts to perform malicious intentions on the compromised application, such as stealing account information, redirecting users to malicious websites, …

With the Laravel framework, this kind of attack can be prevented with the help of the escape string {{ }} syntax. However, for root resolution, data saved to the database needs to be escaped first. In addition, when displaying the content entered by the user, it is necessary to check and thoroughly and fully handle the possible cases.

If you are uncertain about ensuring application-layer XSS prevention, this rule should not be disabled.

EC2MetaDataSSRF_BODY

Inspects for attempts to exfiltrate Amazon EC2 metadata from the request body.

Intercepting requests that are vulnerable to SSRF attacks via metadata.

This rule can “misunderstand” a normal file containing malicious content when analyzing abnormal data within the file’s metadata.

Without an alternative precaution, we should not disable this rule.

Instead, you can intervene by removing the file’s metadata through the exif tools

SQLi_BODY

Uses the built-in AWS WAF SQL injection match statement to inspect the request body for patterns that match malicious SQL code.

Blocking requests that are at risk of SQL Injection attack.

For today’s new frameworks, this type of attack is preventable, but not completely guaranteed. Hence, we should still set this rule up in the WAF.

There is a rare case in which this rule could misinterpret the request (false positive) to be malicious when uploading files in binary format. One possible solution is to encrypt the file to base64 or compress the file before uploading it.

Note: Make sure the file before encryption or compression is not malicious. If not, take security measures after decrypting or decompressing the file.

Conclude

These are just a few cases where using WAF can cause conflicts or unexpected application operations. Therefore, before setting up a certain firewall rule, it is important to consider the possible data scenarios to avoid unnecessary problems.

Refer

AWS, AWS Managed Rules rule groups list

Srinivas, PHP Lab: File Inclusion attacks

PHP, Runtime Configuration

AWS, How do I upload files that are blocked by AWS WAF?