Introduction

Automated security testing technologies, such as those, which rely on scanning, fuzzing and sending arbitrary malicious data to detect security problems, can seriously damage the web applications they are used to test. Therefore, it is often recommended to perform automated tests only against systems in demo, testing or pre-production environments.

To understand the implications when using automated security testing tools, consider the following scenario. If you target a web application which performs many database operations, such as updating or inserting new records, an automated security tool may not only lead to unnecessary load resulting in a form of a Denial of Service attack, but it may also cause unnecessary bogus records to be inserted into the backend database. In the case of the former it will be required an extensive database clean up, which may not always be a trivial task.

Some of the side effects when using automated security testing tools are summarised bellow:

• Denial of Service (DoS).
• Record of bogus information in databases and log files.
• Trigger of unnecessary or false security alarms.
• System crash, malfunction and general instability.

A combination of automated and manual testing is often the only way to minimise any damage during testing and maximise vulnerability detection coverage.

Automated testing with Websecurify

Websecurify offers several key features to minimize the possibility of damage even when testing applications in production environments.

Adjustable Testing Scope

Websecurify provides trivial to use, adjustable testing scope. You can easily configure the tool to skip certain parts from your application, which are known to be unstable or not fully functional.

Runtime Analytical Engine

Websecurify employs an advanced analytical engine, which dynamically adjusts to the application environment. This offers several benefits. First, it reduces testing time. Second, the tool will send the least number of requests required to detect a security defect. This, as a result, reduces the potential damage when testing poorly written or configured web applications.

Identifiable Testing Headers

Websecurify supplies the X-Websecurify-Request HTTP header for every request during any automated scanning/testing activities. This header can be easily detected by your application or even the web application firewall and as such prevent unwanted/unplanned scanning activities.

Let’s consider the following scenario. In testing and pre-production environments, it is not only preferable but a requirement to use Websecurify in order to spot web application vulnerabilities early in the development stages of your web application. Due to various concerns, such testing activities are not allowed on the production environment. To minimize the risk of incidental damage, the web application firewall is configured to detect the X-Websecurify-Request HTTP header and block access to the application effectively making scans from within Websecurify impossible.

A Word of Caution

It is essential to understand that although Websecurify provides facilities by which you can control the tool’s behaviour, there is no mechanism on the Web, which governs how your application will be accessed and used. Therefore, it is advisable to program your web application with security in mind and ready for the worst-case scenario. In other words, your application must be able to handle any kind of malicious traffic generated by Websecurify and other automated tools. Any malicious usage should not affect your web application day-to-day activities and normal operation.