Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
mike123
Master Smack Fu Yak Hacker
1462 Posts |
 Posted - 2004-08-03 : 21:40:06
|
| Just wondering if I can get a hand with this one. It's been a long time security worry of mine. Its my only SPROC that is written in dynamic SQL and I *HATE* it. I'm worried about its vunerablity to sql injection.Is there a better way I can write this SPROC ? How can I make sure its not vunerable to sqlinjection attacks? I've never been comfortable enough determining its safe on my own.Thanks alotmike123CREATE PROCEDURE [delete_Messages] ( @MessageIDTXT VarChar(255), @MessageTo [int] ) AS SET NOCOUNT ON Declare @SQL VarChar(500) Select @SQL = 'DELETE [tblMessage] ' Select @SQL = @SQL + 'WHERE [MessageID] IN (' + @MessageIDTXT +') AND [MessageTo] = ' + CAST(@MessageTo As varchar) Exec ( @SQL) GO |
|
|
timmy
Master Smack Fu Yak Hacker
1242 Posts |
Posted - 2004-08-03 : 22:02:08
|
| One way to stop SQL injection is to remove any characters or character sequences that are used as breakout sequences from your parameters. These are generally apostrophes (') and comments (/*), but there's a few more that I can't remember at the moment.But - the best way of stopping SQL injection is to implement the filtering at the front-end application (I'm assuming it's ASP). For my app, I have a series of custom functions designed to read text fields, currency fields, date fields etc that validate each input and (in the case of strings) clean out script tags and other sequences used by hackers.You can also use URLScan to good effect for this (again, assuming you use IIS).Tim |
 |
|
|
kselvia
Aged Yak Warrior
526 Posts |
|
|
|
|
|
sqlinjection