www.Tutorialsforu.info

General SQL Techniques

The previous section’s focus on Microsoft SQL Server should not preclude you from trying
SQL injection techniques against other databases. MS SQL Server merely has an extreme
amount of functionality built into it that makes a SQL injection test more devastating. There
are still several techniques that apply to SQL-based databases. These techniques manipulate
the SQL statement by appending, inserting, and modifying normal SQL keywords—
using SQL against itself.
Remember to use placeholders for spaces when submitting SQL statements in the URL. The Web
server (and browser) will strip spaces unless they are occupied by “%20” or “+”.
SQL Operators SQL has a predefined list of keywords, or tokens, set aside to have special
meanings. If you want to select data from a table, you use the SELECT statement. A Web
application gets a lot of use out of SELECT, FROM, and WHERE tokens—these constitute
a basic query.ASQL injection can extend the query in order to retrieve alternate information
or generate an always true condition.

SQL statements are varied and often complicated. These few techniques represent the
wrenches you can use to pry open a database. More directed tests require more complicated
structures, but all of them rely on these basics.

These represent data manipulation techniques. The manner in which they are injected varies from a
single tick, to double dashes, to multiple ticks and parentheses. This is why it’s so important to be able
to walk through a series of SQL errors in order to find the right track into the database.

MOR 1=1
This statement of the obvious creates a true condition. This is useful in authentication
queries that check a username and password:

sqlAuth = "SELECT userid FROM logins WHERE name='" & Username & "' AND
password='" & Password & "'"

If a user logs in with the name “Wayne” and the password “Pirate,” then the query
would appear as:

SELECT userid FROM logins WHERE name='Wayne' AND password='Pirate'
Thus, Wayne couldn’t log in unless “Pirate” matches the entry in the database. However,
the “OR 1=1” tampers with this logic:

SELECT userid FROM logins WHERE name='Wayne' AND password='Pirate' OR 1=1
MUNION

A UNION statement combines SELECT statements. Use it to retrieve all rows from a
table. The basic syntax is
UNION ALL SELECT field FROM table WHERE condition
You can usually deduce the field and table from variable names in the application,
.inc files, or SQL errors. The condition is usually always true, such as 1=1 or ''='' (nothing
equals nothing).

MINSERT
The INSERT instruction does just that, inserts a value into a table. This might not seem
very useful; after all, we want to find out what’s in the database. It is useful for bypassing
authentication. Imagine if we use SQL injection to insert a new user into the Users table
with the name “neo” and password “trinity”:

INSERT INTO Users VALUES('neo', 'trinity')
Database Authentication Credentials A Web server needs to have a username and password
in order to connect to the database. The server makes this connection automatically.
Consequently, the application stores the authentication credentials somewhere within its
pages. Unfortunately, most applications store these connection strings in files in the Web
document root—a location accessible by the Web browser.

Sometimes developers rely on the server to protect sensitive files, such as IIS disallowing
requests for the global.asa file. However, if the application suffers from a file source disclosure
vulnerability (which happens with Web applications), then the username and
password may be up for grabs. Other times, the developers place the connection string in

files that they do not expect the user to find or view. These files have names such as
xmlserver.js, database.inc, or server.js.

An MS SQL Server connection string is easy to spot, especially when it has a blank
password:

strConn = "Provider=SQLOLEDB;Data Source=dotcomdb;Initial Catalog=Demo;
User Id=sa;Password="

Oracle’s global.jsa file might have credentials inside.
Common Countermeasures
Each database has its own methods of secure installation and security lockdown. Yet
there are steps you can take to defend against SQL injection attacks at the application
level. U Robust Error Handling
Never pass raw ODBC or other errors to the user. Use generic error pages and error handlers
to inform a user of a problem, but do not provide system information, variables, or
other data. In Java, for example, the best way to accomplish this is through the “try, catch,
finally” method of exception handling. U Parameter Lists
Place user-supplied data into specific variables. String concatenation is the bane of a
secure SQL statement because it provides the easiest way for a user to manipulate the
statement with tick marks.
Input validation should be performed on the Web server and items in the database
should be strongly typed. A field that only uses numeric values should be a type INT, not
a VARCHAR. U Stored Procedures
Although not a panacea, user-defined stored procedures are more difficult to break with
SQL injection. They require a specific number of parameters in specific places in a specific
format. That’s a lot of prerequisites to satisfy. Improved performance is often a byproduct
of stored procedures—it’s not just for security! U Running with Least Privilege
The database application should run in a least-privilege situation. Also, the user account
that the Web server uses should have limited functionality. Sure, it must read and write to
the database, but it doesn’t have to write to the Master database or perform backup duties.

Protecting the Schema
This might sound like a thinly veiled attempt at security through obscurity, but table
names, column names, and SQL structures should not appear in the HTML. We’ve
seen instances where the developer placed the entire table definition between HTML
comment tags. This might be a useful mnemonic; however, the comments would be
better placed between ASP comment tags where the developers can see them, but the
users cannot.