Proposing SQL Statement Coverage Metrics: Difference between revisions

Line 47:

“select * from users where username =

‘$username’ AND password = ‘$password’”);

//extract the first row of the resultset

$firstresult = mysql_fetch_array($result);

//extract the “role” column from the result

$role = $firstresult[‘role’];

//set a cookie for the user with their role

setcookie(“userrole”, $role);

</code>

<center>'''Figure 4. Example authentication code'''</code>

The code in Figure 4 performs the following. First, query the database for every entry with the entered username and password. Typically, we use the first row of returned SQL results (which is retrieved by mysql_fetch_array and stored in $firstresult) because the web application (or the database management system)

will ensure that there are no duplicate usernames and will ensure that every user name is given the appropriate role. Finally, we

extract the role field from the first result and give the user a cookie<sup>4</sup>, which allows the login to be persistent (i.e., the user does not have to login to view every protected page). The example we have presented in Figure 4 performs no input validation, and as a result the example contains at least three input

validation vulnerability locations. The first two are the username and password fields as given in the web form in Figure 3. An attacker could cause the code fragment change shown in Figure 5 simply by entering the SQL command fragment “‘ OR 1=1 -- AND" in the input field instead of any valid user name in Figure

3.

== 9. References ==

@@ Line 47: / Line 47: @@
   “select * from users where username =
   ‘$username’ AND password = ‘$password’”);
-//extract the first row of the resultset
+  //extract the first row of the resultset
-$firstresult = mysql_fetch_array($result);
+  $firstresult = mysql_fetch_array($result);
-//extract the “role” column from the result
+  //extract the “role” column from the result
-$role = $firstresult[‘role’];
+  $role = $firstresult[‘role’];
-//set a cookie for the user with their role
+  //set a cookie for the user with their role
-setcookie(“userrole”, $role);
+  setcookie(“userrole”, $role);
 </code>
 <center>'''Figure 4. Example authentication code'''</code>
+The code in Figure 4 performs the following. First, query the database for every entry with the entered username and password. Typically, we use the first row of returned SQL results (which is retrieved by mysql_fetch_array and stored in $firstresult) because the web application (or the database management system)
+will ensure that there are no duplicate usernames and will ensure that every user name is given the appropriate role. Finally, we
+extract the role field from the first result and give the user a cookie<sup>4</sup>, which allows the login to be persistent (i.e., the user does not have to login to view every protected page). The example we have presented in Figure 4 performs no input validation, and as a result the example contains at least three input
+validation vulnerability locations. The first two are the username and password fields as given in the web form in Figure 3. An attacker could cause the code fragment change shown in Figure 5 simply by entering the SQL command fragment “‘ OR 1=1 -- AND" in the input field instead of any valid user name in Figure
+.
 == 9. References ==