If your website has fallen victim to SQL Injection, it may not be obvious. Perhaps your homepage is a little slow to load, or a JavaScript error icon has appeared in the lower left corner of your browser. In some cases the data on your site is not loading correctly at all. When your web host explains that the issue is SQL Injection, you immediately want to know "What is SQL Injection and how has it affected my website?"

First a little background on data-driven ASP websites. In the case of most of our clients, their data is stored in SQL databases and displayed/updated on their website with a combination of ASP code and SQL queries.

Use of ASP, aka Active Server Pages, began in the late 1990's. The idea of SQL Injection did not exist. Engineers built out dynamic websites which allowed users to enter data via custom-built admin tools. The front-end of their websites would connect to the database via ASP, query the database via SQL, and display this data to the end-user. We used simple and clean code to get and display this data and did not think about how that could be manipulated for ulterior motives.

Around 2004 / 2005 developers became aware of SQL Injection but it was not widespread and rather simple preventative measures were taken to avoid it. Within the last few months, however, the strategy of those attacking has evolved with the evolution of new technologies such as Google and automated web-surfing software. Would-be attackers used Google's search engine to identify sites vulnerable to an attack and then ran automated software that attacked each page.

So what exactly is happening when a site has been SQL Injected? The simple answer is that the attacker injects their own data into the database. The attacker changes the parameter being used by the code to lookup data in the database, whether it be in a login form or more frequently in a URL. For example:

• Most ASP websites use the URL to tell a page which piece of data to display. You might recognize it as something like this: http://www.website.com/DetailPage.asp?ID=3

• What that basically means is, "get me the data out of the database for item number 3". Attackers realized they could change that number 3 to SQL code that would end the Get SQL and then insert/inject their own text into the database.

• Now that the attacker's text is in the website's database, it is displayed to the user viewing the web page. Often times it is a link to another website or a file that could be downloaded onto the user's computer.

Why would the hacker want to do this?
There are many reasons including mischief, redirecting users to another website, and pulling secure data out of the database. Many are hoping that the people visiting the website don't have good protection on their computers which would allow software to be downloaded and installed. This software could track what websites the users go to and save what they type to get into their bank accounts, or what credit cards they enter when shopping online.

Now that we know, what are we doing to prevent it?
Most importantly, as we develop our websites, we ask ourselves continuously if we are leaving ourselves vulnerable in any way.

1. We always encrypt secure data in our clients' databases. This secure data is not readable unless run through special functions in the code to decrypt it. This way if an attacker tries to enter SQL code that will display secure data, anything encrypted will not be readable. There is nothing they could do with SQL code to decrypt it.

2. We also continuously backup our databases. If somehow an attacker gets in and injects data, we can restore to the clean data that existed before the attack.

3. New development projects are not coded with ASP anymore, but rather new technologies like .NET. All interactions with the database go through objects called stored procedures, which automatically make sure if you are looking up data, the parameters are valid and not text that a hacker might be trying to inject.

4. For our current clients with ASP websites, we have spent time going through all their files, checking to see if every place the database is accessed has been secured. We make sure only valid parameter types are queried on the database and that certain SQL code keywords are not included in any text parameters that could have been modified by users. Although we may have to take some extra time and effort to put these measures in place, our clients' data and their users' experiences on the website make it an absolute necessity.