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.

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:

Trust no one. Web developers must assume that all user-generated input are malicious. Their validation and sanitation are a must. Whitelisting—rejecting all input except those in the whitelist—is one of the ways input can be securely handled. When coding websites and web applications, consider terminating execution if input problems occur, such as the use of unexpected characters, and filtering and encoding inputs to keep them in check. Some programming languages have taint-checking features that can inspect and prevent inputs from being used to execute malicious commands. How output is handled should also be verified. Web programmers should escape encode the output with their alternative iterations to sanitize characters and prevent them from behaving unexpectedly.

Design with security. Web programmers must apply secure coding practices throughout the development lifecycle to help maintain the privacy, integrity and accessibility of data that will be processed by their web application/page. Stringently validating untrusted data in Cascading Style Sheet (CSS) properties, HTML attributes, and XML parser, for instance—while also retaining the look and feel of the website/application—is a must to fortify it against intruders.

Keep abreast. IT professionals must regularly apply the latest updates and patches to prevent security flaws in the system and its software from being exploited. Developers must also stay up-to-date with best coding practices. Information security awareness training and audits should also be considered in the workplace.

Don’t complicate things. Whenever possible, developers should avoid using tools and programming techniques that are susceptible to attacks. An example would be using prepared and parameterized statements or queries, and stored procedures instead of dynamic SQL. Disabling the parsing of external entities also helps mitigate XXE-based denial-of-service attacks.

Inspect the wall (or build a castle). IT professionals should be on the lookout for malicious and suspicious data or traffic traversing the network. Inspect the connection as well as requests and responses within websites or web applications, such as HTTP, HTTPS, Simple Object Access Protocol (SOAP), and XML remote procedure calls, among others. Check for code artifacts that can indicate an XSS attempt, for instance. Web application firewalls (WAFs) help do this; WAFs also have filters that can scrutinize message scripts (i.e. JavaScript), and offer some protection against vulnerability exploits. Developers can consider a defense-in-depth (castle approach) security posture: layering defense mechanisms in their websites or web applications to reduce the chances of a successful attack.

Lessen your exposure. Developers should disable components that aren’t necessary to the website, database, or web application’s functionality. Sometimes they can even increase your attack surface. For instance, capabilities that elevate privileges and spawn command shells can be useful for hackers looking into hijacking SQL server service accounts. Preventing the upload of documents with entity declarations via document type definition (DTD) can reduce the application’s risk to XXE attacks. Using an application program interface (API) can help separate commands and parameters before system commands are called. IT professionals are recommended to disable unnecessary or unused ports (only opening public HTTP/HTTPS ports to the Internet, for instance) to block network attacks and abuse related to certain application protocols. Developers must equally take this into account when creating/coding websites and web applications.

Keep secrets to yourself. IT professionals should enforce privilege management policies to mitigate attacks that entail administration-level access to the system/machine. Developers can do the same by limiting user permissions in the website/application, and encrypting or hashing credentials and other sensitive data (i.e. connection strings). Bad guys can learn a lot about the database’s architecture by just looking at an error page. Developers can mitigate this by displaying only minimal information on external error pages, to ensure that attackers get nothing more than unhandled error.

Always double check. Developers, together with IT professionals, should test the web application/site for exposure to vulnerabilities before its deployment. Routine penetration tests of database-connected applications/services and websites help pinpoint security flaws that may have slipped by other means. Continuously monitoring the site, software or database infrastructure during these vetting processes provides actionable information on security flaws and risks that may have been overlooked otherwise.

Plug the hole (and sound the alarm). Incident response also entails how proactive the recovery effort is. Forensic and log analysis tools can help system administrators and IT professionals figure out the hacker’s point of entry and in turn locate the flaw or vulnerable component that developers can then put a lid on. These include tools that can capture disk data and images, as well as those that inspect and analyze files, registries, emails, memory, web pages and network traffic. Were any data exfiltrated or stolen? Did the attack change any of the content on the website or server? Knowing the organization’s risk profile also streamlines the analysis. Don’t forget to validate and notify the appropriate people.

2019 SECURITY PREDICTIONS

Our security predictions for 2019 are based on our experts’ analysis of the progress of current and emerging technologies, user behavior, and market trends, and their impact on the threat landscape.View the 2019 Security Predictions