Query Parameterization Cheat Sheet (Hawaiian Pidgin English) - Revision history

Jmanico: gone

2018-08-16T21:30:29Z

gone

Show changes

Jmanico: /* Authors and Primary Editors */

2014-07-07T13:52:28Z

‎Authors and Primary Editors

Jmanico: to to foa

2014-07-07T13:50:54Z

to to foa

Jmanico: this to da

2014-07-07T13:47:57Z

this to da

Jmanico: this to dis

2014-07-07T13:45:31Z

this to dis

Jmanico at 13:36, 7 July 2014

2014-07-07T13:36:15Z

Jmanico at 13:24, 7 July 2014

2014-07-07T13:24:33Z

Jmanico: Created page with " NOTOC
link=
{| style="padding: 0;margin:0;margin-top:10px;..."

2014-07-07T13:21:22Z

Created page with " __NOTOC__ <div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">link=</div> {| style="padding: 0;margin:0;margin-top:10px;..."

New page

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

[[SQL Injection]] is one of the most dangerous web vulnerabilities. So much so that it's the [[Top_10_2013-A1|#1 item in the OWASP Top 10]]. It represents a serious threat because SQL Injection allows evil attacker code to change the structure of a web application's SQL statement in a way that can steal data, modify data, or potentially facilitate command injection to the underlying OS. This cheat sheet is a derivative work of the [[SQL Injection Prevention Cheat Sheet]].

= Parameterized Query Examples =

SQL Injection is best prevented through the use of [[SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_1:_Prepared_Statements_.28Parameterized_Queries.29|''parameterized queries'']]. The following chart demonstrates, with real-world code samples, how to build parameterized queries in most of the common web languages. The purpose of these code samples is to demonstrate to the web developer how to avoid SQL Injection when building database queries within a web application.

== Prepared Statement Examples ==

{| class="wikitable nowraplinks"
|-
! Language - Library
! Parameterized Query
|-
| Java - Standard
|
String custname = request.getParameter("customerName");
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
'''PreparedStatement pstmt = connection.prepareStatement( query );'''
'''pstmt.setString( 1, custname); '''
ResultSet results = pstmt.executeQuery( );
|-
| Java - Hibernate
|
//HQL
Query safeHQLQuery = session.createQuery("from Inventory where productID=:productid");
safeHQLQuery.setParameter("productid", userSuppliedParameter);

//Criteria API
String userSuppliedParameter = request.getParameter("Product-Description"); // This should REALLY be validated too
// perform input validation to detect attacks
Inventory inv = (Inventory) session.createCriteria(Inventory.class).add
(Restrictions.eq("productDescription", userSuppliedParameter)).uniqueResult();
|-
| .NET/C#
|
String query = "SELECT account_balance FROM user_data WHERE user_name = ?";
try {
OleDbCommand command = new OleDbCommand(query, connection);
'''command.Parameters.Add(new OleDbParameter("customerName", CustomerName Name.Text));'''
OleDbDataReader reader = command.ExecuteReader();
// …
} catch (OleDbException se) {
// error handling
}
|-
| ASP.NET
|
string sql = "SELECT * FROM Customers WHERE CustomerId = @CustomerId";
'''SqlCommand command = new SqlCommand(sql);'''
'''command.Parameters.Add(new SqlParameter("@CustomerId", System.Data.SqlDbType.Int));'''
command.Parameters["@CustomerId"].Value = 1;
|-
| Ruby - ActiveRecord
|
'''# Create'''
Project.create!(:name => 'owasp')
'''# Read'''
Project.all(:conditions => "name = ?", name)
Project.all(:conditions => { :name => name })
Project.where("name = :name", :name => name)
'''# Update'''
project.update_attributes(:name => 'owasp')
'''# Delete'''
Project.delete(:name => 'name')
|-
| Ruby
|
insert_new_user = db.prepare "INSERT INTO users (name, age, gender) VALUES (?, ? ,?)"
insert_new_user.execute 'aizatto', '20', 'male'
|-
| PHP - PDO
|
$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)");
'''$stmt->bindParam(':name', $name);'''
'''$stmt->bindParam(':value', $value);'''
|-
| Cold Fusion
|
<cfquery name = "getFirst" dataSource = "cfsnippets">
'''SELECT * FROM #strDatabasePrefix#_courses WHERE intCourseID ='''
'''<cfqueryparam value = #intCourseID# CFSQLType = "CF_SQL_INTEGER">'''
</cfquery>
|-
| Perl - DBI
|
my $sql = "INSERT INTO foo (bar, baz) VALUES ( ?, ? )";
'''my $sth = $dbh->prepare( $sql );'''
'''$sth->execute( $bar, $baz );'''
|}

== Stored Procedure Examples ==

The SQL you write in your web application isn't the only place that SQL injection vulnerabilities can be introduced. If you are using Stored Procedures, and you are dynamically constructing SQL inside them, you can also introduce SQL injection vulnerabilities. To ensure this dynamic SQL is secure, you can parameterize this dynamic SQL too using bind variables. Here are some examples of using bind variables in stored procedures in different databases:

{| class="wikitable nowraplinks"
|-
! Language - Library
! Parameterized Query
|-
| Oracle - PL/SQL
|
Normal Stored Procedure - no dynamic SQL being created. Parameters passed in to stored procedures are naturally bound to their location within the query without anything special being required.

PROCEDURE SafeGetBalanceQuery(
UserID varchar, Dept varchar) AS BEGIN

SELECT balance FROM accounts_table WHERE user_ID = UserID AND department = Dept;
END;

|-
| Oracle - PL/SQL
|
Stored Procedure Using Bind Variables in SQL Run with EXECUTE. Bind variables are used to tell the database that the inputs to this dynamic SQL are 'data' and not possibly code.

PROCEDURE AnotherSafeGetBalanceQuery(
UserID varchar, Dept varchar) AS
stmt VARCHAR(400); result NUMBER;

BEGIN
stmt := 'SELECT balance FROM accounts_table WHERE user_ID = :1
AND department = :2';
EXECUTE IMMEDIATE stmt INTO result USING UserID, Dept;
RETURN result;
END;
|-
| SQL Server- Transact-SQL
|
Normal Stored Procedure - no dynamic SQL being created. Parameters passed in to stored procedures are naturally bound to their location within the query without anything special being required.

PROCEDURE SafeGetBalanceQuery(
@UserID varchar(20),
@Dept varchar(10)) AS BEGIN

SELECT balance FROM accounts_table WHERE user_ID = @UserID AND department = @Dept
END
|-
| SQL Server- Transact-SQL
|
Stored Procedure Using Bind Variables in SQL Run with EXEC. Bind variables are used to tell the database that the inputs to this dynamic SQL are 'data' and not possibly code.

PROCEDURE SafeGetBalanceQuery(@UserID varchar(20),
@Dept varchar(10)) AS BEGIN
DECLARE @sql VARCHAR(200)
SELECT @sql = 'SELECT balance FROM accounts_table WHERE '
+ 'user_ID = @UID AND department = @DPT'
EXEC sp_executesql @sql,
'@UID VARCHAR(20), @DPT VARCHAR(10)',
@UID=@UserID, @DPT=@Dept
END
|}

= References =
* [http://bobby-tables.com/ The Bobby Tables site (inspired by the XKCD webcomic) has numerous examples in different languages of parameterized Prepared Statements and Stored Procedures]
* OWASP [[SQL Injection Prevention Cheat Sheet]]

= Authors and Primary Editors =

Jim Manico - jim [at] owasp.org<br/>
[[User:Wichers|Dave Wichers - dave.wichers]] [at] aspectsecurity.com<br/>
Neil Matatal - neil [at] owasp.org

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

@@ Line 8: / Line 8: @@
   __TOC__{{TOC hidden}}
-'Ey, Howzit? One [[SQL Injection]] is da moddah of all web vulnerabilities. Fo' real! So much so that it's da [[Top_10_2013-A1|#1 item in da OWASP Top 10]].  It represents a serious threat because SQL Injection allows evil attacker code to change da structure of a web application's SQL statement in a way that can steal data, modify data, or potentially facilitate command injection to da underlying OS.
+'Ey, Howzit? One [[SQL Injection]] is da moddah of all web vulnerabilities. Fo' real! So much so that it's da [[Top_10_2013-A1|#1 item in da OWASP Top 10]].  It represents a serious threat because SQL Injection allows evil attacker code foa change da structure of a web application's SQL statement in a way that can steal data, modify data, or potentially facilitate command injection foa da underlying OS.
 Dis cheat sheet is a derivative work of da [[SQL Injection Prevention Cheat Sheet]].  Mahalos yeah fo' checking out dis place. Shoots!
 = Parameterized Query Examples =
-SQL Injection is best prevented through the use of [[SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_1:_Prepared_Statements_.28Parameterized_Queries.29|''parameterized queries'']]. Da following chart demonstrates, with real-world code samples, how to build parameterized queries in most of da common web languages. Da purpose of these code samples is to demonstrate to da web developer how to avoid SQL Injection when building database queries within a web application.
+SQL Injection is best prevented through the use of [[SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_1:_Prepared_Statements_.28Parameterized_Queries.29|''parameterized queries'']]. Da following chart demonstrates, with real-world code samples, how foa build parameterized queries in most of da common web languages. Da purpose of these code samples is foa demonstrate foa da web developer how foa avoid SQL Injection when building database queries within a web application.
 == Prepared Statement Examples ==
@@ Line 147: / Line 147: @@
 | SQL Server- Transact-SQL
+|
-Stored Procedure Using Bind Variables in SQL Run with EXEC. Bind variables are used to tell da database that da inputs to dis dynamic SQL are 'data' and not possibly code.
+Stored Procedure Using Bind Variables in SQL Run with EXEC. Bind variables are used to tell da database that da inputs to dis dynamic SQL are 'data' and noa possibly code.
    PROCEDURE SafeGetBalanceQuery(@UserID varchar(20),

@@ Line 8: / Line 8: @@
   __TOC__{{TOC hidden}}
-'Ey, Howzit? One [[SQL Injection]] is da moddah of all web vulnerabilities. Fo' real! So much so that it's the [[Top_10_2013-A1|#1 item in the OWASP Top 10]].  It represents a serious threat because SQL Injection allows evil attacker code to change the structure of a web application's SQL statement in a way that can steal data, modify data, or potentially facilitate command injection to the underlying OS.
+'Ey, Howzit? One [[SQL Injection]] is da moddah of all web vulnerabilities. Fo' real! So much so that it's da [[Top_10_2013-A1|#1 item in da OWASP Top 10]].  It represents a serious threat because SQL Injection allows evil attacker code to change da structure of a web application's SQL statement in a way that can steal data, modify data, or potentially facilitate command injection to da underlying OS.
-Dis cheat sheet is a derivative work of the [[SQL Injection Prevention Cheat Sheet]].  Mahalos yeah fo' checking out dis place. Shoots!
+Dis cheat sheet is a derivative work of da [[SQL Injection Prevention Cheat Sheet]].  Mahalos yeah fo' checking out dis place. Shoots!
 = Parameterized Query Examples =
-SQL Injection is best prevented through the use of [[SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_1:_Prepared_Statements_.28Parameterized_Queries.29|''parameterized queries'']]. The following chart demonstrates, with real-world code samples, how to build parameterized queries in most of the common web languages. The purpose of these code samples is to demonstrate to the web developer how to avoid SQL Injection when building database queries within a web application.
+SQL Injection is best prevented through the use of [[SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_1:_Prepared_Statements_.28Parameterized_Queries.29|''parameterized queries'']]. Da following chart demonstrates, with real-world code samples, how to build parameterized queries in most of da common web languages. Da purpose of these code samples is to demonstrate to da web developer how to avoid SQL Injection when building database queries within a web application.
 == Prepared Statement Examples ==
@@ Line 101: / Line 101: @@
 == Stored Procedure Examples ==
-The SQL you write in your web application isn't the only place that SQL injection vulnerabilities can be introduced. If you are using Stored Procedures, and you are dynamically constructing SQL inside them, you can also introduce SQL injection vulnerabilities. To ensure dis dynamic SQL is secure, you can parameterize dis dynamic SQL too using bind variables. Here are some examples of using bind variables in stored procedures in different databases:
+Da SQL you write in your web application isn't da only place that SQL injection vulnerabilities can be introduced. If you are using Stored Procedures, and you are dynamically constructing SQL inside them, you can also introduce SQL injection vulnerabilities. To ensure dis dynamic SQL is secure, you can parameterize dis dynamic SQL too using bind variables. Here are some examples of using bind variables in stored procedures in different databases:
 {| class="wikitable nowraplinks"
@@ Line 110: / Line 110: @@
 | Oracle - PL/SQL
+|
-Normal Stored Procedure - no dynamic SQL being created. Parameters passed in to stored procedures are naturally bound to their location within the query without anything special being required.
+Normal Stored Procedure - no dynamic SQL being created. Parameters passed in to stored procedures are naturally bound to their location within da query without anything special being required.
    PROCEDURE SafeGetBalanceQuery(
@@ Line 121: / Line 121: @@
 | Oracle - PL/SQL
+|
-Stored Procedure Using Bind Variables in SQL Run with EXECUTE. Bind variables are used to tell the database that the inputs to dis dynamic SQL are 'data' and not possibly code.
+Stored Procedure Using Bind Variables in SQL Run with EXECUTE. Bind variables are used to tell da database that da inputs to dis dynamic SQL are 'data' and not possibly code.
    PROCEDURE AnotherSafeGetBalanceQuery(
@@ Line 136: / Line 136: @@
 | SQL Server- Transact-SQL
+|
-Normal Stored Procedure - no dynamic SQL being created. Parameters passed in to stored procedures are naturally bound to their location within the query without anything special being required.
+Normal Stored Procedure - no dynamic SQL being created. Parameters passed in to stored procedures are naturally bound to da location within da query without anything special being required.
    PROCEDURE SafeGetBalanceQuery(
@@ Line 147: / Line 147: @@
 | SQL Server- Transact-SQL
+|
-Stored Procedure Using Bind Variables in SQL Run with EXEC. Bind variables are used to tell the database that the inputs to dis dynamic SQL are 'data' and not possibly code.
+Stored Procedure Using Bind Variables in SQL Run with EXEC. Bind variables are used to tell da database that da inputs to dis dynamic SQL are 'data' and not possibly code.
    PROCEDURE SafeGetBalanceQuery(@UserID varchar(20),
@@ Line 161: / Line 161: @@
 = References =
-* [http://bobby-tables.com/ The Bobby Tables site (inspired by the XKCD webcomic) has numerous examples in different languages of parameterized Prepared Statements and Stored Procedures]
+* [http://bobby-tables.com/ Da Bobby Tables site (inspired by da XKCD webcomic) has numerous examples in different languages of parameterized Prepared Statements and Stored Procedures]
 * OWASP [[SQL Injection Prevention Cheat Sheet]]

@@ Line 8: / Line 8: @@
   __TOC__{{TOC hidden}}
-[[SQL Injection]] is one of the most dangerous web vulnerabilities. So much so that it's the [[Top_10_2013-A1|#1 item in the OWASP Top 10]].  It represents a serious threat because SQL Injection allows evil attacker code to change the structure of a web application's SQL statement in a way that can steal data, modify data, or potentially facilitate command injection to the underlying OS.  This cheat sheet is a derivative work of the [[SQL Injection Prevention Cheat Sheet]].  Mahalos yeah fo' checking out dis place. Shoots!
+'Ey, Howzit? One [[SQL Injection]] is da moddah of all web vulnerabilities. Fo' real! So much so that it's the [[Top_10_2013-A1|#1 item in the OWASP Top 10]].  It represents a serious threat because SQL Injection allows evil attacker code to change the structure of a web application's SQL statement in a way that can steal data, modify data, or potentially facilitate command injection to the underlying OS.  This cheat sheet is a derivative work of the [[SQL Injection Prevention Cheat Sheet]].  Mahalos yeah fo' checking out dis place. Shoots!
 = Parameterized Query Examples =

@@ Line 164: / Line 164: @@
 * OWASP [[SQL Injection Prevention Cheat Sheet]]
-= Authors and Primary Editors  =
+= Translators =
 Jim Manico - jim [at] owasp.org<br/>
-[[User:Wichers|Dave Wichers - dave.wichers]] [at] aspectsecurity.com<br/>
+Jeremiah Grossman
 == Other Cheatsheets ==