Difference between revisions of "Improper type handling"
(Created page with "Integer handled as string Improper type handling is as common as it is dangerous. If a programmer makes the mistake of handling an integer as a string (or other type confusio...") |
|||
| Line 1: | Line 1: | ||
| − | + | Improper type handling is as common as it is dangerous. If a programmer makes the mistake of handling an integer as a string (or other type confusions), sanitizing inputs can become useless. There are a variety of approaches for mitigation of this type of issue. | |
| − | + | ||
| − | + | =Examples of integral handling vulnerabilities= | |
| − | + | ==PHP== | |
| − | + | {{code|text=<source lang="php"> | |
| − | + | <?php | |
| − | + | $id = mysql_real_escape_string($_GET['id']); | |
| − | + | @mysql_query("SELECT * FROM user WHERE user_id = " . $id . " LIMIT 1"); | |
| − | + | ?> | |
| − | + | </source>}} | |
| − | + | ||
| − | + | =Mitigation= | |
| − | + | If user_id is an integer, this statement is still vulnerable, if a user inputs "id=1%20OR1=1", the statement will not be escaped (since there are no quotes) and still a valid SQL statement, rendering the database open to injection. While this example uses SQL, other situations may still be vulnerable. In this case, for forward compatibility and "universal solution" purposes, the programmer should use the appropriate native (or generic) method to cast to an integer instead of mysql_real_escape_string(): | |
| − | + | ||
| − | + | ==PHP== | |
| − | + | {{code|text=<source lang="php"> | |
| − | + | <?php | |
| − | + | $id = (int)$_GET['id']; | |
| − | + | @mysql_query("SELECT * FROM user WHERE user_id = " . $id . " LIMIT 1"); | |
| − | + | ?> | |
| − | + | </source>}} | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ==Ruby== | |
| + | Warning: (link to ruby paramaterized section)Activerecord supports paramaterized statements(/link). It is likely that if you need to use this in conjunction with active record, you may be (link to unparamaterized queries) doing something wrong (/link). | ||
| + | |||
| + | =Auditing= | ||
Latest revision as of 02:53, 12 May 2013
Improper type handling is as common as it is dangerous. If a programmer makes the mistake of handling an integer as a string (or other type confusions), sanitizing inputs can become useless. There are a variety of approaches for mitigation of this type of issue.
Contents
Examples of integral handling vulnerabilities
PHP
<?php $id = mysql_real_escape_string($_GET['id']); @mysql_query("SELECT * FROM user WHERE user_id = " . $id . " LIMIT 1"); ?> |
Mitigation
If user_id is an integer, this statement is still vulnerable, if a user inputs "id=1%20OR1=1", the statement will not be escaped (since there are no quotes) and still a valid SQL statement, rendering the database open to injection. While this example uses SQL, other situations may still be vulnerable. In this case, for forward compatibility and "universal solution" purposes, the programmer should use the appropriate native (or generic) method to cast to an integer instead of mysql_real_escape_string():
PHP
<?php $id = (int)$_GET['id']; @mysql_query("SELECT * FROM user WHERE user_id = " . $id . " LIMIT 1"); ?> |
Ruby
Warning: (link to ruby paramaterized section)Activerecord supports paramaterized statements(/link). It is likely that if you need to use this in conjunction with active record, you may be (link to unparamaterized queries) doing something wrong (/link).
