Recently I conducted an interview with Jacky Chen, EVERWORKS’S Leading System Architect. I was rather shocked to find out that a SQL Injection Attack is rather serious. Don’t take my word for it; hear what Jacky has to say with his experience with it.
This brings me back to one of my bad experiences few years back when I just stepped into my 1st employment after my graduation. In those days, security is more emphasized on exposure of the source codes, or a networking related issue; seldom looking over the security of the database. On one Monday morning, after coming back from a long weekend, the whole development team was shocked after discovering that the whole production database was gone. Lucky for the team the database was restored from daily backups that had earlier been implemented. After much investigation, we discovered a security loophole on the website pages which led to this catastrophic issue. The ‘hacker’ has injected SQL commands to delete all the tables in the database via the form’s input boxes.
I want to give you a solution so that you can perform a fix-it-yourself action with stuff that actually make sense! (Hey I am no software engineer, coder, or programmer; when I see code all I see is stuff from Matrix.)
I know, I know, you must be thinking why should you take my advice on code, when I have little or no knowledge of it! Well you see that is where Jacky comes in, his many years of experience is just one of the benefits you will gain as you continue to read this!
Simple basic SQL Injection solutions
So I promised you some simple stuff that makes sense to any person, and it will generally work.
Firstly lets start with identifying some simple things before we actually get underway. Let’s ask Jacky and see what he has to say!
- Why is it important to protect yourself against SQL Injection Attacks?
- Just how serious can SQL Injection Attacks be?
Once an attacker realizes that a system is vulnerable to SQL Injection, he is able to inject a series SQL Query / Commands through an input form field. This is equivalent to handing the attacker your database and allowing him to execute any SQL command including a DROP TABLE to the database!
An attacker may execute arbitrary SQL statements on the vulnerable system. This may compromise the integrity of your database and/or expose sensitive information. Depending on the back-end database in use, SQL injection vulnerabilities lead to varying levels of data/system access for the attacker. It may be possible to manipulate existing queries, to UNION (used to select related information from two tables) arbitrary data, use sub-selects, or append additional queries.
In some cases, it may be possible to read in or write out to files, or to execute shell commands on the underlying operating system. Certain SQL Servers such as Microsoft SQL Server contain stored and extended procedures (database server functions). If an attacker can obtain access to these procedures, it could spell disaster.
Unfortunately the impact of SQL Injection is only uncovered when the theft is discovered. Data is being unwittingly stolen through various hack attacks all the time. The more expert of hackers rarely get caught.
Knowing this is rather terrifying! What if I told you just some simple basic solutions to get you underway? A little bit so that it would help with some prevention against this attacks!
Pay attention now here are two solutions you can implement right away!
There are several of ways in preventing the SQL Injection; one of the simple ways is using Parameterized Queries. SQL Server, like many database systems, supports a concept called parameterized queries. This is where the SQL Command uses a parameter instead of injecting the values directly into the command. The particular second-order attack above would not have been possible if parameterized queries had been used.
The second one is cleaning and validating an input. In many applications, the developer has sidestepped the potential use of the apostrophe as a way to get access to the system by performing a string replace on the input given by the user. This is useful for valid reasons, such as being able to enter surnames such as "O'Brian" or "D'Arcy", and so the developer may not even realize that they have partly defeated a SQL injection attack. It is also imperative that the input from the user is checked to determine that it really is a number, and in the valid range.
So now that you have a rough idea of what you could potentially gain from just performing simple steps! Now what else could be better? Simple solutions for everyone with minimal effort required.
Some topics for discussion:
- Any experience you have with SQL Injection Attack
- How you went about a SQL Injection Attack?
0 comments:
Post a Comment