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.


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 

For example, if an application passes a parameter sent via a GET request to the 
code other than what the developer had in mind.

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

is useful for gaining information about the configuration of the environment 
his PHP code using the following request:

Avoid using eval with untrusted data.

// LDAP Injection

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

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 

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

1. Use parameter binding

2. Whitelisting