Re: Website & SQL Server Security
- From: "Mark McGinty" <mmcginty@xxxxxxxxxxxxxxx>
- Date: Fri, 29 Aug 2008 16:05:07 -0700
"csgraham74" <colin@xxxxxxxxxxxxxxxx> wrote in message
news:97929c8c-2936-4d02-ab24-683bec63d430@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Ok,
im sure this has been dealt with before but when i read other posts i
kinda get lost in the jargon. Ok the reason for my being here is that
i developed a website that recently got hit by a sql injection attack.
Of the back of that i have decided to rethink my security strategy to
ensure it doesnt happen again.
from my vague understanding of sql server i have decided to setup my
sql server authentication to allow only db_datareader access and also
to give grant permissions to my stored procedures.
To me this means that front end users will only be able to run
"SELECT" command statements on my datatables & run the stored
procedures as i have set them up.
what im wondering about is this really what this means or does this
mean that someonce could do sql injection again through one of my
forms and delete or insert into my database ????
BTW ive added extra validation to all my user input formsto restrict
SQL Injection but its the database stuff i need to know more about.
any help appreciated.
You realize that to use impersonation (where SQL statements within a stored
procedure execute with privileges of the procedure's owner, when called by
less-privileged users who have been granted permission to execute) those
stored procedures cannot use any dynamic SQL within them. (Well actually,
they can, but dynamic SQL in them executes with the privileges of the
caller, not the owner.)
But the bonus of doing all your writes from within stored procedures is that
you guarantee yourself at least some degree of parameterization, and as long
as you don't concatenate dynamic T-SQL statements with user input passed as
parameters into your procs, it's much easier to safely implement a fair
level of dynamic -- for example, sp_executesql provides a way to pass
parameters to dynamic SQL. Given that this is the case, with due caution,
you can create privileged connections to execute the stored procedures, and
unprivileged connections to do the rest, without sacrificing too much
safety.
-Mark
CG
.
- References:
- Website & SQL Server Security
- From: csgraham74
- Website & SQL Server Security
- Prev by Date: Re: How to verify whether a user has been added to a database role
- Next by Date: Re: Website & SQL Server Security
- Previous by thread: Website & SQL Server Security
- Next by thread: Re: Website & SQL Server Security
- Index(es):
Relevant Pages
|
Loading