Secure Application Development and the OWASP Top 10
Some of you may already be familiar with the Open Web Application Security Project (OWASP) and its Top 10 2010 list due in part to Requirement 6.5 of the Payment Card Industry Data Security Standard (PCI DSS):
6.5 Develop applications based on secure coding guidelines. Prevent common coding vulnerabilities in software development processes.
For those of you who are not familiar with OWASP and their Top 10, the OWASP Top 10 2010 was aimed at highlighting simple problems that can plague applications and ultimately undermine security. Given recent news stories, and the renewed interest of the general public in information security, I thought it was worth taking a run through each of the Top 10 as sort of a refresher. We’ll make sure to crosslink the various posts as we publish them.
Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data.
While there are other types of injection, such as OS command, XPATH, and LDAP, SQL injection is perhaps the most common form of attack. It is also specifically called out by Requirement 6.5.1 of the PCI DSS:
6.5.1 [Develop applications based on secure coding guidelines. Prevent common coding vulnerabilities in software development processes, to include the following:] Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.
SQL injection typically occurs when unvalidated user input is passed to the database to perform a query. In the following example, data is being directly incorporated into the SQL query without any data validation.
String username = request.getParameter("username");
String password = request.getParameter("password");
String sql = "SELECT *
FROM users
WHERE username = '" + username + "'
and password = '" + password + "'";The consequences of a successful attack exploiting an SQL injection vulnerability can range from exfiltration of the data contained within the database, to compromising the database server itself.
Using the above example, the developer is expecting the SQL query to be run as:
SELECT * FROM users
WHERE username = 'bob' and password = 'weakpassword'Whereas if an attacker was to enter input that the developer wasn’t expecting, the SQL query could get modified. Using the string -- to terminate the SQL query, one example would be to modify the username as bob'--, which would result in the following SQL query being run:
SELECT * FROM users WHERE username = 'bob'--' and password = 'weakpassword'
With the second half of the SQL query not running, the attacker is able to look up bob’s account without entering the correct password!
When coding secure applications, dynamic queries like the example above should be avoided. Instead, use Prepared Statements or Stored Procedures (safely coded).
For more information from OWASP on securely coding database queries, you can check out their SQL Injection Prevention Cheat Sheet and their write-up on Reviewing Code for SQL Injection.
Zach Grace submitted this to 