Skip to main content

Top 10 web security vulnerabilities number 2: Injection Flaws

Posted by caroljmcdonald on October 2, 2009 at 3:35 PM PDT

The Top 10 Web Application security vulnerabilities

OWASP Top 10 number 2: Injection Flaws

Number 2 in the Top
10 most critical web application security vulnerabilities

identified by the Open
Web Application Security Project (OWASP)

is Injection Flaws. Injection happens whenever an attacker's data is
able to modify a query or command sent to a database, LDAP server,
operating system or other Interpreter. Types of injections are SQL,
LDAP, XPath, XSLT, HTML, XML, OS command... SQL injection
and Cross-Site
Scripting account for more than 80% of the vulnerabilities being
discovered against Web applications (SANS Top Cyber
Security Risks
).

SQL Injection Example

use of string concantenation to build
query
:
SQL Injection can happen with dynamic database queries concatenated
with user supplied input, for example with the following query:

"select * from MYTABLE where name=" + parameter

if the user supplies "name' OR 'a'='a' " as
the parameter it results in the following:

"select * from MYTABLE where name= 'name' OR 'a'='a';

the OR 'a'='a' causes the where clause to always be true which is
the equivalent of the following:

"select * from MYTABLE;

if the user supplies "name' OR 'a'='a' ;
delete from MYTABLE" as the parameter it results in the following:

"select * from MYTABLE where name= 'name' OR 'a'='a'; delete from MYTABLE;

the OR 'a'='a' causes the where clause to always be true which is
the equivalent of the following:

"select * from MYTABLE; delete from MYTABLE;

some database servers, allow multiple SQL
statements separated by semicolons to be executed at once.


SQL Injection can be used to:

  • create , read , update, or delete database data

Protecting against SQL Injection

  • Don't concatenate user input data to a query or command!
    • Use Query Parameter binding with typed parameters, this ensures
      the input data can only be interpreted as the value for
      the intended parameter
      so the attacker can not change the intent of a
      query
      .
  • Validate all input data to the application using white list (what
    is allowed) for type, format, length, range, reject if invalid. (see previous
    blog entry
    )
  • don't provide too much information in error messages (like SQL
    Exception Information, table names..) to the user.


Java specific Protecting against SQL Injection

Don't concatenate user
input data
to a query or command:

  • Don't do this with JDBC:
    String empId= req.getParameter("empId") // input parameter
    String query = "SELECT * FROM Employee WHERE
                         id = '" + empId +"'"? 

  • Don't do this with JPA:

    q = entityManager.createQuery(
    Related Topics >>