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


Using Certificates to Sign Stored Procedures


Using Certificates to Sign Stored Procedures

Author
Message
SQL_Elvis
SQL_Elvis
SSC-Enthusiastic
SSC-Enthusiastic (167 reputation)SSC-Enthusiastic (167 reputation)SSC-Enthusiastic (167 reputation)SSC-Enthusiastic (167 reputation)SSC-Enthusiastic (167 reputation)SSC-Enthusiastic (167 reputation)SSC-Enthusiastic (167 reputation)SSC-Enthusiastic (167 reputation)

Group: General Forum Members
Points: 167 Visits: 143
One benefit is that the Certificate and certificate user account are managed outside of the stored procedure code and can be updated or the user account changed without having to change the stored proc code for every procedure that uses thecert. "With Execute as" is embedded in the code so each proc would have to be altered in the case that you needed to change the user (ex. user account is compromised by a terminated employee).
Tom Garth
Tom Garth
Ten Centuries
Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)

Group: General Forum Members
Points: 1241 Visits: 1499
SQL_Elvis (6/21/2010)
One benefit is that the Certificate and certificate user account are managed outside of the stored procedure code and can be updated or the user account changed without having to change the stored proc code for every procedure that uses thecert. "With Execute as" is embedded in the code so each proc would have to be altered in the case that you needed to change the user (ex. user account is compromised by a terminated employee).

Definitely true with SQL Server authentication. With Windows Authentication, Security Groups are a little easier, but certificates are still an option.

Tom Garth
Vertical Solutions

"There are three kinds of men. The one that learns by reading. The few who learn by observation. The rest of them have to pee on the electric fence for themselves." -- Will Rogers

UMG Developer
UMG Developer
SSCrazy
SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)

Group: General Forum Members
Points: 2672 Visits: 2204
SQL_Elvis (6/21/2010)
One benefit is that the Certificate and certificate user account are managed outside of the stored procedure code and can be updated or the user account changed without having to change the stored proc code for every procedure that uses thecert. "With Execute as" is embedded in the code so each proc would have to be altered in the case that you needed to change the user (ex. user account is compromised by a terminated employee).


I think you get the same benefit by using "proxy" logins, that can't actually log-in to the DB, so the login itself can't be compromised:

CREATE USER [Proxy_User] WITHOUT LOGIN WITH DEFAULT_SCHEMA=[dbo]



Then you just assign the SP to EXECUTE AS that login:

CREATE PROCEDURE [dbo].[usp_xxx] (@SQL VARCHAR(MAX))
WITH EXECUTE AS N'Proxy_User'



But I don't see how either using the certificates or the proxy login protects you from SQL injection attacks when using dynamic SQL, as the SP can still do anything that the certificate user/proxy login has permissions to do. What it does do is make it so we don't have to give end-users direct access to the data, or have the application login with an account that can be compromised.
Jonathan AC Roberts
Jonathan AC Roberts
SSC Eights!
SSC Eights! (857 reputation)SSC Eights! (857 reputation)SSC Eights! (857 reputation)SSC Eights! (857 reputation)SSC Eights! (857 reputation)SSC Eights! (857 reputation)SSC Eights! (857 reputation)SSC Eights! (857 reputation)

Group: General Forum Members
Points: 857 Visits: 1905
UMG Developer (6/21/2010)
But I don't see how either using the certificates or the proxy login protects you from SQL injection attacks when using dynamic SQL, as the SP can still do anything that the certificate user/proxy login has permissions to do.

Yes that's true but I did add at the bottom of the article that "Signing stored procedures is a step to making your application SQL injection proof, you would also need to make sure that any stored procedures that use dynamic SQL do not allow injection, this can be achieved using parameterised dynamic SQL". So the steps to make sure your application not SQL injectable is both to not granting users any access rights to tables and also making sure that any stored procedures that use dynamic SQL use parameters.
Jonathan AC Roberts
Jonathan AC Roberts
SSC Eights!
SSC Eights! (857 reputation)SSC Eights! (857 reputation)SSC Eights! (857 reputation)SSC Eights! (857 reputation)SSC Eights! (857 reputation)SSC Eights! (857 reputation)SSC Eights! (857 reputation)SSC Eights! (857 reputation)

Group: General Forum Members
Points: 857 Visits: 1905
janyalee (6/21/2010)
Using a Certificate Versus Stored Procedure WITH EXECUTE AS
Hello Jonathan, I appreciated this article. It got me wondering, what signing with a certificate gets us that SP WITH EXECUTE AS functionality does not?
Either way we grant myCertUserName read access to the underlying tables called by the sp.
CREATE PROCEDURE dbo.usp_Demo
WITH EXECUTE AS 'CompanyDomain\myCertUserName'
AS
SELECT user_name();
GO
Thank you in advance for your feedback.

Both methods achieve the same thing but using certificates is generally recommended. Some things are different for example if there is auditing a table with a trigger and the function user_name() is used then the function would return the EXECUTE AS user not the actual caller of the stored procedure. Also, if another stored procedure is called from within the stored procedure it would execute that stored procedure with the EXECUTE AS user rather than the actual user.
UMG Developer
UMG Developer
SSCrazy
SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)

Group: General Forum Members
Points: 2672 Visits: 2204
Jonathan AC Roberts (6/21/2010)
Both methods achieve the same thing but using certificates is generally recommended. Some things are different for example if there is auditing a table with a trigger and the function user_name() is used then the function would return the EXECUTE AS user not the actual caller of the stored procedure. Also, if another stored procedure is called from within the stored procedure it would execute that stored procedure with the EXECUTE AS user rather than the actual user.


You can, and probably should use the ORIGINAL_LOGIN() function in any logging you do in triggers so that you can get the actual user in the cases of EXECUTE AS.
ChiragNS
ChiragNS
Hall of Fame
Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)

Group: General Forum Members
Points: 3365 Visits: 1865
Jonathan AC Roberts (6/21/2010)
ChiragNS (6/21/2010)

We granted select permissions to mycertificateuser. Do we need to give permissions to all the other users who are going to execute the procedure (i think not.. thats the point of this article).
You need to grant EXECUTE permission to the stored procedure to all users who need to execute the procedure but you do not need to grant them any access to the tables if you use a certificate.

User xyz has been given execute permissions to the stored procedure and no select permissions on the underlying tables. When xyz executes this procedure does the exectution context belong to mycertificateuser. How does xyz get access to the underlying tables in the dynamic sql in hte stored procedure.
The procedure is executed by user 'xyz' but the stored procedure gets its permission to select from the table through the certificate.


Thank you Jonathan

"Keep Trying"
SQLRNNR
SQLRNNR
SSC-Dedicated
SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)SSC-Dedicated (32K reputation)

Group: General Forum Members
Points: 32094 Visits: 18551
Thanks for taking the time to share this with us.



Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server, MVP


SQL RNNR

Posting Performance Based Questions - Gail Shaw

James Woodhouse
James Woodhouse
Forum Newbie
Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)

Group: General Forum Members
Points: 5 Visits: 42
Hi Jonathan. Good article - however, I have run into a hitch.
I'm trying to use table functions to encapsulate logic for re-use.
If the signed procedure accesses the tables directly, the certificate and the certificate user allow this to occur.
However, you can't sign a table function, and a procedure which calls a table function which then selects from the table... no joy here either.
It's like the security link between the procedure and the user is lost in translation.
Can you tell me if I'm on a no hoper here? Or is there a way to do this?
Regards,
James
Jonathan AC Roberts
Jonathan AC Roberts
SSC Eights!
SSC Eights! (857 reputation)SSC Eights! (857 reputation)SSC Eights! (857 reputation)SSC Eights! (857 reputation)SSC Eights! (857 reputation)SSC Eights! (857 reputation)SSC Eights! (857 reputation)SSC Eights! (857 reputation)

Group: General Forum Members
Points: 857 Visits: 1905
Hi James,
I'm not sure exactly what you are trying to do. Is it that you have a stored procedure that calls an inline table function and it's the inline table function that accesses a table with dynamic sql? Maybe if you can paste the two routines in this thread or some more details?
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