rfc:sql_injection_protection

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
rfc:sql_injection_protection [2015/07/28 16:45]
matttait
rfc:sql_injection_protection [2017/09/22 13:28] (current)
Line 3: Line 3:
   * Date: 2015-07-22   * Date: 2015-07-22
   * Author: Matt Tait, matttait#​at#​google.com   * Author: Matt Tait, matttait#​at#​google.com
-  * Status: ​Draft+  * Status: ​Under discussion
   * First Published at: http://​wiki.php.net/​rfc/​sql_injection_protection   * First Published at: http://​wiki.php.net/​rfc/​sql_injection_protection
 +  * You can [[http://​phpoops.cloudapp.net/​oops.php||try it online]] ([[http://​phpoops.cloudapp.net/​oops.php?​action=main&​dbg_sql&​limit=4%20ohdear|spoiler]])
  
 ===== Background ===== ===== Background =====
Line 46: Line 47:
  
 By design, SafeConstness is ***not** applied to the output of SQL-escape functions. Consider the following query: By design, SafeConstness is ***not** applied to the output of SQL-escape functions. Consider the following query:
-  mysqli_query("​SELECT * from USER where $id=" . mysqli_escape_query($_GET["​userid"​]))  +  mysqli_query("​SELECT * from USER where ID=" . mysqli_escape_query($_GET["​userid"​]))  
-This can be injected via page.php?​userid=1%20INJECT_HERE--. Even quoted forms [[[[http://​shiflett.org/​blog/​2006/​jan/​addslashes-versus-mysql-real-escape-string|charset bugs]]|can be injected ​in ways]] the code cannot ​easily ​verify: +This can be injected via page.php?​userid=1%20INJECT_HERE--. Even using correct SQL-escapes within quotes can [[[[http://​shiflett.org/​blog/​2006/​jan/​addslashes-versus-mysql-real-escape-string|can be injected]] ​in a way PHP cannot verify ​at runtime 
-  mysqli_query("​SELECT * from USER where $id='"​ . mysqli_escape_query($_GET["​userid"​]) . "'"​)+  mysqli_query("​SELECT * from USER where ID='"​ . mysqli_escape_query($_GET["​userid"​]) . "'"​) 
 It is a feature, not a bug, of this proposal that we are deliberately encouraging developers to parameterize,​ rather than escape their SQL queries. It is a feature, not a bug, of this proposal that we are deliberately encouraging developers to parameterize,​ rather than escape their SQL queries.
  
Line 199: Line 201:
  
 ===== Unaffected PHP Functionality ===== ===== Unaffected PHP Functionality =====
-This change is designed to have the minimum user-visible impact for websites ​that do not use SQL, or who use it in a safe way.+Websites ​that already adopt security-best-practice of only issuing dynamic queries to their SQL database via parameterized SQL statements with constant parameter-strings will see no change when this proposal is adopted.
  
 ===== Future Scope ===== ===== Future Scope =====
Line 205: Line 207:
  
 ===== Proposed Voting Choices ===== ===== Proposed Voting Choices =====
-This requires a 50%+1 vote to be adopted.+This does not introduce any syntax changes to the PHP language, and therefore ​requires a 50%+1 vote to be adopted.
  
 ===== Patches and Tests ===== ===== Patches and Tests =====
rfc/sql_injection_protection.1438101921.txt.gz · Last modified: 2017/09/22 13:28 (external edit)