Security Injection


// Security - Injections (SQL injection and other injection vulnerabilities):

Types of Injection:

1. SQL Injection
3. Xpath
4. OS Commands
5. XML parsers
6. SMTP Headers
7. Program arguments

Consider the following query:

Select * from user where username = ‘un_input’ and password = ‘pw_input’

where un_input and pw_input are user inputs, and no modifications are made 
before passing to the SQL query.  An enterprising attacker might enter a 
username of “ admin’– ” which results in this query:

Select * from user where username = ‘admin’--’ and password = ‘pw_input’

In SQL, “--” denotes a comment, causing the application to ignore the rest of the 
query and only execute the first part.  Since this query will be true as long as 
the admin exists, a user could bypass the password check and login this way.

To determine if a field is vulnerable to SQL injection attack, modify the input 
for that field to include something like ' limit 1' and see if it produce the expected 
result.  If it does produce the expected result, the field is vulnerable to SQL 
injection attacks.

The ' limit 1' approach may or may not always be a good test for SQL injection 
vulnerability, but it has no harmful side effect.  Other things that we may want 
to try is using quotes, percent sign, and --.  If these characters lead to error, 
it is likely that this field is vulnerable to SQL injection attack (particularly if 
the result SQL statement is displayed on the screen as part of the error or 
exception message).

Common payload for SQL inject attacks:

something ' limit 1'
something %' and Performance_rating < 2 and name like '%
5 or 1=1;

SQL injection is not just about querying for data.  It can also be used to CREATE, 
INSERT, DELETE, and DROP data from your database.  So, SQL injection flaws 
can be extremely serious.  A single flaw anywhere may allow attacker to read, 
modify, or delete our entire database.

To avoid injection attacks, use parameter binding if available.  If not, we need 
to carefully escape special characters using the specific escape syntax for that 
interpreter. OWASP ESAPI provides many of these escaping routines:

Command injection attacks are possible largely due to insufficient input validation.
To prevent command injection, search the source code for all calls to external 
resources (e.g., system, exec, fork, Runtime.exec, etc), and make sure that you
validate the data, remove dangerous characters, etc.

On the Unix platform, the semicolon character is typically used to chain commands 
in order to perform a command injection attack.

Always use absolute path, and avoid being dependent on the PATH environment 
variable, because the attacker can alter the PATH environment variable.

Code Injection is the general term for attack types which consist of injecting 
code that is then interpreted/executed by the application. This type of attack 
exploits poor handling of untrusted data.  These types of attacks are usually 
made possible due to a lack of proper input/output data validation, for example:

1. allowed characters (standard regular expressions classes or custom)
2. data format
3. amount of expected data

Code Injection differs from Command Injection in that an attacker is only 
limited by the functionality of the injected language itself. If an attacker is 
able to inject PHP code into an application and have it executed, he is only 
limited by what PHP is capable of. Command injection consists of leveraging 
existing code to execute commands, usually within the context of a shell.

For example, if an application passes a parameter sent via a GET request to the 
PHP include() function with no input validation, the attacker may try to execute 
code other than what the developer had in mind.

The URL below passes a page name to the include() function:

The file "evilcode.php" may contain, for example, the phpinfo() function which 
is useful for gaining information about the configuration of the environment 
in which the web service runs. An attacker can ask the application to execute 
his PHP code using the following request:

Avoid using eval with untrusted data.

// LDAP Injection

String ldapSearchQuery = "(cn=" + $userName + ")"; 

If the variable $userName is not validated, it could be possible accomplish 
LDAP injection, as follows:

1. If a user puts “*” on box search, the system may return all the usernames on 
   the LDAP base

2. If a user puts “jonys) (| (password = * ) )”, it will generate the code below 
   revealing jonys’ password ( cn = jonys ) ( | (password = * ) )

injection = input validation (to prevent injection problems, do input validation).
// Security - Injection - Prevention:

1. Use parameter binding

2. Whitelisting
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License