A SQL Injection Attack is one of the many security issues that must be address when designing and developing applications that access a database. The injection vulnerability is potentially present on pages or forms where the user must enter a value to be submitted to the server. If the user input is not properly validated and the database doesn’t protect itself then SQLiA can occur. I have posted the source for the sample application on the portal. To download the SQL Injection Attack Sample Web Site and SQL Script click here: VB.Net Version or C# Version To run this demo code you will need Visual Studio 2008 or higher and SQL Server 2000 or higher installed. See the video below for an overview of the sample app.
The SQLInjectionDemo.zip file consists of a T-SQL Script file named CustomerOrdersDB_SQLInjection.sql used to create the database, tables (including sample data) and stored procedures (Stored procedures were created using CRUD Script) and a Visual Studio 2008 project called Demo.sln. The Visual Studio Solution contains 2 pages: SQLInjection.aspx and SQLInjectionFixed.aspx that as the names imply illustrate a page that is vulnerable to SQL Injection and one that is not (not all possible SQL injection attacks are prevented but most).
Test it out here: https://sqlinjectiondemocs.azurewebsites.net/
To test the search feature that’s vulnerable to SQL Injection:
Open the Solution (Demo.sln)
Select SQLInjection.aspx in the Solution Explorer
Press Ctrl + F5 or Select Start without Debugging from the Debug menu
Type Antoine into the search box
Press the Search button
Note: You will notice that the results displayed on the page are filtered to show only Antoine Victor.
Try a couple more searches then continue
Copy the injection statement from the bottom of the page
Paste into the search box
Press the Search button
Note: You will see a list of all of the tables defined in the current database and all columns defined in those tables.
Think credit card table, employee table with Social Security Numbers.
Armed with this information a hacker could use the same SQL Injection vulnerability in this page to then request columns and rows from the credit card or employees table.
Fortunately there is a relatively easy fix for this. The fix is a 2-part process, first we validate the user input before sending it to the server and removed any special characters or malicious code, and second we make all calls to the database through stored procedures (created automatically using CRUD Script or the SSMS Toolkit)
To see the page with the Injection issue resolved in the current browser window navigate to SQLInjectionFixed.aspx and follow the previous steps.
“This” SQL Injection issue is now resolved.
For a list of other common injection attacks to test with this demo see: SQL Injection Cheat Sheet.
For details on storing the connection string in the config file and stored procedure calls see the videos below.
Refactor the code so that it is easier to update and maintain:
Add stored procedures to prevent SQL Injection:
