SQL Injection Attacks and Defense - 2009

Exploiting Authenticated Vulnerabilities
Advanced Topics • Chapter 7 337
Many SQL injection vulnerabilities reside within authenticated functionality. In some cases,
only privileged users, such as application administrators, can reach and exploit the vulnerability.
Usually, this constraint reduces the impact of the vulnerability somewhat.
If the administrator is completely trusted within the application, and is also able to
perform arbitrary SQL queries directly in the database, one might suppose that SQL
injection flaws which only the administrator can access are completely inconsequential,
and are not exploitable unless the attacker has already compromised the administrator’s
account.
However, this overlooks the possibility of cross-site request forgery. This attack
technique can be combined with many kinds of authenticated vulnerabilities to make
those vulnerabilities exploitable by an unprivileged attacker. Consider an administrative
function which displays the account details of a selected user:
https://www.example.org/admin/ViewUser.aspx?UID=123
The UID parameter is vulnerable to SQL injection, but this can be directly exploited
only by the administrator. However, an attacker who is aware of the vulnerability can use
cross-site request forgery to exploit the bug indirectly. For example, if he creates a Web page
containing the following HTML, and induces a logged-in administrator to visit it, his
injected SQL query will be executed, creating a new administrative user that is controlled by
the attacker:
Note that cross-site request forgery is a one-way attack, and the attacker cannot
trivially retrieve the application’s response to the attack request. Hence, the attacker
must inject an SQL query which causes a useful side effect, rather than just seeking to
read sensitive data.
The moral of this story is that cross-site request forgery does not need to involve
application functionality that was actually designed for performing sensitive actions. In the
example described, the application is no less vulnerable than if it contained an explicit
function for performing arbitrary SQL queries that was accessible only by administrators
but not protected from request forgery. And because the example described is not actually
designed for performing an action, it is much less likely to be included in the scope of any
antirequest forgery defenses that are implemented within the application.