Proposing SQL Statement Coverage Metrics: Difference between revisions

Line 71:

‘’ OR 1=1 -- AND password = ‘PASSWORD’”);

<center>'''Figure 5. Example SQL statement, before and after

<center>'''Figure 5. Example SQL statement, before and after</center>

The single quotation mark (<code>'</code>) indicates to the SQL parser that the character sequence for the username column is closed, the fragment <code>OR 1=1</code> is interpreted as always true, and the hyphens (<code>--</code>) tells the parser that the SQL command is over and the fragment of the query after the hyphens is a comment. With these values, the $result variable contains a list of every user in the table (and their associated role) because the where clause is always true. The first listing returned from the database is unknown and will vary based on the database configuration. Regardless, the role of the user in the first returned row will be extracted and assigned to a cookie on the attacker’s machine. The consequence is as follows: Assuming the attacker is not a registered user of the system, he or she has just been granted unauthorized access to the system with the role (and identity) associated with the first username in the table. The password field shown in Figure 3 is also vulnerable, but we do not demonstrate this attack for space reasons. Because no input validation was performed, the system can be exploited for a use that was unintended by its developers.

The exploitation of the third vulnerability requires slightly more work than the first two, but is more threatening. Presumably, the developer of this example web application provides different content to a given web user (or provides no content at all) depending on the role parameter, which is stored in a cookie. An example code for the design decision of using a cookie is Figure 6.

The <code>$_COOKIE[‘role’]</code> macro extracts the value stored on the user’s machine for the parameter passed (in this case “role”). The web application provides one set of content for users with the administrator role and another set of content for those with the employee role. If the role parameter is anything else, the user is redirected to <code>authrequired.html</code>, which presumably contains some type of message to the user that authentication is required to access the requested page. The vulnerability stems from the relatively well-known fact that HTTP cookies are usually stored in a text file on the user’s machine. In this case, the attacker need only to edit this file and see that there is a parameter named “role” and a reasonable guess for the authentication value would be “admin”. The consequence is as follows: If the attacker succeeds in guessing the correct value, the system provides content to a user who was unauthorized to view it and the system has been exploited.

== 9. References ==

@@ Line 71: / Line 71: @@
     ‘’ OR 1=1 -- AND password = ‘PASSWORD’”);
-<center>'''Figure 5. Example SQL statement, before and after
+<center>'''Figure 5. Example SQL statement, before and after</center>
+The single quotation mark (<code>'</code>) indicates to the SQL parser that the character sequence for the username column is closed, the fragment <code>OR 1=1</code> is interpreted as always true, and the hyphens (<code>--</code>) tells the parser that the SQL command is over and the fragment of the query after the hyphens is a comment. With these values, the $result variable contains a list of every user in the table (and their associated role) because the where clause is always true. The first listing returned from the database is unknown and will vary based on the database configuration. Regardless, the role of the user in the first returned row will be extracted and assigned to a cookie on the attacker’s machine. The consequence is as follows: Assuming the attacker is not a registered user of the system, he or she has just been granted unauthorized access to the system with the role (and identity) associated with the first username in the table. The password field shown in Figure 3 is also vulnerable, but we do not demonstrate this attack for space reasons. Because no input validation was performed, the system can be exploited for a use that was unintended by its developers.
+The exploitation of the third vulnerability requires slightly more work than the first two, but is more threatening. Presumably, the developer of this example web application provides different content to a given web user (or provides no content at all) depending on the role parameter, which is stored in a cookie. An example code for the design decision of using a cookie is Figure 6.
+The <code>$_COOKIE[‘role’]</code> macro extracts the value stored on the user’s machine for the parameter passed (in this case “role”). The web application provides one set of content for users with the administrator role and another set of content for those with the employee role. If the role parameter is anything else, the user is redirected to <code>authrequired.html</code>, which presumably contains some type of message to the user that authentication is required to access the requested page. The vulnerability stems from the relatively well-known fact that HTTP cookies are usually stored in a text file on the user’s machine. In this case, the attacker need only to edit this file and see that there is a parameter named “role” and a reasonable guess for the authentication value would be “admin”. The consequence is as follows: If the attacker succeeds in guessing the correct value, the system provides content to a user who was unauthorized to view it and the system has been exploited.
 == 9. References ==