"There have been other papers on SQL injection,
including some that are much more detailed, but this one shows the
rationale of discovery as much as the process of exploitation.
. .
So the first test in any SQL-ish form is to
enter a single quote as part of the data: the intention is to see if
they construct an SQL string literally without sanitizing. When
submitting the form with a quote in the email address, we get a 500
error (server failure), and this suggests that the "broken" input is
actually being parsed literally. . .
This error response is a dead giveaway that
user input is not being sanitized properly and that the application
is ripe for exploitation. . .
Because the application is not really thinking
about the query - merely constructing a string - our use of quotes
has turned a single-component WHERE clause into a
two-component one, and the 'x'='x' clause is guaranteed to
be true no matter what the first clause is . . .
Friedl then goes on to show some fascinating
examples of how to guess the name of tables and the columns with the
tables:
"We'd dearly love to perform a
SHOW TABLE, but in
addition to not knowing the name of the table, there is no
obvious vehicle to get the output of this command routed to us.
So we'll do it in steps. In each case, we'll show the whole
query as we know it, with our own snippets shown specially. . .
The intent is to use a proposed field name (email) in
the constructed query and find out if the SQL is valid or not. .
.
If we get a server error, it means our SQL is malformed and a
syntax error was thrown: it's most likely due to a bad field
name. If we get any kind of valid response, we guessed the name
correctly. "
Overall, this is one of the best step-by-step examples of SQL
injection attacks and a must-read for any Oracle professional.
