InfoSec Guide: Web Injections

Web injections are every programmer, developer and information security (InfoSec) professional’s headache—and a permanent fixture in a cybercriminal’s toolkit. Cross-site scripting, and command, SQL and XML injections, in particular, are some of the most widespread threats against websites and web-based applications due to the many ways they can be executed. The intricacy often involved in defending against them also adds to the challenge.

Securing these platforms from which personal and financial data change hands is part and parcel for an enterprise’s operations, reputation, and bottom line. Here’s a glance at four of the most prevalent web injection attacks information security professionals contend with:

SQL Injection (SQLi)

SQL injection is used to compromise database-driven software and is considered by the Open Web Application Security Project (OWASP) as one of the most critical and common techniques used to breach websites and SQL databases. SQLi inserts malicious SQL statements into entry fields (as part of a command or query), and exploits the software or web application’s security flaws—such as when user input is incorrectly filtered. For instance, an attacker can use a malicious input that, when used as an argument to an SQL query, will be interpreted as part of an SQL command that the database then executes.

A successful SQLi attack allows hackers to spoof their target’s identity and gain administrator privileges to the database server. Attackers can then modify existing data such as voiding transactions, leak data in the system, and destroy, overwrite, or delete data and even render it inaccessible. This has been the technique of choice for bug poachers who extort enterprises for bounties in exchange for information on how they breached their network, or bad guys who delete the website's content, and masquerade their activities as ransomware. SQLi has also been used to deface various websites and expose the personal identifiable information, credentials, and sensitive company data stored on the databases.

Command Injection

While SQLi attacks target database-related web applications/services, a command injection enables attackers to insert malicious shell commands to the host’s operating system (OS) that runs the website. An example would be finding out the directory where an application is installed, then running a malicious script from there. Command injection attacks allow hackers to execute arbitrary commands within vulnerable web applications—such as when an application relays malicious user-generated data in forms, HTTP headers, and cookies to a system shell. Attacks of this kind are typically executed with privileges on the unsecure application.

Simply put, command injections occur when malicious inputs are misinterpreted as an OS command, and can be used to give bad guys gaining control over file or web servers. The Shellshock attacks of 2014 are a case in point: they allowed attackers to modify the web server’s content, change the website’s source code, steal or leak data, change permissions, and install malware such as backdoors. Email-sending libraries also made headlines when vulnerabilities related to their website components were found, such as contact, registration, and password email reset forms.

XML External Entity Injection (XXE)

This kind of attack isn't as commonly used as SQLi or cross-site scripting, but XML External Entity Injection (XXE) has recently gained traction. XML (Extensible Markup Language) supports external entities that can be used to reference and invoke data outside the main file into an XML document. XXE attacks leverage flaws or weaknesses in how web applications parse XML inputs from an unknown or suspicious source. Malicious content is injected into a document (an XML file, for instance) where user-generated or customer data are imported into an application.

Successful XXE attacks let hackers access internal networks or services, read system files stored on servers, and scan for internal ports. In certain situations, XXE can allow attackers to do remote code execution (by loading malicious, executable PHP code, for instance). These depend on the permissions granted to the parser.

XXE was employed as a foothold to execute remote code against Facebook, resulting in one of its highest bug bounties. XXE vulnerabilities were also recently uncovered in an updater framework commonly used in Mac applications, an XML parser in Adobe’s ColdFusion (CVE-2016-4264), a feature in Google’s search engine, and the PHP toolkit (Zend) used by Magento.

Cross-site Scripting

Exploiting cross-site scripting (XSS) flaws enables bad guys to inject malicious scripts into the user’s web browser. OWASP’s latest data cited XSS as the top security risk, often employed in website defacements and automated cyberattacks.

XSS-based attacks vary, depending on how these codes are injected and the attackers’ motivations. XSS attacks can be found in webpages that process user input such as databases, login and search forms, comment fields, and message boards/forums (stored XSS). Error and search result pages, where input is sent to the server as part of a request, can also be misled into relaying malicious scripts injected by the attacker (reflected XSS). Attackers can also modify the Document Object Model (DOM) in the victim’s web browser in order to execute their payload (DOM-based XSS).

The impact ranges from nuisance to major security risk—marring the website with inappropriate content, stealing or altering session and authorization cookies, generating requests that can be misinterpreted as valid, diverting users to malicious websites, hijacking the victim’s account, causing websites to have outages, or delivering malware to the system. Attacks on Yahoo!, Wordpress (via vulnerable plug-ins), and websites/domains from Google Docs and Google Developers (via flaws in the Caja toolkit), as well as e-commerce and web development platforms Magento and Wix, were just some of 2016’s most notable incidents involving cross-site scripting.

Safety Tips

As with most things, an ounce of prevention is better than a pound of cure. Here are some countermeasures that IT professionals and web developers/programmers can employ to mitigate, if not thwart, these attacks: