php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #61708 Untrusted input variables tagging to detect and prevent SQL injection
Submitted: 2012-04-13 01:52 UTC Modified: 2012-04-13 19:52 UTC
From: forphponly at hostultra dot com Assigned:
Status: Not a bug Package: MySQL related
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
 [2012-04-13 01:52 UTC] forphponly at hostultra dot com
Description:
------------
I propose that PHP tag bytes in variables that come from untrusted sources such as user input (eg. $_GET $_POST $_COOKIE $_REQUEST etc..) or read from the database.
For each php variable, there would be a piece of metadata that defines the byte ranges in that variable containing bytes from untrusted sources.
This metadata would be updated whenever any php code or function changed the contents of a variable.
This is a very simple concept in theory, but I am not sure how difficult it would be to implement in php.

The mysql functions such as mysql_query() can then use the metadata to differentiate between bytes that come from untrusted sources from the part of the query that the programmer wrote.
eg. in my test script below, mysql_query() would know that the $username and $password parts in the $query variable are untrusted and must be escaped.

The php mysql functions can then alter the query to automatically add escaping before passing it on to mysql database thus making all SQL injection exploits obsolete without needing to rewrite any php code.

This would work similar to magic quotes, without the problem of double escaping or display errors when the variables are displayed on a webpage instead of used in a database.

A color diagram should make my idea more clear.
http://img690.imageshack.us/img690/3313/mysqlinjection.png

Test script:
---------------
<?php
// username and password variables vulnerable to SQL injection
// Example exploit http://server/test.php?username=john&password=' OR 1=1 --

$username = $_GET['username'];
$password = $_GET['password'];

$query = "SELECT * FROM `users` WHERE `username` = '$username' AND `password` = '$password' ";
$result = mysql_query ( $query );

?>

Expected result:
----------------
mysql_query() would change the query to
SELECT * FROM `users` WHERE `username` = 'john' AND `password` = '\' OR 1=1 --' 

Actual result:
--------------
The query that gets executed
SELECT * FROM `users` WHERE `username` = 'john' AND `password` = '' OR 1=1 --' 

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-04-13 02:01 UTC] sixd@php.net
-Status: Open +Status: Not a bug
 [2012-04-13 19:52 UTC] forphponly at hostultra dot com
Although I was not aware of the taint project before submitting this.
I believe my suggestion is substantially different.

Taint is subject to many false positives such as if input validation was done, but the variable was not cleaned with real_mysql_escape_string(), or the variable does not contain any unsafe characters.
Taint is also just taints the entire variable, and without knowing which specific bytes in the variable are tainted its not possible to automatically escape it.

Taint looks good for a programmer to detect bugs in a php app, but my suggestion was for more like something that can be installed on a production web server (eg. by a web hosting company) to protect all php applications from SQL injections, and without needing any changes to the php scripts being protected.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Apr 28 22:01:29 2024 UTC