Abstract
Using unvalidated input as part of a directive or command to a subsystem can introduce vulnerability.
Description
"Injection" is a special kind of input validation vulnerability. It is special in that the input that is not validated is later used as input to some embedded system, such as a script processor or a database.
Warning
The several pieces of advice presented here that relate to "injection" are very ambiguously related. Their coverage in literature tends to define them somewhat arbitrarily by either their engineering cause of the pattern of attack carried out by an adversary to exploit them. These two ways of describing vulnerabilities lead to quite different coverage and to different categorizations. Even the term "injection"—which is fairly uniformly used—is strange to engineers since the use of the term implies a clearly adversarial perspective, rather than an engineering one.
Command Injection
When a program accepts unvalidated input from a user and uses that input to form a dynamic command to be executed by a "command-oriented" subsystem, a vulnerability may exist.
The usual context for this class of vulnerability is a program that invokes a command processor (e.g., UNIX shell) with commands derived from user input [[VU#502328], VU#195371].
SQL Injection
When a program accepts unvalidated input from a user and uses that input to construct a dynamic SQL query to an SQL database, a vulnerability may exist.
The usual context for this class of vulnerability is a web server that accepts input from browsers, uses that input to construct queries against a server-side database, and formats the query response to the browser. The browser user may construct crafted input that, when embedded in a string that is interpreted as an SQL query, performs database operations that are not intended.
Cross-Site Scripting
The security community that has not completely settled on the definition of cross-site scripting. In its simplest form,
Cross-site scripting is possible when
An adversary tricks a victim into clicking on a link that he crafted and presented to the victim (via a web server or email),
The link contains a URL with embedded malicious script (typically as a query string), and
The URL refers to host that echoes input back to a browser without input validation.
When the victim clicks the link, he is referred to the host in the URL, the host processes the query string and echoes it to the victim's browser, and the victim's browser executes the malicious script.
This is an unusual vulnerability because the system at fault, the web site not doing input validation, is not the victim of attack.
The only remedy for this vulnerability is for the web site to perform adequate input validation.
References
Citation | Bibliographic Entry |
---|---|
[Anley 02] | Anley, Chris. Advanced SQL Injection In SQL Server Applications. http://www.nextgenss.com/papers/advanced_sql_injection.pdf (2002). |
[Apache 00] | apache.org. Cross Site Scripting Info. http://httpd.apache.org/info/css-security/ (2000). |
[CA-2000-02] | cert.org. CERT® Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests. http://www.cert.org/advisories/CA-2000-02.html (2000). |
[CERT 00] | cert.org. Understanding Malicious Content Mitigation for Web Developers. http://www.cert.org/tech_tips/malicious_code_mitigation.html (2000). |
[Howard 02] | Howard, Michael & LeBlanc, David. Writing Secure Code, 2nd. edition. Redmond, WA: Microsoft Press, 2002. |
[Integrigy 04] | integrigy.com. An Introduction to SQL Injection Attacks for Oracle Developers. http://www.integrigy.com/info/IntegrigyRethinkingSQLInjectionAttacks.pdf (2004). |
[VU#195371] | Havrilla, Jeffrey S. Vulnerability Note VU#195371: SGI IRIX rpc.xfsmd does not filter shell metacharacters from user input before invoking popen() function. http://www.kb.cert.org/vuls/id/195371 (2003). |
[VU#502328] | MacInnis, Ken. Vulnerability Note VU#502328: SquirrelMail vulnerable to command injection because of flawed input checking in S/MIME plug-in. http://www.kb.cert.org/vuls/id/502328 (2005). |
Copyright © Carnegie Mellon University 2005-2012.
This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at permission@sei.cmu.edu.
The Build Security In (BSI) portal is sponsored by the U.S. Department of Homeland Security (DHS), National Cyber Security Division. The Software Engineering Institute (SEI) develops and operates BSI. DHS funding supports the publishing of all site content.
NO WARRANTY
THIS MATERIAL OF CARNEGIE MELLON UNIVERSITY AND ITS SOFTWARE ENGINEERING INSTITUTE IS FURNISHED ON AN “AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.