Page 90 - Hands-On Bug Hunting for Penetration Testers

SQL, Code Injection, and Scanners Chapter 5

Now when we use BSBDIOJ later in the chapter, we can invoke it directly, as opposed to
having to type the full path each time.

SQLi and Other Code Injection Attacks `

Accepting Unvalidated Data

SQLi is a rather old vulnerability. It's been two decades since the first public disclosures of
the attack started appearing in 1998, detailed in publications such as Phrack, but it persists,
often in critically damaging ways. SQLi vulnerabilities can allow an attacker to read
sensitive data, update database information, and sometimes even issue OS commands. As
OWASP succinctly states, the "flaw depends on the fact that SQL makes no real distinction
between the control and data planes." This means that SQL commands can modify both the
data they contain and parts of the underlying system running the software, so when the
access prerequisites for a feature such as sqlmap's PT TIFMM flag are present, a SQLi
flaw can be used to issue system commands.

Many tools and design patterns exist for preventing SQLi. But the pressure of getting new
applications to market and iterating quickly on features means that SQLi-vulnerable inputs
don't get audited, and the procedures to prevent the bug are never put into place.

As a vulnerability endemic to one of the most common languages for database
development and as an easily detected, easily exploited, and richly rewarded bug, SQLi is a
worthy subject for study.

A Simple SQLi Example

Let's look at how SQLi breaks down into actual code.

Take a look at the following query, where the value of JE would be input supplied by the
user:
SELECT title, author FROM posts WHERE id=$id

[ 75 ]