Difference between revisions of "CRV2 SQLInjPHP"

From OWASP
Jump to: navigation, search
Line 27: Line 27:
 
==Suspicious Validation==
 
==Suspicious Validation==
 
The most common ways to prevent SQL Injection in PHP are using functions such as addslashes() and mysql_real_escape_string()  
 
The most common ways to prevent SQL Injection in PHP are using functions such as addslashes() and mysql_real_escape_string()  
but those function can always cause SQL Injections in some cases
+
but those function can always cause SQL Injections in some cases.
 +
 
 
'''addslashes :'''
 
'''addslashes :'''
 
addslashes() will only work if the query string is wrapped in quotes.A string such as the following would still be vulnerable to an SQL injection
 
addslashes() will only work if the query string is wrapped in quotes.A string such as the following would still be vulnerable to an SQL injection
Line 36: Line 37:
 
   
 
   
 
  ?>
 
  ?>
 +
  
 
'''mysql_real_escape_string():'''
 
'''mysql_real_escape_string():'''
 +
 
mysql_real_escape_string() is a little bit more powerful than addslashes() as it calls MySQL's library function mysql_real_escape_string, which prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a.
 
mysql_real_escape_string() is a little bit more powerful than addslashes() as it calls MySQL's library function mysql_real_escape_string, which prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a.
 
As with addslashes(), mysql_real_escape_string() will only work if the query string is wrapped in quotes. A string such as the following would still be vulnerable to an SQL injection:
 
As with addslashes(), mysql_real_escape_string() will only work if the query string is wrapped in quotes. A string such as the following would still be vulnerable to an SQL injection:

Revision as of 21:39, 15 October 2013

««Reviewing code for SQL Injection«« Main
(Table of Contents)
»»CRV2 SQL Injection Java»»

Contents


Introduction

An SQL injection Attack consists of injecting sql query portions in the back-end database system via the client interface in the web application. The consequence of a successful exploitation of an SQL injection varies from just reading data to modifying data or executing system commands. SQL Injection in PHP remains the number one attack vector, and also the number on reason for DATA COMPROMISES

Data Validation and prepared statements

It is as simple as this the absence of data validation and prepared statements or stored procedures will increase the possibility that your code contain SQL injections. If your application gives the users the possibility to change parameters and those parameters are not verified and inserted in an unprepared statement than your code contain an SQL Injection.

Example 1 :

<?php
$pass=$_GET["pass"];
$con = mysql_connect('localhost', 'owasp', 'abc123');
mysql_select_db("owasp_php", $con);
$sql="SELECT card FROM users WHERE password = '".$pass."'";
$result = mysql_query($sql);
?>

Suspicious Validation

The most common ways to prevent SQL Injection in PHP are using functions such as addslashes() and mysql_real_escape_string() but those function can always cause SQL Injections in some cases.

addslashes : addslashes() will only work if the query string is wrapped in quotes.A string such as the following would still be vulnerable to an SQL injection

<?php

$id = addslashes( $_GET['id'] );
$query = 'SELECT title FROM books WHERE id = ' . $id;

?>


mysql_real_escape_string():

mysql_real_escape_string() is a little bit more powerful than addslashes() as it calls MySQL's library function mysql_real_escape_string, which prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a. As with addslashes(), mysql_real_escape_string() will only work if the query string is wrapped in quotes. A string such as the following would still be vulnerable to an SQL injection:

<?php

$bid = mysql_real_escape_string( $_GET['id'] );
$query = 'SELECT title FROM books WHERE id = ' . $bid;

?>

Canonicalization

Canonicalization is the process by which various equivalent forms of a name can be resolved to a single standard name, or the "canonical" name.

The most popular encodings are UTF-8, UTF-16, and so on (which are described in detail in RFC 2279). A single character, such as a period/full-stop (.), may be represented in many different ways: ASCII 2E, Unicode C0 AE, and many others.

With the myriad ways of encoding user input, a web application's filters can be easily circumvented if they're not carefully built.

Bad Example

public static void main(String[] args) {
    File x = new File("/cmd/" + args[1]);
    String absPath = x.getAbsolutePath();
}

Good Example

public static void main(String[] args) throws IOException {
    File x = new File("/cmd/" + args[1]);
    String canonicalPath = x.getCanonicalPath();
}


References

See Reviewing code for Data Validation (in this guide) Reviewing code for Data Validation


See the OWASP ESAPI Project

The OWASP ESAPI project provides a reference implementation of a security API which can assist in providing security controls to an application.


««Session Management«« Main
(Table of Contents)
»»Error Handling»»