28.10.2014 Views

SQL Injection Attacks and Defense - 2009

SQL Injection Attacks and Defense - 2009

SQL Injection Attacks and Defense - 2009

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Reviewing Code for <strong>SQL</strong> <strong>Injection</strong> • Chapter 3 99<br />

To get started, the following lines build strings that are concatenated with tainted input<br />

(data that has not been validated):<br />

// a dynamically built sql string statement in PHP<br />

$sql = "SELECT * FROM table WHERE field = '$_GET["input"]'";<br />

// a dynamically built sql string statement in C#<br />

String sql = "SELECT * FROM table WHERE field = '" +<br />

request.getParameter("input") + "'";<br />

// a dynamically built sql string statement in Java<br />

String sql = "SELECT * FROM table WHERE field = '" +<br />

request.getParameter("input") + "'";<br />

The PHP, C#, <strong>and</strong> Java source code presented next shows how some developers<br />

dynamically build <strong>and</strong> execute <strong>SQL</strong> statements that contain user-controlled data that has<br />

not been validated. It is important that you are able to identify this coding behavior when<br />

reviewing source code for vulnerabilities.<br />

// a dynamically executed sql statement in PHP<br />

mysql_query("SELECT * FROM table WHERE field = '$_GET["input"]'");<br />

// a dynamically executed sql string statement in C#<br />

SqlComm<strong>and</strong> comm<strong>and</strong> = new SqlComm<strong>and</strong>("SELECT * FROM table WHERE field = '" +<br />

request.getParameter("input") + "'", connection);<br />

// a dynamically executed sql string statement in Java<br />

ResultSet rs = s.executeQuery("SELECT * FROM table WHERE field = '" +<br />

request.getParameter("input") + "'");<br />

Some developers believe that if they do not build <strong>and</strong> execute dynamic <strong>SQL</strong> statements<br />

<strong>and</strong> instead only pass data to stored procedures as parameters, their code will not be<br />

vulnerable. However, this is not true, as stored procedures can be vulnerable to <strong>SQL</strong><br />

injection also. A stored procedure is a set of <strong>SQL</strong> statements with an assigned name that’s<br />

stored in a database. Here is an example of a vulnerable Microsoft <strong>SQL</strong> Server stored<br />

procedure:<br />

// vulnerable stored procedure in MS <strong>SQL</strong><br />

CREATE PROCEDURE SP_StoredProcedure @input varchar(400) = NULL AS<br />

DECLARE @sql nvarchar(4000)<br />

SELECT @sql = 'SELECT field FROM table WHERE field = ''' + @input + ''''<br />

EXEC (@sql)<br />

In the preceding example, the @input variable is taken directly from the user input<br />

<strong>and</strong> concatenated with the <strong>SQL</strong> string (i.e., @sql ). The <strong>SQL</strong> string is passed to the EXEC<br />

function as a parameter <strong>and</strong> is executed. The preceding Microsoft <strong>SQL</strong> Server stored<br />

procedure is vulnerable to <strong>SQL</strong> injection even though the user input is being passed to it<br />

as a parameter.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!