Knowledge Base

Overview

Injection attacks refer to a broad class of attack vectors. Injection flaws occur when an attacker can send hostile data to an interpreter as part of a command or query. In turn, this alters the execution of that program.

The most common injection flaws are:

• Cross-Site Scripting (XSS)
• SQL injections (SQLi)
• Command injections which can lead to remote code execution (RCE) vulnerabilities
• LDAP injections

How to enforce

In general, preventing injection requires keeping data separate from commands and queries and using "whitelist" server-side input validation. (Source: OWASP Top 10)

User input may be used in different contexts, and it needs to be treated differently depending on the context that it will be used in, be it HTML, Javascript, SQL or LDAP.

Developers should validate data on input. This involves checking data types, ranges, lengths and expected values. The purpose of validation is to make sure that we receive what we expect to receive. Data should be further sanitized on output depending on context. Sanitization involves transforming the data to be safe in the output context.

Please read further to find out how to prevent specific cases of injection in ResourceSpace.

SQL injection (SQLi)

In ResourceSpace SQL injections can be prevented by using prepared statements.

When prepared statements can't be used (e.g table name in the FROM clause) then make sure to sanitise the input.

Cross-Site Scripting (XSS)

There are three forms of XSS:

• Reflected XSS: The application includes unvalidated and unescaped user input as part of HTML output. A successful attack can allow the attacker to execute arbitrary HTML and JavaScript in the victim's browser.
• Stored XSS: The application stores unsanitized user input that is viewed at a later time by another user or an administrator. Stored XSS is often considered a high or critical risk.
• DOM XSS: JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controllable data to a page are vulnerable to DOM XSS.

Preventing XSS requires separation of untrusted data from active browser content.

In ResourceSpace, we have agreed to apply the following rules:

• When echoing text to the screen that should not include html (e.g. $lang elements, error messages) then use escape();
• From v10+: If the text will be within quotes you can use escape_quoted_data(); (removed from v10.3+)
• If the text you are outputting to screen can include valid html (e.g. rich text field metadata values) then use strip_tags_and_attributes();
• When manipulating untrusted data on the client side, use DOMPurify (added since revision #21792). e.g:

  let your_var = DOMPurify.sanitize(dirty);

OWASP maintains a better list of preventing XSS. For a better understanding and more comprehensive list, please see their Cross Site Scripting Prevention Cheat Sheet.

Command Injection

Command injection is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell.

In this attack, the attacker-supplied operating system commands are usually executed with the privileges of the vulnerable application.

Command injection attacks are possible largely due to insufficient input validation.

In ResourceSpace, developers should use the run_command($command, $geterrors = false, array $params = array()) function which, if used with the params argument it will automatically escapeshellarg() every single one of them before using it in the command.