At first glance this may seem like a straightforward and logical step for easily validatingusers, however if a simple substitution of the user entered values is performed on thistemplate, it is susceptible to an SQLI attack.For example, suppose “myuser’–” is entered in the user name field and “wrongpass” isentered in the password. Using simple substitution in our template query, we would getthis:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
A key to this statement is the inclusion of the two dashes
. This is the begin commenttoken for SQL statements, so anything appearing after the two dashes (inclusive) will beignored. Essentially, the above query is executed by the database as:
SELECT UserID FROM Users WHERE UserName='myuser'
The glaring omission here is the lack of the password check. By including the two dashesas part of the user field, we completely bypassed the password check condition and wereable to login as “myuser” without knowing the respective password. This act of manipulating the query to produce unintended results is a SQL injection attack.
What damage can be done?
A SQL injection attack is caused by negligent and irresponsible application coding and iscompletely preventable (which we will cover in a moment), however the extent of thedamage which can be done depends on the database setup. In order for a web applicationto communicate with the backend database, the application must supply a login to thedatabase (note, this is different than a user login to the web site itself). Depending onwhat permissions the web application requires, this respective database account canrequire anything from read/write permission in existing tables only to full database access.If this isn’t clear now, a few examples should help provide some clarity.Based on the above example, you can see that by entering, for example,
or any other user name, we can instantly login to the site as that user withoutknowing the password. Once we are in the system doesn’t know we are not actually thatuser so we have full access to the respective account. Database permissions will notprovide a safety net for this because, typically, a web site must have at least read/writeaccess to its respective database.Now let’s assume the web site has full control of its respective database which gives theability to delete records, add/remove tables, add new security accounts, etc. It is importantto note that some web applications could need this type of permission so it is notautomatically a bad thing that full control is granted.So to illustrate the damage which can be done in this situation, we will use the exampleprovided in the comic above by entering the following into the user name field:
"Robert';DROP TABLE Users;--".
After simple substitution the authentication query becomes:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' ANDPassword='wrongpass'
Note: the semicolon is in a SQL query is used to signify the end of a particular statement and the beginning of a new statement.
Which gets executed by the database as:
SELECT UserID FROM Users WHERE UserName='Robert'DROP TABLE Users
So just like that, we have used an SQLI attack to delete the entire Users table.Of course, much worse can be done as, depending the SQL permissions allowed, theattacker can change values, dump tables (or the entire database itself) to a text file, createnew login accounts or even hijack the entire database installation.
Preventing a SQL injection attack
As we mentioned several times previously, a SQL injection attack is easily preventable. Oneof the cardinal rules of web development is you never blindly trust user input as we didwhen we performed simple substitution in our template query above.An SQLI attack is easily thwarted by what is called sanitizing (or escaping) your inputs. Thesanitize process is actually quite trivial as all it essentially does is handle any inline single
converted by Web2PDFConvert.com