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 database span>, 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 orcal, db2, but SQL Server is easy to use and widely becoming the reasons we continue to use. How can I make the SQL Server's setup make people feel relieved?
The first step is definitely the latest security patches on SQL Server, and now the patch has been available to SP3. download link:
http://www.microsoft.com/sql/downloads/2000/sp3.asp. If this is not done, then we have not continued it.
The second step is to modify the default 1433 port and hide SQL Server. This can prohibit response to the broadcast of the existing SQL Server clients attempt to enumerate the network. In addition, you also need to shield 1433 ports in TCP / IP screening, hide your SQL Server database span> as much as possible. So, let the attack created the account of SQL Server, or 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: Enterprise Manager -> Your Database SPAN> Group -> Properties -> General -> Network Configuration -> TCP / IP -> Properties, change your default port, and SQL Server hides.
The third step is a very important step, and SQL INJECTION is often generated in web code. As a system administrator or database span> administrator, you can't often see 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 span> role, letting the database span> user 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. The SQL Server will prompt the error message with SELECT IS_SRVROLEMEMBER ('sysadmin'), or select is_member ('db_owner'), or by user = 0 (let character and digital comparison, SQL Server will prompt the error message, from this information " Some statements such as sensitive information are tested. There is still, I don't dare to say more. It is afraid of the fault, and the people in the alliance are flat. At present, if the website's database span> The user uses SA privileges, plus the absolute path of the confirmation of the Web, then the Over of your website is announced. 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-propied permissions, let the attacker can't find the lower mouth. Create an example in SQL Server online help: Create a method of SQL Server Database Span> Role (Enterprise Manager)
Create SQL Server Database Span> Roles
1. Expand the server span> group and expand the server span>.
2. Expand the Database SPAN> folder and expand the database span> you want to create.
3. Right-click "Role" and click New Database Span> 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 Selected Database SPan> 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 permissions, 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 in database span> or database span> The activities involved in the table or stored procedure require another type of authority for statement authority. For example, if a user must be able to create a table in database span>, you should grant CREATE TABLE statement permission to the user. Statement privileges (such as CREATE DATABASE) apply to statements themselves without applicable to specific objects defined in database span>. Statement permissions are:
· Backup Database
· Backup log
· Create Database
· Create Default
· CREATE FUNCTION
CREATE Procedure
· CREATE RULE
CREATE TABLE
CREATE VIEW
Hint
Inspiration Permissions Controls activities that can only be performed by members or database span> object owners that are active by predefined system roles. For example, the SYSADMIN Fixed Server Span> Role member is automatically inherited in the SQL Server installation to perform all permissions.
Database Span> Objects Owners also have 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 database span>.
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 a 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 span>.
DB_DATAWRITER can change all the data in any user table in the database span>.
DB_DenyDataReader cannot select any of the data in any user table in Database SPAN>.
DB_DENYDATAWRITER cannot change any of the data in any user table in the database span>.
Configure the newly created database span> 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, when you create a database span> account, you must not choose the server span> role.
The fourth step is to modify the SQL Server built-in stored procedure. SQL Server estimates are for installation or other aspects, there is a built-in dangerous stored procedure. You can read registry span> information, you can write registry span> information, you can read disk sharing information, etc. Query the analyzer can check the result output. Give you this permission, can't, or 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 shielding method: sp_dropeXtendedProc 'xp_cmdshell', if needed, use sp_addextendedProc 'xp_cmdshell', 'xpsql70.dll' recovery. If you don't know which .dll file is used by XP_cmdshell, you can use sp_helpextendedProc XP_cmdshell 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.
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……
