Github 1

[armorcodegithubapp]

Category: SQL Injection
Sub Category: null
Instance Id: 02BCC3964E9F62ECA012D20F1D80379F
Accuracy: 5.0
Impact: 5.0
RemediationEffort: 1.0
Probability: 5.0
Scan Type: Static
Abstract: Line 44 of db.php invokes a SQL query built using input coming from an untrusted source. This call could allow an attacker to modify the statement's meaning or to execute arbitrary SQL commands.Constructing a dynamic SQL statement with input coming from an untrusted source might allow an attacker to modify the statement's meaning or to execute arbitrary SQL commands.
Trace Details:
onlinetests/app/classes/user.php:72 - Read $_POST
onlinetests/app/classes/user.php:72 - Assignment to temp~foreach~list~0
onlinetests/app/classes/user.php:72 - each(0 : return)
onlinetests/app/classes/user.php:72 - Assignment to temp~foreach~1
onlinetests/app/classes/user.php:72 - Assignment to $k
onlinetests/app/classes/user.php:75 - Assignment to $cols
onlinetests/app/classes/user.php:81 - Assignment to $cols
onlinetests/app/classes/user.php:84 - Assignment to $sql
onlinetests/app/classes/user.php:87 - query(0)

onlinetests/app/classes/user.php:72 - Read $_POST
onlinetests/app/classes/user.php:72 - Assignment to temp~foreach~list~0
onlinetests/app/classes/user.php:72 - each(0 : return)
onlinetests/app/classes/user.php:72 - Assignment to temp~foreach~1
onlinetests/app/classes/user.php:72 - Assignment to $v
onlinetests/app/classes/user.php:76 - Assignment to $values
onlinetests/app/classes/user.php:82 - Assignment to $values
onlinetests/app/classes/user.php:84 - Assignment to $sql
onlinetests/app/classes/user.php:87 - query(0)
Source Snippet:
onlinetests/app/classes/user.php:69

			$cols 	= '';
			$values = '';
			
			foreach($_POST as $k => $v) {
				// filter dob
				if(($k != 'dob_month') || ($k != 'dob_day') || ($k != 'dob_year')) {
					$cols 	.= "$k, ";

Sink Snippet:
onlinetests/app/classes/db.php:41

			$return = mysql_insert_id();
			
		} elseif(stristr($sql, 'UPDATE')) {
			mysql_query($sql) or die(mysql_error());
			$return = '';
		}
		

Explanation:SQL injection errors occur when:

1. Data enters a program from an untrusted source.

In this case the data enters at in **user.php** at line **72**.

2. The data is used to dynamically construct a SQL query.

In this case the data is passed to in **db.php** at line **44**.

Example 1: The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where the owner matches the user name of the currently-authenticated user.

	...
	$userName = $_SESSION['userName'];
	$itemName = $_POST['itemName'];
	$query = "SELECT * FROM items WHERE owner = '$userName' AND itemname = '$itemName';";
	$result = mysql_query($query);
	...

The query that this code intends to execute follows:

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:

	SELECT * FROM items;

This simplification of the query allows the attacker to bypass the requirement that the query only return items owned by the authenticated user; the query now returns all entries stored in the items table, regardless of their specified owner.

Example 2: This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name wiley enters the string "name'; DELETE FROM items; --" for itemName, then the query becomes the following two queries:

	SELECT * FROM items 
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

Many database servers, including Microsoft(R) SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed [4]. In this case the comment character serves to remove the trailing single-quote left over from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:

	SELECT * FROM items 
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from a whitelist of safe values or identify and escape a blacklist of potentially malicious values. Whitelisting can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, blacklisting is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers can:

• Target fields that are not quoted

• Find ways to bypass the need for certain escaped meta-characters

• Use stored procedures to hide the injected meta-characters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.

File Path: onlinetests/app/classes/db.php:44

Mitigation: The root cause of a SQL injection vulnerability is the ability of an attacker to change context in the SQL query, causing a value that the programmer intended to be interpreted as data to be interpreted as a command instead. When a SQL query is constructed, the programmer knows what should be interpreted as part of the command and what should be interpreted as data. Parameterized SQL statements can enforce this behavior by disallowing data-directed context changes and preventing nearly all SQL injection attacks. Parameterized SQL statements are constructed using strings of regular SQL, but where user-supplied data needs to be included, they include bind parameters, which are placeholders for data that is subsequently inserted. In other words, bind parameters allow the programmer to explicitly specify to the database what should be treated as a command and what should be treated as data. When the program is ready to execute a statement, it specifies to the database the runtime values to use for each of the bind parameters without the risk that the data will be interpreted as a modification to the command. When connecting to MySQL, the previous example can be rewritten to use parameterized SQL statements (instead of concatenating user supplied strings) as follows:

	...
	$mysqli = new mysqli($host,$dbuser, $dbpass, $db);
	$userName = $_SESSION['userName'];
	$itemName = $_POST['itemName'];
	$query = "SELECT * FROM items WHERE owner = ? AND itemname = ?";
	$stmt = $mysqli->prepare($query);
	$stmt->bind_param('ss',$username,$itemName);
	$stmt->execute();
	...

The MySQL Improved extension (mysqli) is available for PHP5 users of MySQL. Code that relies on a different database should check for similar extensions. More complicated scenarios, often found in report generation code, require that user input affect the structure of the SQL statement, for instance by adding a dynamic constraint in the WHERE clause. Do not use this requirement to justify concatenating user input to create a query string. Prevent SQL injection attacks where user input must affect command structure with a level of indirection: create a set of legitimate strings that correspond to different elements you might include in a SQL statement. When constructing a statement, use input from the user to select from this set of application-controlled values.

Finding Id : 532026776

[armorcodegithubapp]

Finding [532026776] status changed to Confirmed
Note:
by vincent.goyal@armorcode.io via ArmorCode Platform