Improving Web Application Security: Threats and - CGISecurity

532 Part IV: Securing Your Network, Host and ApplicationStep 12. SQL Server Database ObjectsSQL Server provides two sample databases for development and education togetherwith a series of built-in stored procedures and extended stored procedures. Thesample databases should not be installed on production servers and powerful storedprocedures and extended stored procedures should be secured.In this step, you:● Remove the sample databases.●●●Secure stored procedures.Secure extended stored procedures.Restrict cmdExec access to the sysadmin role.Remove the Sample DatabasesUse SQL Server Enterprise Manager to remove any sample databases. By default SQLServer includes the Pubs and Northwind sample databases.Secure Stored ProceduresRestrict access to your application’s stored procedures. Do not grant the public role orthe guest user access to any stored procedures that you create. Your main line ofdefense for securing stored procedures is to ensure that you use strongauthentication, and then to provide granular authorization, allowing only thenecessary users permission to run the stored procedures.The recommended approach is to create a SQL Server login for your application, mapthe login to a database user, add the user to a user-defined database role, and thengrant permissions to the role.Secure Extended Stored ProceduresDeleting stored procedures is not tested and not supported.Restrict cmdExec Access to the sysadmin RoleThe cmdExec function is used by the SQL Server Agent to execute Windowscommand-line applications and scripts that are scheduled by the SQL Server Agent.Prior to SQL Server Service Pack 3, by default the SQL Server Agent allows users whoare not in the sysadmin role to schedule jobs that may require privileged access to thesystem. You should change this setting to allow members only of the sysadmin roleto schedule jobs.