Concept
The current revision of the PHP manual mentions that the rationale behind magic quotes was to "help reventcode written by beginners from being dangerous." It was however originally introduced in PHP 2 as a php.h compile-time setting for msql, only escaping single quotes, "making it easier to pass form data directly to msql queries". It originally was intended as a "convenience feature, not as security feature." The use scope for magic quotes was expanded in PHP 3. Single quotes, double quotes, backslashes and null characters in all user-supplied data all have a backslash prepended to them before being passed to the script in the$_GET
, $_REQUEST
, $_POST
and $_COOKIE
global variables. Developers can then in theory use string concatenation to construct safe SQL queries with data provided by the user. (This was most accurate when PHP 2 and PHP 3 were current, since the primary supported databases allowed only 1-byte character sets.)
Criticism
Magic quotes were enabled by default in new installations of PHP 3 and 4, but could be disabled through themagic_quotes_gpc
configuration directive. Since the operation of magic quotes was behind the scenes and not immediately obvious, developers may have been unaware of their existence and the potential problems that they could introduce. The PHP documentation pointed out several pitfalls and recommended that, despite being enabled by default, they should be disabled.
Problems with magic quotes included:
* Not all data that are supplied by the user are intended for insertion into a database. They may be rendered directly to the screen, stored in a session, or previewed before saving. This can result in backslashes being added where they are not wanted and being shown to the end user. This bug often creeps into even widely used software.
* Not all data that are supplied by the user and used in a database query are obtained directly from sources protected by magic quotes. For instance, a user-supplied value might be inserted into a database, protected by magic quotes, and later retrieved from the database and used in a subsequent database operation. The latter use is not protected by magic quotes, and a naive programmer used to relying on them may be unaware of the need to protect it explicitly.
* Magic quotes also use the generic functionality provided by PHP's addslashes()
function, which is not Unicode-aware and is still subject to SQL injection vulnerabilities in some multi-byte character encodings. Database-specific functions such as mysql_real_escape_string()
or, where possible, prepared queries with bound parameters, are preferred.
* While many Other approaches
* Some languages such as Perl and Ruby opt for an approach involving data tainting, where data from untrusted sources, such as user input, are considered "tainted" and can not be used for dangerous operations until explicitly marked as trustworthy, usually after validation or encoding. Since the construction of SQL queries is considered "dangerous" in this context, this forces the programmer to address the problem. Tainting does not solve the problem, but it does highlight those instances where there is a problem so that the programmer is able to solve them appropriately. * Joel Spolsky has suggested using a form ofSee also
*References
{{Reflist, 30emExternal links