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
What is SQL Injection and why is all this
information not included in the regular FAQ?
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.
|