SQL injection – Security Testing Handbook for Banking Applications

2: Basic Tests and Techniques
weak session management
sensitive data in browser cache
over-reliance on client-side validation
unencrypted traffic
unhardened database
weak password policies
poor error handling mechanisms.
SQL injection
First of all what is an input field? Any field to which you
provide input is an input field. Every form that you fill on
the Internet has input fields – from your user name and
password to the comments you enter in a feedback form.
Any data that you type in/select/check is the ‘value’ for that
input field. When you click the Submit/Go button on the
form, the values of all those input fields are sent to the
application. The application sends this information to a
back-end database where your values are stored/compared
and relevant output returned to you. Before processing this
data, the application checks whether the data you entered is
in the form it expects. This is called ‘input validation’.
Applications generally validate the input for the data type,
the length and allowed range of values. So, for example, a
name in a date field will generate an error. Improper input
validation may pose a serious threat as it may lead to SQL
injection attacks.
What is SQL injection? Normally, the application takes
your input, processes it and passes it to the database.
Structured Query Language or SQL is the language the
database understands. So when you send a request to the
application to view your account statement, the application
2: Basic Tests and Techniques
constructs an SQL query with your input, queries the
database and returns your account statement. If you were
able to structure the input in such a way that the resultant
query retrieved the account statement of all other users as
well – that’s SQL injection.
For example, if user Bill clicks on the ‘Show account
statement’ button, the application constructs an SQL query
of the form:
SELECT acct_statement FROM users_acct_statement
WHERE username=bill;
and sends it to the database. Now suppose, instead of ‘Bill’,
in the username field an attacker enters ‘OR 1=1. The
actual query just before it hits the database will read:
SELECT acct_statement FROM users_acct_statement
WHERE username= ’OR 1=1;
What the attacker is trying to tell the database is: It doesn’t
matter who the user is – just give me all data in the
acct_statement column. If the application is vulnerable it
will just throw back everyone’s account statements on
screen. We’ll discuss how exactly an attacker does this and
what tools they use in the next chapter.
To avoid SQL injection, we need to implement strong input
validation in the application. The most effective and secure
way would be to have a white list of characters that are
allowed. Any character that is not used by the application is
not included in this list. We then write a filtering function
which will intercept every request (GET or POST) sent to
the application and disallow all requests that have such