Core SQLXML Security Considerations
The following are security guidelines for using SQLXML for data access.
The SQLXMLOLEDB provider exposes a StreamFlags property which allows you to set flags indicating what SQLXML functionality should be enabled or disabled for each specific instance. You can use this property to customize your use of SQLXML and to make sure that only the components you want are enabled. For more information, see SQLXMLOLEDB Provider (SQLXML 4.0).
When SQLXML errors occur and are returned, they can include information about the database schema such as table names, column names or type information. You should use care when handling these errors so that information about your SQL Server installation is not easily discoverable by users where it is not intended or needed.
When used to either query or send updates to SQL Server, SQLXML sets no limit on the amount of data that can be exchanged and does not do any checking on the size of data in a SQLXML payload before attempting to process it. When you develop your application using SQLXML, it is your responsibility to ensure there is enough memory on the system to process the data. For example, when querying data from the server, you should verify there is enough room in memory on the client to receive it. Likewise, if you are loading data to the server, you need to verify there is enough available memory on the server to process it and enough available disk storage space on the server to store the data.
SQLXML dynamically generates Transact-SQL queries and update commands and sends them to SQL Server for execution. This is the only way in which SQLXML queries and updates the server. Results will be received either as a stream (of XML) or as a rowset.
When receiving query results, SQLXML takes no actions based on the content of the data that it receives. No additional processing is done based on the type or contents of the data. The data is never treated as code with which to execute actions.
When executing XML Templates, SQLXML translates the XPath and DBObject queries contained within the submitted template into Transact-SQL commands that are then executed against SQL Server. These commands only ever affect existing data. Commands generated by SQLXML will never alter the structure of the database. Users must issue explicit commands to alter the database structure. For example, by including them in a sql:query block of a template.
When executing DBObject queries and XPath statements over mapping files, SQLXML will not alter the data in the database in any way.
SQLXML may make formatting changes to the given data based on differences between the XML and SQL Server data models. For example, the format for specifying a time is different. SQLXML will attempt to resolve these differences. As a result, some precision information may be lost.
SQLXML sets no limit on the amount of time it takes to process the data. Processing will continue until an error occurs or processing is complete.
SQLXML does not write to the file system. If users wish to save the data they retrieve from the database, they must do this in their code.
SQLXML allows users to execute any SQL query they like against the database. This functionality should never be exposed to an unsecure or uncontrolled source, as this is essentially opening up the SQL database without provision to any users.
When executing Updategrams, SQLXML translates the updg:sync blocks into DELETE, UPDATE, and INSERT commands against the SQL Server instance. These commands only ever affect existing data. Commands generated by SQLXML will never alter the database. Users must issue explicit commands to alter the database structure. For example, by including them in a sql:query block of a template.
When executing DiffGrams, SQLXML translates the DiffGram into DELETE, UPDATE, and INSERT commands against the SQL Server instance. These commands only ever affect existing data. Commands generated by SQLXML will never alter the database. Users must issue explicit commands to alter the database structure. For example, by including them in a sql:query block of a template.