Kingsley Idehen's Blog Data Space

Are other SQL Servers (Sybase, Oracle, DB2) subject to SQL injection?

Yes, to varying degrees. Here is a site that can get you more details on some of the issues with other SQL Servers. http://www.owasp.org

SQL Injection is simply a term describing the act of passing SQL code into an application that was not intended by the developer.   Since this topic is not specifically restricted to SQL Server it is not included in the normal FAQ.  In fact, much of the problems that allow SQL injection are not the fault of the database server per-se but rather are due to poor input validation and coding at other code layers.  However, due to the serious nature and prevalence of this problem I feel its inclusion in a thorough discussion of SQL Server security is warranted.

What causes SQL Injection?

SQL injection is usually caused by developers who use "string-building" techniques in order to execute SQL code.  For example, in a search page, the developer may use the following code to execute a query (VBScript/ASP sample shown):

Set myRecordset = myConnection.execute("SELECT * FROM myTable WHERE someText ='" & request.form("inputdata") & "'")

The reason this statement is likely to introduce an SQL injection problem is that the developer has made a classic mistake - poor input validation.  We are trusting that user has not entered something malicious - something like the innocent looking single quote (').  Let's consider what would happen if a user entered the following text into the search form:

' exec master..xp_cmdshell 'net user test testpass /ADD' --

Then, when the query string is assembled and sent to SQL Server, the server will process the following code:

SELECT * FROM myTable WHERE someText ='' exec master..xp_cmdshell 'net user test testpass /ADD'--'

Notice, the first single quote entered by the user closed the string and SQL Server eagerly executes the next SQL statements in the batch including a command to add a new user to the local accounts database.  If this application were running as 'sa' and the MSSQLSERVER service is running with sufficient privileges we would now have an account with which to access this machine.  Also note the use of the comment operator (--) to force the SQL Server to ignore the trailing quote placed by the developer's code.

More

Very intresting that these are all Native Interface based exploits.  So the security issue isn't ODBC, JDBC, ADO.NET, or OLE DB specific (although they certainly increase the potential damage that can be unleashed via metadata analysis en route to that huge Cartesian Product ; the mother of all Exploits!). Our Session Rules Book was devised in 1993 with many of these issues in mind, and to this date there are no other ODBC/JDBC/OLE DB products out there that even come close to acknowledging this reality.

Are other SQL Servers (Sybase, Oracle, DB2) subject to SQL injection?

Yes, to varying degrees. Here is a site that can get you more details on some of the issues with other SQL Servers. http://www.owasp.org

SQL Injection is simply a term describing the act of passing SQL code into an application that was not intended by the developer.   Since this topic is not specifically restricted to SQL Server it is not included in the normal FAQ.  In fact, much of the problems that allow SQL injection are not the fault of the database server per-se but rather are due to poor input validation and coding at other code layers.  However, due to the serious nature and prevalence of this problem I feel its inclusion in a thorough discussion of SQL Server security is warranted.

What causes SQL Injection?

SQL injection is usually caused by developers who use "string-building" techniques in order to execute SQL code.  For example, in a search page, the developer may use the following code to execute a query (VBScript/ASP sample shown):

Set myRecordset = myConnection.execute("SELECT * FROM myTable WHERE someText ='" & request.form("inputdata") & "'")

The reason this statement is likely to introduce an SQL injection problem is that the developer has made a classic mistake - poor input validation.  We are trusting that user has not entered something malicious - something like the innocent looking single quote (').  Let's consider what would happen if a user entered the following text into the search form:

' exec master..xp_cmdshell 'net user test testpass /ADD' --

Then, when the query string is assembled and sent to SQL Server, the server will process the following code:

SELECT * FROM myTable WHERE someText ='' exec master..xp_cmdshell 'net user test testpass /ADD'--'

Notice, the first single quote entered by the user closed the string and SQL Server eagerly executes the next SQL statements in the batch including a command to add a new user to the local accounts database.  If this application were running as 'sa' and the MSSQLSERVER service is running with sufficient privileges we would now have an account with which to access this machine.  Also note the use of the comment operator (--) to force the SQL Server to ignore the trailing quote placed by the developer's code.

More

Very intresting that these are all Native Interface based exploits.  So the security issue isn't ODBC, JDBC, ADO.NET, or OLE DB specific (although they certainly increase the potential damage that can be unleashed via metadata analysis en route to that huge Cartesian Product ; the mother of all Exploits!). Our Session Rules Book was devised in 1993 with many of these issues in mind, and to this date there are no other ODBC/JDBC/OLE DB products out there that even come close to acknowledging this reality.