These are the common technique used today to prevent SQL Injection.
Sanitize the input, Escape/Quote safe the input, bound parameters, Limit database permissions and segregate users, Use stored procedures for database access, Isolate the webserver, Configure error reporting.
1. Sanitize and limit the Input
There are two way to limit the user input for a filed. First approach would be create a list of characters which should not allowed. This approach will not work because you are not sure what character user entered as input. You can not validated all the character because in web many character can be represent by alternative way. Second approach would be create a list which should allowed for a field. For example for a valid email id only this characters are allowed.
Alphabet Lower Case abcdefghijklmnopqrstuvwxyz
Alphabet Upper Case ABCDEFGHIJKLMNOPQRSTUVWXYZ
Number 0123456789
Special Chars @.-_+
You can create a validation routine to check character by character, any thing not in list is invalid character, warn user for that.
Dim ValidString As String
ValidString = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789@.-_+"
Dim i As Integer
For i = 1 To Len(TxtEmailID.Text)
If InStr(ValidString, Mid(TxtEmailID.Text, i, 1)) <= 0 Then
MsgBox("Invalid character found in email id.", MsgBoxStyle.Exclamation)
Exit For
End If
Next
2. Escape/Quote safe the input
Check the escape character like "\" and remove it from the input data. Filter out character like single quote, double quote, slash, back slash, semi colon, extended character like NULL, carry return, new line,
For numeric value, convert it to an integer before parsing it into SQL statement. Or using ISNUMERIC to make sure it is an integer.
3. Limit database permissions and segregate users
The web application ought to use a database connection with the most limited rights possible: query-only access to the members table, and no access to any other table. Even a "successful" SQL injection attack is going to have much more limited success. So hacker not have been able to do the UPDATE, DELETE request that ate user don't have the permission, Once the web application determined that a set of valid credentials had been passed via the login form, it would then switch that session to a database connection with more rights. It should go almost without saying that sa rights should never be used for any web-based application. If a hacker is get rights of sa that is System Administrator then he can able to do anything with your database.
4. Use stored procedures for database access
When the database server supports them, use stored procedures for performing access on the application's behalf, which can eliminate SQL entirely. By encapsulating the rules for a certain action - query, update, delete, etc. - into a single procedure, it can be tested and documented on a standalone basis and business rules enforced. For simple queries this might be only a minor benefit, but as the operations become more complicated (or are used in more than one place), having a single definition for the operation means it's going to be more robust and easier to maintain.
Note: it's always possible to write a stored procedure that itself constructs a query dynamically: this provides no protection against SQL Injection - it's only proper binding with prepare/execute or direct SQL statements with bound variables that provide this protection.
All database supports parameter passing mechanism, Its helpful to pass parameter to the database stored procedure to prevent SQL Injection.
5. Isolate the webserver
Even having taken all these mitigation and prevention steps, it's nevertheless still possible to miss something and leave the server open to compromise with the attacker. One ought to design the network infrastructure to assume that the bad guy will have full administrator access to the machine, and then attempt to limit how that can be leveraged to compromise other things. This won't stop everything, of course, but it makes it a lot harder.
6. Configure error reporting
The default error reporting for some frameworks includes developer debugging information, and this cannot be shown to outside users. Imagine how much easier a time it makes for an attacker if the full query is shown, pointing to the syntax error involved. I saw so many commercial web site make this silly mistake by not configure web server to show custom error message. Professional attacker easily understand so many useful information. This information is useful to developers, but it should be restricted - if possible - to just internal users.
7. Run SQL Server in Low privileges
Change "Startup and run SQL Server" using low privilege user in SQL Server Security tab. Delete stored procedures that you are not using like:
master..Xp_cmdshell, xp_startmail, xp_sendmail, sp_makewebtask
8. Preventing multi-statement attacks
All commercial database server support multiple statement execution. Look following query.
select * from user_master where user_name='ANYUSER' and
user_password ='ANYPASS' ; drop table user_master -- '
Its execute two query first query lookup for the User Table and Second query will delete the user_master table from the database. Attacker create and used multi query statement to perform SQL Injection. Used database option to prevent multi-statement query.
Information Source by - http://www.programmer2programmer.net
0 comments:
Post a Comment