A few days ago, the attack test of SQL Injection has become more intensified, and many large websites and forums are injectable. These websites are generally used for SQL Server databases, because of this, many people began to suspect SQL Server security. In fact, SQL Server 2000 has passed the US government's C2 safety certification - this is the highest certification level that the industry can have, so use SQL Server is still quite safe. Of course, there is still a gap between orcale, db2, but SQL
Server is ease and wide, or it can be a reason we continue to use. How can I make the SQL Server's setup make people feel relieved?
1.1.
Playing the latest security patches of SQL Server, and now the patch has been available to SP3. Download address: http://www.microsoft.com/sql/downloads/2000/sp3.asp. If this is not done, then we have not continued it.
1.2. Second step
Modify the default 1433 port and hide SQL Server. This can prohibit responding to the broadcast of broadcasts issued on the existing SQL Server client on the network. In addition, you also need to shield the 1433 port in the TCP / IP filter, and hide your SQL Server database as much as possible. This makes it only to create SQL Server's account, or you can't immediately use the query analyzer to remotely log in to the next attack. If you construct a malicious statement from the ASP, PHP, etc., there is a problem that needs to view the return value, which will not be able to fall by the direct query analyzer. So we must first do it even if others are injected, they can't let the attackers will be smooth. Modification method:
Enterprise Manager -> Your Database Group -> Properties -> General -> Network Configuration -> TCP / IP -> Properties, in this, make your default ports, and SQL Server hide.
1.3. Third step
SQL INJECTION is often generated in the web code, and as a system administrator or database administrator, you can't always look at each code. Even often look at the code, we can't guarantee our negligence above. What should I do? We have to start from the database role to let the database user's permissions to the lowest point. The default rights of SQL Server is really a headache. The permissions are very high. If the permissions are small, sysadmin and db_owner are really love and hate. Attacks one but confirmed that there is a SQL INJECTION vulnerability in the website, and there is certain step by step is how much permissions are to test the SQL Server user of the website. Generally, will be by the help
SELECT IS_SRVROLEMEMEMEMBER ('sysadmin ")
or
SELECT IS_MEMBER ('DB_OWNER')
Again or
User = 0
(Compare characters and numbers, SQL Server will prompt the error message, you know some statements such as some sensitive information). Of course there are other methods. At present, if the website's database user uses SA permissions, add the absolute path you confirmed by the Web, then announce your website over. DB_OWNER privilege, if the absolute path is confirmed, 50% of the opportunity can give your machine in the WEB mode Trojan, such as Haiyang, etc. So we confirm this, we have to create self-privileges, let the attacker can't find the place where it is. Quote an example in the SQL Server online help here:
Method for creating a SQL Server database role (Enterprise Manager)
Create a SQL Server database role
1. Expand the server group and expand the server.
2. Expand the Database folder and expand the database you want to create.
3. Right-click "Role" and click New Database Role command.
4. Enter the name of the new role in the Name box.
5. Click Add to add a member to the Standard Role list, and then click one or more users you want to add. (Optional)
Only users in the selected database can be added to the role.
Object privilege
Permission categories called object privileges when processing data or execution procedures:
• SELECT, INSERT, UPDATE, and DELETE statement, they can be applied to the entire table or view.
• SELECT and UPDATE statement permissions, they can be selectively applied to a single column in the table or view.
• SELECT permissions, they can be applied to user-defined functions.
• INSERT and DELETE statement permissions, they affect the trial, so they can only be applied to tables or views without being applied to a single column.
• EXECUTE statement permissions, they can affect stored procedures and functions.
Statement permission
Creating a database or a database (such as a table or stored procedure) requires the other type of permissions to statement rights. For example, if the user must be able to create a table in the database, you should grant the user
CREATE TABLE statement authority. Statement privileges (such as CREATE DATABASE) apply to statements themselves without applicable 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
Hint
Inspiration Permissions Control activities that can only be performed by members or database objects that can only be active by predefined system roles. For example, sysadmin.
Fixed server role members automatically inherit all permissions to operate or view in SQL Server installations.
The database object owner also has suggestive permissions, and all activities can be performed on the objects you have. For example, users who have a table can view, add, or delete data, change table definitions, or control allows other users to operate on the table.
DB_OWNER has all permissions in the database.
DB_ACCESSADMIN can add or delete the user ID.
DB_SecurityAdmin can manage all permissions, object ownership, role, and role membership.
DB_DDLADMIN can issue ALL DDL, but cannot issue GRANT, REVOKE or
Deny statement.
DB_BACKUPOPERATOR can issue DBCC, CheckPoint, and Backup statements.
DB_DataReader can select all the data in any user table in the database.
DB_DATAWRITER can change all the data in any user table in the database.
DB_DenyDataReader cannot select any of the data in any user table in the database.
DB_DENYDATAWRITER cannot change any of the data in any user table in the database.
Configure the newly built database roles here, such as which table, view, stored procedure, etc. need to be used. Then remove DB_OWNER and DB_SECURITYADMIN, DB_BACKUPOPERATOR, do not give attackers Backup Database and Create Table opportunities, one, the attacker has these two permissions, then your website is still in a very dangerous state. Also pay attention to, when you create a database account, you must not choose the server role. 1.4. Fourth step
Modify the SQL Server built-in stored procedure.
SQLServer estimates are for installation or other aspects, there is a built-in dangerous stored procedure. You can read the registry information, you can write to the registry information, you can read disk sharing information, etc. ... You can see it, you may think, there is other code in my website, not like query analyzer. Can output the result directly. Give you this permission, you can't see information. If you want to think about it, you have a big mistake. Tip, if the attacker has the permissions of Create Table, create a temporary table, and then the information INSERT is in the table, but SELECT comes out, then compares the number, let SQL Server error, then the result is all out ... So We have to report to the attitude of killing, not letting.
First list dangerous built-in stored procedures:
XP_cmdshell
XP_REGADDMULTINTISTRING
XP_RegdeleteKey
XP_Regdeletevalue
XP_RegenumKeys
XP_RegenumValues
XP_REGREAD
XP_REGREMOVEMULTINTRING
XP_Regwrite
ActiveX automatic script:
sp_oacreate
sp_oadestroy
Sp_oamethod
SP_OAGETPROPERTY
Sp_oasetproperty
SP_OAGETERRORINFOFO
SP_OASTOP
The above is all in our block, such as the XP_cmdshell mask method:
sp_dropextendedProc 'XP_cmdshell'
Use if needed
sp_addextendedProc 'XP_cmdshell', 'XPSQL70.DLL'
Restore. If you don't know which .dll file is used by XP_cmdshell, you can use it.
sp_helpextendedProc XP_cmdshel
To see which dynamic link library is used by xp_cmdshell. In addition, after the XP_cmdshell is masked, the step we need to do is to change the XPSQL70.dll file to prevent the SA from recovering it.
1.5. Conclusion
We do this here, your SQL Server is basically safe. But information is still the same. After all, SELECT we cannot cancel unless your website is HTML. SQL INJECTION prevention requires us to pay attention to it, this is the law of the rules. We then then analyze the security of SQL Server security in advanced settings. This article If there is any wrong leak, please include it. Thank you……
Also recommend, SQL INJECTION test tool NBSI, this is developed by bamboo bamboo in Nb Alliance, for SQL
The Injection of Injection has a representative effect, and the other is the younger brother's Nbwebshell. These tools can be downloaded from the NB alliance website.
