Security and Scripting

  New Information - SQL Server 2000 SP3.

The flexibility and effectiveness of scripting is demonstrated by its widespread use in SQL Server 2000. However, this flexibility and effectiveness can potentially be exploited in unsafe ways. You should treat scripts like any other software package in terms of installation and security measures.

For more information about scripting, see this page on Microsoft.com.

Best Practices

The following suggestions should be considered best practices:

• When possible, set the script engine to run scripts in safe mode.
  
  
• If the script is to be distributed in a separate file, such as a Microsoft Visual Basic® Scripting Edition (VBScript) file (.vbs), consider using the Scripting Runtime Signer object to digitally sign the script.
  
  
• Avoid using COM libraries and ActiveX controls that are not marked as safe for initialization or scripting.
  
  
• Avoid using unsigned COM libraries and ActiveX controls.
  
  
• Always use the least privilege necessary to run a script.
  
  
• Validate all user input used by the script, and do not concatenate user input before validating it. Never execute a command constructed from user input that has not been validated. For more information, see Validating User Input.
  
  
• Never store security credentials as part of a script. If you must persist credentials, you should encrypt them with the Microsoft Win32® crypto API. For information about the crypto API, see this page on Microsoft.com.