Questions about this topic? Sign up to ask in the talk tab.

Improper type handling

From NetSec
Jump to: navigation, search

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

 
<?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).

Auditing