|
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. |
