Re: The "Best Practice" for securing my vb.net/SQL connection.
- From: RB <owmdkbqzikigpu@xxxxxxxxxxxxxx>
- Date: Thu, 08 Nov 2007 16:26:47 +0000
Hi Ammer,
Okay, I think my original understanding was basically correct.
Users will not be able to bypass the security built into the end client by using the SP to run select and update statements at will, because they cannot alter the stored procedures (as you would not have added them to a group which can alter procedures).
They will be able to execute the existing SPs however, thus bypassing any front-end validation your client application does. If this is your concern then I guess you'll have to employ one of the methods you outlined earlier.
Sorry that's not much help!!
Cheers,
RB.
Ammer wrote:
By tamper I mean. Bypass the security built into the end client by using the SP to run select and update statments at will. I don't think its a moot point though. Its the data people want to protect not so much the passwords..
What do you mean "login tamper" with an SP?
If you only give users Execute permissions on stored procedures and no other permissions, I don't really see what they can do to break things. Yes, they may be able to see other accounts, but I assume they won't have passwords to those accounts, so I think it's a moot point.
From Books Online:
"ALTER PROCEDURE permissions default to members of the sysadmin fixed server role, and the db_owner and db_ddladmin fixed database roles, and the owner of the procedure, and are not transferable."
So they will not be able to alter your stored procedures...
Not sure if any of that helps - I feel I've misunderstood your question, but I'm not sure where!!
Cheers,
RB.
- References:
- Prev by Date: Re: Old style Collections
- Next by Date: reflection VB2003 to VB2005
- Previous by thread: Re: The "Best Practice" for securing my vb.net/SQL connection.
- Next by thread: Re: The "Best Practice" for securing my vb.net/SQL connection.
- Index(es):
Relevant Pages
|
