The Most Dangerous Cyberattack (and how to prevent it)
The Most Dangerous Cyberattack – What is the most dangerous form of attack against a web application or site?
You might think the answer is DDoS (Distributed Denial of Service). Large DDoS attacks can be very dramatic, and they often appear in the news. For example, in February an AWS customer was hit by a record-shattering 2.3 terabit-per-second assault that lasted for three days.
Or perhaps you think the answer is database breaches. Large-scale database compromises are also frequently reported, and one incident can affect millions of people. For example, the Equifax breach in 2017 exposed sensitive data (including birthdates and Social Security numbers) for almost 150 million consumers.
Or maybe you think the worst threat is ransomware, where the attacker penetrates the victim’s system, encrypts the victim’s data, and demands a ransom to make it accessible again. One notorious example was the WannaCry attack that affected 200,000 computers across 150 countries.
Many people are surprised to hear that none of these answers are correct. Arguably, the most dangerous cyberthreat is the injection attack. Indeed, OWASP (the Open Web Application Security Project®), in its list of the Top 10 Web Application Security Risks, lists injection as the top item.
There are several reasons for this. First, an injection attack is often the first step in other types of attack, such as data theft, system compromises leading to ransomware installation, and so on. So, a successful injection can enable many other forms of attack. Also, there are a large number of ways in which a system can be vulnerable to injection, so a proper defense requires planning and diligence.
Fortunately, although there are many ways in which a web application can be vulnerable to injection, there are some straightforward security principles that can protect your networks against it. But before we can discuss them, we should discuss injection, and how it works.
The Most Dangerous Cyberattack – What is an Injection Attack?
Injection occurs when the attacker submits malicious inputs to an interpreter as part of a command or query. To illustrate how this works, let’s look at four common examples.
SQL Injection: This occurs when an attacker successfully submits malicious SQL commands to a database. For example, let’s say a web application accepts a customer’s username, and then retrieves account information by building this query string from it:
string query = “SELECT * FROM accounts WHERE customer = “‘” + userName + “‘;”
In normal use, this query will return a single record: the one associated with the specified customer. But the attacker abuses it by submitting this value for userName:
foo’ OR ‘a’=’a
Thus, the query string that is built will be this:
SELECT * FROM accounts WHERE customer = ‘foo’ OR ‘a’=’a’;
Notice that the “WHERE” condition now contains a logical OR condition that will be true for every record in the table. Therefore, depending on how the web application is coded, the query might display the contents of the entire table – and show the details of every customer account – to the attacker.
A successful SQL injection can result in the attacker stealing large amounts of data without even needing to breach the victim’s network.
Code Injection: Here, the attacker attempts to manipulate the targeted system into executing malicious code. For example, let’s say a web application links to internal pages using this format:
An attacker can refer to a malicious PHP file in the URL (thus using injection to create an RFI: a Remote File Inclusion attack) as follows:
A poorly coded web application will accept this, and the server will process and execute the code that the malicious page contains. A successful code injection of this kind can compromise data confidentiality and availability, or even compromise the server itself.
Command Injection: In this attack, hackers attempt to execute commands against the operating system itself. For example, the following code is used to display the contents of a file within the application:
$file = $_GET[‘filename’];
$contents = shell_exec(“cat $file”);
A normal use would be something like this:
But an attacker might abuse it like this:
…which will attempt to list the names of all files in the current directory, and then delete them.
Cross Site Scripting (XSS): An XSS attack occurs when an attacker inserts malicious code into a web application. For example, many sites accept user-generated content such as comments or product reviews; an attacker might abuse this by submitting content that contains a malicious script. Subsequent visitors to the site will have that code run within their browsers. The attacker can then access session cookies and other sensitive information maintained by the visitors’ browsers, possibly hijacking user accounts and performing other mischief as well.
SQL injection, code injection, command injection, and XSS are all very common on the web today. And along with these four, there are other types of injection as well. By now it should be clear that injection attacks are a serious threat, not only in their own right but also in the subsequent attacks that they enable.
Fortunately, there are some straightforward best practices that can minimize the risk of successful injections.
The Most Dangerous Cyberattack – How to Mitigate Them
Preventing injections is a very broad topic, of course. But many best practices fall into just five categories: update, limit, constrain, sanitize & validate, and filter.
Update: Make sure all frameworks, libraries, and other dependencies are kept current; whenever a vendor issues an update, install it immediately (this seems obvious, but many security incidents still occur because organizations don’t do this consistently). Additionally, evaluate your web applications – are they based on older technologies that should be upgraded? For example, the latest Java and .NET libraries make successful SQL injection much less likely.
Limit: The permissions for web applications and users must be limited to the minimum that is necessary to accomplish the intended purposes. This will limit the potential damage that an attacker can do. For example, most database access should be done without DDL privileges.
Constrain: Wherever possible, constrain the ranges and types of inputs that a user can submit, or that the application will accept. For example, the UI should use pulldowns wherever possible instead of textboxes. Rather than building SQL query strings directly from user inputs, use prepared statements/parameterized queries instead. And so on.
Sanitize and Validate: All inputs must be sanitized (i.e., modified if necessary) and validated (verified). Sanitization will modify unwanted content in the input: for example, HTML tags and special characters are removed, single quotes are converted into double quotes, and so on. Validation then confirms that the sanitization was successful, and that the input is legitimate; ideally, this includes validating the input against a schema.
Although this concept is simple, the execution can be difficult. Fortunately, most frameworks include validation libraries. Use them! Also ensure that validation is done at the server; even if client-side validation is performed, this can be bypassed by an attacker, so don’t rely on it. Lastly, outputs should also be sanitized if possible. For example, a web application should not return detailed error messages in its responses, since hackers can use these to learn about the backend’s architecture and behavior.
Filter: It can be extremely tedious and error-prone to include sanitization and validation for every possible input in a web application. The problem is even more challenging in modern environments; DevOps and other practices have accelerated the pace of software development and delivery. Unfortunately, this makes it easy to leave security holes in Internet-facing applications.
Modern cloud security platforms can solve this problem. A WAF (web application firewall) solution that runs in the cloud can act as a reverse proxy, filtering and scrubbing all incoming requests with near-zero latency. A good WAF can filter—i.e., detect and block—injection attacks and other forms of hostile traffic before they reach the targeted application. Thus, whatever holes are present in the application will be irrelevant, because the attacker cannot reach it.
This advice might seem obvious, because WAFs have been around for many years. But there is a key difference here: traditional WAFs are sold as on-premise appliances. These have disadvantages when compared to new cloud-based solutions: among other things, they are complicated to administer, they require a certain level of expertise from IT staff to be configured correctly, and they require frequent updates. Meanwhile, the best cloud solutions are fully managed by the vendor, and are updated automatically as new Internet threats arise.
Of course, this does not remove the need for building security into your web applications. But a good cloud-based security platform will include sophisticated detection abilities for a wide variety of threats, and will include DDoS protection, bot mitigation, API protection, etc.
Today’s cloud-based security solutions are straightforward to deploy and have other features besides the ones described here. If you have not seriously considered them before, perhaps you should do so now. You might find their benefits quite compelling.
The Most Dangerous Cyberattack (and how to prevent it)