This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Query Parameterization Cheat Sheet (Hawaiian Pidgin English)"

From OWASP
Jump to: navigation, search
m (this to da)
(to to foa)
Line 8: Line 8:
 
  __TOC__{{TOC hidden}}
 
  __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!
 
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 =
 
= 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 ==
 
== Prepared Statement Examples ==
Line 147: Line 147:
 
| SQL Server- Transact-SQL
 
| 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),
 
   PROCEDURE SafeGetBalanceQuery(@UserID varchar(20),

Revision as of 13:50, 7 July 2014

Cheatsheets-header.jpg

Last revision (mm/dd/yy): 07/7/2014

Introduction

'Ey, Howzit? One SQL Injection is da moddah of all web vulnerabilities. Fo' real! So much so that it's da #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 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

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"); // Dis 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

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:

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 da 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 da database that da inputs to dis 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 da location within da 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 da database that da inputs to dis dynamic SQL are 'data' and noa 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

Authors and Primary Editors

Jim Manico - jim [at] owasp.org
Dave Wichers - dave.wichers [at] aspectsecurity.com
Neil Matatal - neil [at] owasp.org

Other Cheatsheets

V - T - E Cheat Sheets
Developer / Builder
Assessment / Breaker
Mobile
OpSec / Defender
Draft and Beta
All Pages In This Category
Retrieved from "https://wiki.owasp.org/index.php?title=Query_Parameterization_Cheat_Sheet_(Hawaiian_Pidgin_English)&oldid=178095"