Web Application and API Protection Quick-Start Guide

Total Uptime’s Web Application and API Protection (WAAP) is an extremely powerful tool to protect web applications at the edge of the Internet as opposed to right inside your datacenter. The WAF shields your network and applications from the ever increasing number of application-layer attacks and can also aid with compliance, like PCI, by helping to prevent information disclosure.

A common request we receive is: “Where do I start with configuring the many options in the WAF?”  We’ve developed this quick-start guide. All of the settings below will provide immediate protection, but will not have adverse affects.

1. Deny URL. If you have any directories on your site that you wish to protect from public access, this is a good one to activate. For example, with a WordPress site, do you really want anyone on the Internet to reach your /wp-admin/ directory? To block this directory, create a new URL entry and set the Deny URL to /wp-admin(/.*)?$  This will block all access to that directory and anything deeper as well. Create as many entries as needed to block the various directories or even specific pages you want to protect.
2. Cookie Consistency. This check examines cookies returned by users to verify that they match the cookies that your website set for that user. If a modified cookie is found, it is stripped from the request before the request is forwarded to the web server. Simply enable this feature for protection. No advanced configuration is needed for most clients.
3. Buffer Overflow. This check prevents attacks against insecure operating-system or web-server software that can crash or behave unpredictably when it receives a data string that is larger than it can handle. Proper programming techniques prevent buffer overflows by checking incoming data and either rejecting or truncating overly long strings. Many programs, however, do not check all incoming data and are therefore vulnerable to buffer overflows. This setting is also easy to check and forget since we’ve configured the advanced settings to reasonable default values already.
4. Credit card. This check prevents unwanted information disclosure of cardholder data. Are you PCI compliant, or do you need to be? This setting is a huge help. Check the box and under the advanced tab, choose which credit cards to block and whether you want to X them out or simply stop the page from loading. This feature is an easy way to prevent a data leak.
5. CSRF Form Tagging. The Cross Site Request Forgery (CSRF) Form Tagging check tags each web form sent by a protected web site to users with a unique and unpredictable FormID, and then examines the web forms returned by users to ensure that the supplied FormID is correct. This check protects against cross-site request forgery attacks. This check applies only to HTML requests that contain a web form, with or without data. It does not apply to XML requests.The CSRF Form Tagging check prevents attackers from using their own web forms to send high volume form responses with data to your protected web sites. This check requires little configuration. Simply check the box to automatically enable this protection.
6. HTML Cross-Site Scripting (XSS). To prevent misuse of the scripts on your protected web sites to breach security, the HTML Cross-Site Scripting check blocks scripts that violate the same origin rule, which states that scripts should not access or modify content on any server but the server on which they are located. Any script that violates the same origin rule is called a cross-site script, and the practice of using scripts to access or modify content on another server is called cross-site scripting. The reason cross-site scripting is a security issue is that a web server that allows cross-site scripting can be attacked with a script that is not on that web server, but on a different web server, such as one owned and controlled by the attacker. Caution: Many companies have a large installed base of JavaScript-enhanced web content that violates the same origin rule. If you enable the HTML Cross-Site Scripting check on such a site, you have to generate the appropriate exceptions so that the check does not block legitimate activity. You can also enable the “Transform cross-site scripts” checkbox on the advanced page using the “more” link for a gentler approach for older sites.
7. HTML SQL Injection. Many web applications have web forms that use SQL to communicate with relational database servers. Malicious code or a hacker can use an insecure web form to send SQL commands to the web server. The application firewall HTML SQL Injection check provides special defenses against injection of unauthorized SQL code that might break security. If the application firewall detects unauthorized SQL code in a user request, it either transforms the request, to render the SQL code inactive, or blocks the request. The application firewall examines the request payload for injected SQL code in three locations: 1) POST body, 2) headers, and 3) cookies.A default set of keywords and special characters provides known keywords and special characters that are commonly used to launch SQL attacks. You can add new patterns, and you can edit the default set to customize the SQL check inspection. The application firewall offers various action options for implementing SQL Injection protection. The WAF profile also offers the option to transform SQL special characters to render an attack harmless. This may be a desirable initial setting to prevent significant impact to an existing site. Simply check “Transform SQL special characters” under the “more” link in the advanced page.
8. XML Denial of Service. Running an XML-based API? Consider enabling this feature and activating the element checks on the advanced section based on your knowledge of your API to protect against attacks that attempt to overwhelm your servers.
9. XML SQL Injection. A XML SQL attack can inject source code into a web application such that it can be interpreted and executed as a valid SQL query to perform a database operation with malicious intent. For example, XML SQL attacks can be launched to gain unauthorized access to the contents of a database or to manipulate the stored data. XML SQL Injection attacks are not only common, but can also be very harmful and costly. This is an easy feature to implement. Simply check the box. No advanced configuration is necessary.

Of course, we’re here to help! If we can provide any guidance or configuration assistance, simply reach out to us by creating a support case.