SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


how to overcome sql injection


how to overcome sql injection

Author
Message
satishkatarapu
satishkatarapu
Forum Newbie
Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)

Group: General Forum Members
Points: 7 Visits: 13
Hi
we are not to keep our database or tables secured inspite of having password changed ,firewalls and spyware live. the hacker is injecting the java script code in the records of the tables . we found that code insertion is done at where the user is giving the input data. how to avoid this problem.
GilaMonster
GilaMonster
SSC Guru
SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)

Group: General Forum Members
Points: 87173 Visits: 45270
Parameterise all queries in your front end app. Do not concatenated together SQL statements and execute them.

Preferably, use stored procedures for data access only and do not allow the application user to have any rights to the base tables. The application user should have only execute rights on the stored procedures.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


John.Sansom
John.Sansom
SSC Eights!
SSC Eights! (803 reputation)SSC Eights! (803 reputation)SSC Eights! (803 reputation)SSC Eights! (803 reputation)SSC Eights! (803 reputation)SSC Eights! (803 reputation)SSC Eights! (803 reputation)SSC Eights! (803 reputation)

Group: General Forum Members
Points: 803 Visits: 1558
Hi,

Here are some recommendations for you:

1. Secure the Web Tier

You need to ensure that your application/website tier validates all user input before passing it on to the database layer. Rather than checking for invalid characters (quotations etc.), as there are potentially many, I recommend to my clients that they define a list of “valid” input values for their interfaces/forms etc.

2. Use Bound Parameters

In order to negate SQL Injection you need to ensure that any parameters that are passed to SQL calls are adequately bound.

3. Use Different Connections

Use different connections/logins for different tasks. I.e. the connection that is validating a user’s email address does not need to have update permissions to the database.I often recommend to clients that they use a connection/account with minimal privileges for all operations (i.e. logging a user into their system) unless otherwise necessary. Once a user has been authenticated they can be provided with access to/via another connection that has more privileges.

4. Use Stored Procedures

Use stored procedures to interact with your database rather than generating/building SQL dynamically.


Also take a look at the following Microsoft article: http://msdn.microsoft.com/en-us/library/ms161953.aspx

Hope this helps.


John Sansom (@sqlBrit) | www.johnsansom.com
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)

Group: General Forum Members
Points: 85923 Visits: 41091
In other words, you will need to rewrite part of the app to use stored procedures instead of dynamic embedded SQL.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Hari.Sharma
Hari.Sharma
SSCommitted
SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)

Group: General Forum Members
Points: 1580 Visits: 455
The best way to avoid SQL Injection is use of Stored Procedures.

Cheers,
Hari
Tips & Tricks for SQL BI Developers

GilaMonster
GilaMonster
SSC Guru
SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)

Group: General Forum Members
Points: 87173 Visits: 45270
Hari.Sharma (7/14/2008)
The best way to avoid SQL Injection is use of Stored Procedures.


The only way to 100% for certain avoid SQL injection is to use properly parameterised queries or stored procedures.

And don't make the mistake of using stored procedures that dynamically build up SQL strings inside the proc and then exec it. Procs like that are just as vulnerable to SQL injection as dynamic string on the front end.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


Andrew Gothard-467944
Andrew Gothard-467944
Old Hand
Old Hand (354 reputation)Old Hand (354 reputation)Old Hand (354 reputation)Old Hand (354 reputation)Old Hand (354 reputation)Old Hand (354 reputation)Old Hand (354 reputation)Old Hand (354 reputation)

Group: General Forum Members
Points: 354 Visits: 2357
A decent overview with examples and links is in Earland Sommarskog's article here;

http://www.sommarskog.se/dynamic_sql.html#SQL_injection

There's a lot more out there covering in more detail, but IMO this is a good starting point for getting the basic idea
hth Andrew
Perry Whittle
Perry Whittle
SSCoach
SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)

Group: General Forum Members
Points: 19948 Visits: 17242
some brilliant links and advice there, way to go guys BigGrin

-----------------------------------------------------------------------------------------------------------

"Ya can't make an omelette without breaking just a few eggs" ;-)
SQLNightOwl
SQLNightOwl
Old Hand
Old Hand (372 reputation)Old Hand (372 reputation)Old Hand (372 reputation)Old Hand (372 reputation)Old Hand (372 reputation)Old Hand (372 reputation)Old Hand (372 reputation)Old Hand (372 reputation)

Group: General Forum Members
Points: 372 Visits: 510
I'd say GilaMonster has it right. Dynamic SQL in any form (in an application or in a stored procedure) is vulnerable to SQL injection. The safest and best place for SQL DML code is in the database as a stored procedure. You could think of the stored procedures as the methods to a database object. In the .NET world you don't grant access to the internal code and data structures except thru properties and methods, so don't treat your database differently. Never grant users the ability to select, insert, update or delete anything directly from a table or view. Only allow them to execute stored procedures.

This is a point of control for the data. Besides, you don't want to face a news crew (or your boss) to try and explain how the data was compromised. Especially since these practices have been
best practices
for over a decade.

--Paul Hunter
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)SSC Guru (85K reputation)

Group: General Forum Members
Points: 85923 Visits: 41091
paulhunter (7/15/2008)
In the .NET world you don't grant access to the internal code and data structures except thru properties and methods, so don't treat your database differently.


THAT is one of the best justifications for stored procedures that I've seen. Thanks, Paul.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search