SQL injection SQL Server security settings

server| Security


The recent SQL injection attack test intensified, many large websites and forums have been injected successively. These sites typically use a SQL Server database, which is why many people are beginning to suspect SQL Server security. In fact, SQL Server 2000 has passed the U.S. government's C2 level security certification-This is the industry can have the highest level of authentication, so the use of SQL Server is quite safe. Of course, there is still a gap between Orcale, DB2 and so on, but SQL

The ease of use and breadth of the server can still be a reason for us to continue using it. So how to make SQL Server settings for people to use the rest assured?
1.1. The first step
With SQL Server's latest security patch, the patch is now SP3. Download Address: http://www.microsoft.com/sql/downloads/2000/sp3.asp. If this step is not done well, then we do not have to go on the necessary.
1.2. Step Two
Modify the default 1433 port and hide SQL Server. This prevents responses to broadcasts that attempt to enumerate existing SQL Server clients on the network. In addition, you will need to screen out 1433 ports in TCP/IP filtering to hide your SQL Server database as much as possible. This will allow the attack to create a SQL Server account, and can not immediately use the Query Analyzer remote login for the next attack. If you are constructing a malicious statement from a page such as a asp,php, you also need to look at the return value problem, which is better than the Direct Query Analyzer. So the first thing we have to do is to get someone injected and not let the attacker do the next thing. To modify the method:

Enterprise Manager--> Your database group--> properties--> regular--> network configuration--> TCP/IP--> properties, where your default port is modified and SQL Server is hidden.
1.3. Step Three
SQL injection are often generated in web code, and as a system administrator or database administrator, you can't always look at every piece of code. Even if you look at the code often, there is no guarantee of our negligence. Then what? We are going to start with the database role, so that the database user's permissions to the lowest point. The default permissions for SQL Server make people really very headache, the permissions are very high, small permissions and nothing can do, sysadmin and db_owner really let people love and hate. An attacker who confirmed the existence of a SQL injection vulnerability in a Web site must have a step in the way of testing the permissions of the SQL Server user of the site. It's usually the use of

SELECT is_srvrolemember (' sysadmin ')

Or

SELECT is_member (' db_owner ')

Then or

User =0

(When you compare characters to numbers, SQL Server prompts you for the error message, from which you can know some sensitive information) and so on to test the statements. There are other ways, of course. At the moment, if the site's database users are using SA privileges, plus confirming the absolute path the Web is in, then it announces your site over. DB_Owner permissions are the same, if the absolute path is confirmed, then there is a 50% chance to give your machine on the web-style trojan, such as Haiyang. So here we are confirming that we have to create our own permissions so that attackers cannot find a place to start. Here, refer to an example in SQL Server online Help:

Ways to create SQL Server database roles (Enterprise Manager)

To create a SQL Server database role

1. Expand the server group, and then expand the server.

2. Expand the Databases folder, and then expand the database in which you want to create a role.

3. Right-click Roles, then the new database Role command.

4. In the Name box, enter a name for the new role.

5. Click Add to add members to the standard roles list, and then click one or more users that you want to add. (optional)

Only users in the selected database can be added to the role.



Object permissions

A permission category called object permissions is required to process data or execute procedures:

Select, INSERT, UPDATE, and DELETE statement permissions, which can be applied to the entire table or view.

Select and UPDATE statement permissions, which can be applied selectively to individual columns in a table or view.

SELECT permissions, which can be applied to user-defined functions.

Insert and DELETE statement permissions that affect the entire row, so they can only be applied to a table or view, not to a single column.

EXECUTE statement permissions, which can affect stored procedures and functions.



Statement permissions

The activity involved in creating an item in a database or database, such as a table or stored procedure, requires another class of permissions called statement permissions. For example, if a user must be able to create a table in the database, the user should be granted

CREATE TABLE statement permission. Statement permissions, such as CREATE database, apply to the statement itself, not to specific objects defined in the database.

Statement permissions are:

Backup DATABASE

Backup LOG

Create DATABASE

Create DEFAULT

Create FUNCTION

Create PROCEDURE

Create Rule

Create TABLE

Create VIEW



Implied permission

Implied permissions control activities that can be performed only by members of a predefined system role or by the owner of a database object. For example, sysadmin.

Fixed server role members automatically inherit all permissions that are manipulated or viewed in a SQL Server installation.

Database object owners also have implied permissions to perform all activities on the objects they own. For example, a user who owns a table can view, add, or delete data, change the table definition, or control permissions that allow other users to manipulate the table.

DB_Owner has full permissions in the database.

Db_accessadmin can add or remove user IDs.

Db_securityadmin can manage all permissions, object ownership, roles, and role memberships.

Db_ddladmin can emit all DDL, but cannot emit GRANT, REVOKE, or

DENY statement.

Db_backupoperator can emit DBCC, CHECKPOINT, and BACKUP statements.

Db_datareader can select all the data in any user table in the database.

Db_datawriter can change all data in any user table in the database.

Db_denydatareader cannot select any data in any of the user tables in the database.

Db_denydatawriter cannot change any data in any of the user tables in the database.



Here, configure the permissions for the newly created database role, such as which table, view, stored procedure, etc. you want to use. The db_owner and db_securityadmin and Db_backupoperator are then canceled, giving the attacker the opportunity to backup the database and create table, but the attacker has these two privileges, Then your site is still in a very dangerous state. Also note that when creating a database account, you must not choose the server role.
1.4. Step Fourth
Modify SQL Server built-in stored procedures.

SQL Server is estimated to be installed, or otherwise, with a number of dangerous stored procedures built into it. Can read the registry information, can write registry information, read disk sharing information and so on ... You see here, in the mind may be thinking, my site has other code, and not like the Query Analyzer can directly output the results. Give you this permission, also can't how, still can't see the information. It would be a big mistake if you think so. Hint, if the attacker has permission to create TABLE, then creates a temporary table, and then inserts the information into the table, then select it, and then compare with the number, let SQL Server error, then the result is all out ... So we have to report a better way to kill, do not miss the attitude of repair.

First, list the dangerous built-in stored procedures:

xp_cmdshell

Xp_regaddmultistring

Xp_regdeletekey

Xp_regdeletevalue

Xp_regenumkeys

Xp_regenumvalues

Xp_regread

Xp_regremovemultistring

Xp_regwrite



ActiveX Automatic scripting:



sp_OACreate

sp_OADestroy

sp_OAMethod

sp_OAGetProperty

sp_OASetProperty

sp_OAGetErrorInfo

sp_OAStop



All of the above are in our ban, such as xp_cmdshell shielding method:

Sp_dropextendedproc ' xp_cmdshell '

If necessary, then use

Sp_addextendedproc ' xp_cmdshell ', ' Xpsql70.dll '

for recovery. If you don't know which. dll file xp_cmdshell is using, you can use the

Sp_helpextendedproc Xp_cmdshel

To see which dynamic join Library the xp_cmdshell is using. In addition, after shielding the xp_cmdshell, the next step is to rename the Xpsql70.dll file to prevent it from being recovered by an attacker who obtains the SA.
1.5. Conclusion
We do this, and your SQL Server is basically secure. But the information can still be the same leak. After all, select we can't cancel unless your site is using HTML. The prevention of SQL injection also requires the attention of our programmers, this is the root of the solution. We then proceed to the next analysis of SQL Server security in the Advanced Setup article. If there are any mistakes in this article, please forgive me. Thank you......



Also recommended, SQL Injection Test tool NBSI, which is developed by NB Alliance of Small and Medium bamboo comrades, on the SQL

Injection injection has a representative role, the other one is the Nbwebshell of the younger brother. These tools are available for download at the NB affiliate website.