Security from IIS to SQL Server database

From CodeRED to Nimda and so on, a lot of worms to the original need to manually use the vulnerability has become the application of automatic use, do you want to manually operate these IIS vulnerabilities? Let's adjust our focus to see the database used by the server.

General Web sites are based on the database, especially ASP, PHP, JSP, such as the use of the database to dynamically display the site. Many web sites may be more aware of operating system vulnerabilities, but the database and the security of these scripts are always ignored, and not much attention.

Starting with the most common scripting issues, these are old topics, and you can refer to hectic's "simple intrusion of databases and rogue vandalism, as an example of a letter to Heaven," which is very detailed from the SQL scripting question. For the security of the script can also be implemented through filtering, you can refer to what I have previously written. For ASPs, you can use the following filter function:

Function Filter_SQL(strData)
Dim strFilter
Dim blnFlag
Dim i
strFilter="’,;,//,--,@,_,exec,declare" ’需要过滤的字符，可以自己添加，","是分隔符
blnFlag=Flase ’过滤标志，如果产生过滤，那么就是真
Dim arrayFilter
arrayFilter=Split(strFilter,",")
For i=0 To UBound(arrayFilter)
If Instr(strData,arrayFilter(i))>0 Then
blnFlag=True
Exit For
End If
Next
If blnFlag Then
Response.Redirect "wrong.asp"
’当发现有过滤操作时，导向一个预定页面。反正正常访问用不到的连接请求，总不是好事情。
Else
Filter_SQL=strData
End If
End Function

For a MS SQL Server database, security issues are not limited to scripting. God Kill. Microsoft's system is very strong, the entire windows-based application has a strong correlation, for SQL Server, the basic database management and system management can be equated. The password for the default Administrator account SA for SQL Server is empty, which creates a security vulnerability for most NT servers. The sqlrcmd of the Banyan tree will enable you to execute system commands using the database administrator account you obtained.

There are many system stored procedures in SQL Server, some are used internally in the database, and others invoke system commands by executing stored procedures.

System stored procedure: xp_cmdshell executes the given command string as the operating system command line interpreter. It's the specific syntax: xp_cmdshell

{' Command_string '} [, No_output]

xp_cmdshell by default, only members of the sysadmin can execute. However, sysadmin can also grant this execution permission to other users. In earlier versions, users who obtained xp_cmdshell Execute permissions ran commands in the SQL Server service's user account. You can configure SQL Server with configuration options so that users with no SA access to SQL Server can run xp_cmdshell in a sqlexecutivecmdexec Windows NT account. In SQL Server 7.0, this account is called SQLAgentCmdExec. Now for SQL Server2000, you can run the command directly as long as you have an account that can execute the stored procedure.

For NT and WIN2000, when the user is not a member of the sysadmin group, xp_cmdshell simulates the proxy account that uses the SQL Server agent specified by xp_sqlagent_proxy_account. If the proxy account is not available, xp_cmdshell will fail. So even if you have an account that is the db_owner of the master database, you cannot execute the stored procedure.

If we have a database account that can execute xp_cmdshell, such as an SA account with a blank password. Then we can execute a command like this:

EXEC xp_cmdshell ' net user refdom 123456/add '

EXEC xp_cmdshell ' net localgroup Administrators Refdom/add '

The above two calls add a user to the system's Administrators group: Refdom