on. Not all attacks, though, are injection attacks. Other attacks use headers or are a
result of a form of social engineering, where the expectation is the user won’t
notice
something is wrong while it’s happening. Following are explanations of some of the
common web attacks, so you will have a better idea of what is being tested when we
start looking at tools a little later.
As you are looking
through these attack types, keep the target of the attack in mind.
Each attack may target a different element of the entire application architecture,
which means the attacker gets access to different components with different sets of
data to achieve different results. Not all attacks are created equal.
SQL Injection
It’s hard to count the number of web applications that
use a database for storage, but
as a proportion, it’s likely large. Even if there is no need for persistent storage of user
information, a database could help to guide the application in what is presented. This
may be a way of populating changing information without having to rewrite code
pages. Just
dump content into the database, and that content is rendered when a user
comes calling. This means that if you are looking to attack a web application, espe‐
cially one where there is significant interaction with the user, there is probably a data‐
base behind it all, making this a significant concern when testing the application.
Structured Query Language (SQL) is a standard way of issuing
queries to relational
databases. It has existed in one form or another for decades and is a common lan‐
guage used to communicate with the databases behind the web application. A com‐
mon query to a database, looking to extract information, would look something like
"SELECT * FROM mydb.mytable WHERE userid = 567"
.
This tells the SQL server to
retrieve all records from the
mytable
in the
mydb
database where the value in the col‐
umn named
userid
is equal to
567
. The query will run through all of the rows in the
database looking for matching results. The results will be
returned in a table that the
application will have to do something with.
If you are working with a web application, though, you are probably not using con‐
stant values like 567. Instead, the application is probably using a variable as part of
the query. The value inside the variable is inserted into the query just before the
query is sent off to the database server. So, you might have something like
"SELECT *
FROM mydb.mytable WHERE username = '",
username, "';"
. Notice the single
quotes inside the double quotes. Those are necessary to tell the database server that
you are providing a string value. The value of the variable username would be inser‐
ted into the query. Let’s say, though, that the attacker were to input something like
'
OR '1' = '1
. This means the query being passed into the server would look like this:
"SELECT * FROM mydb.mytable WHERE username = '' OR '1' = '1';"
.
