服务器漏洞详情及解决办法 | 中山大学网络与信息中心

FAQ

IT服务FAQ是中山大学校园网IT服务及应用的知识库，几乎涵盖了我校IT服务中可能遇到的各种问题及解答，如网络接入、NetID和密码，校园网服务，电子邮箱，VPN隧道，软件资源和主要的信息系统等。
您可以通过关键字全文搜索本站相关的问题和答案。如果本站问题有未涵盖的，欢迎联系我们反馈意见和建议。

服务器漏洞详情及解决办法

关于安全漏洞的确认和修补

任何软件或系统很难避免存在安全漏洞，漏洞的恶意利用会给用户带来损失。为此，计算机和互联网产业界形成了一套完善的漏洞披露和修复机制。

为方便业界交流和协作，几乎所有正式披露的漏洞都用一个被称为通用漏洞和披露CVE的统一标识。例如“ OpenSSH复制块远程拒绝服务漏洞（CVE-2006-4924）”，CVE-2006-4924是漏洞的CVE标识，是2006年披露的第4924号漏洞。凭这个标识，管理员或用户可以到cve.scap.org.cn（国内）或cve.mitre.org/cve/（国际）等安全网站获得该漏洞详细信息（包括漏洞名称、紧急程度、漏洞类型、详细介绍、修补方法、参考信息及外部链接等等）。

任何安全工具很难避免误报漏报，因此用户在收到一个漏洞提示以后，除了充分了解该漏洞详细信息以外，还要进一步确认所使用或管理的软硬件是否确实存在该漏洞。如果已购买售后服务的，应该立即通过售后服务电话或电子邮件联系厂家确认漏洞情况。确认存在漏洞后，应该根据修补建议（最好是原厂家的漏洞修补建议）进行漏洞修补，彻底消除安全隐患。

如何修复MS15-034/CVE-2015-1635漏洞？

漏洞详情：

发现时间：2015-04-14
更新时间：2015-04-22
危险等级：高危
CNNVD-ID： CNNVD-201504-257
CVE-ID： CVE-2015-1635
漏洞影响：
对于 Windows 7、Windows Server 2008 R2、Windows 8、Windows Server 2012、Windows 8.1 和 Windows Server 2012 R2 所有受支持版本，攻击者能够通过精心构造HTTP请求，执行任意代码。
漏洞概述：
远程执行代码漏洞存在于 HTTP 协议堆栈 (HTTP.sys) 中，当 HTTP.sys 未正确分析经特殊设计的 HTTP 请求时会导致此漏洞。成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。

安装Windows系统更新补丁KB3042553。

更新补丁链接：

https://technet.microsoft.com/zh-CN/library/security/ms15-034.aspx
https://support.microsoft.com/zh-cn/kb/3042553

如何修复SQL注入漏洞？

解决SQL注入缺陷最终要求基于代码的修复。防护建议包括部署分层安全措施（包括在接受用户输入时使用参数化的查询）、确保应用程序仅使用预期的数据、加固数据库服务器防止不恰当的访问数据。

建议使用以下措施防范SQL注入漏洞：

对于开发
========

使用以下建议编写不受SQL注入攻击影响的web应用。

参数化查询：SQL注入源于攻击者控制查询数据以修改查询逻辑，因此防范SQL注入攻击的最佳方式就是将查询的逻辑与其数据分隔，这可以防止执行从用户输入所注入的命令。这种方式的缺陷是可能对性能产生影响（但影响很小），且必须以这种方式构建站点上的每个查询才能完全有效。只要无意中绕过了一个查询，就足以导致应用受SQL注入的影响。以下代码显示的是可以进行SQL注入的SQL语句示例。

sSql = "SELECT LocationName FROM Locations "; sSql = sSql + " WHERE LocationID = " + Request["LocationID"]; oCmd.CommandText = sSql;

下面的例子使用了参数化的查询，不受SQL注入攻击的影响。

sSql = "SELECT * FROM Locations ";
sSql = sSql + " WHERE LocationID = @LocationID"; oCmd.CommandText = sSql; oCmd.Parameters.Add("@LocationID", Request["LocationID"]);

应用程序没有包含用户输入向服务器发送SQL语句，而是使用-@LocationID-参数替代该输入，这样用户输入就无法成为SQL执行的命令。这种方式可以有效的拒绝攻击者所注入的任何输入，尽管仍会生成错误，但仅为数据类型转换错误，而不是黑客可以利用的错误。

以下代码示例显示从HTTP查询字符串中获得产品ID并使用到SQL查询中。请注意传送给SqlCommand的包含有SELECT的字符串仅仅是个静态字符串，不是从输入中截取的。此外还请注意使用SqlParameter对象传送输入参数的方式，该对象的名称（@pid）匹配SQL查询中所使用的名称。

C#示例：

string connString = WebConfigurationManager.ConnectionStrings["myConn"].ConnectionString;
using (SqlConnection conn = new SqlConnection(connString))
{
conn.Open();
SqlCommand cmd = new SqlCommand("SELECT Count(*) FROM Products WHERE ProdID=@pid", conn);
SqlParameter prm = new SqlParameter("@pid", SqlDbType.VarChar, 50);
prm.Value = Request.QueryString["pid"];
cmd.Parameters.Add(prm);
int recCount = (int)cmd.ExecuteScalar();
}

VB.NET示例：

Dim connString As String = WebConfigurationManager.ConnectionStrings("myConn").ConnectionString

Using conn As New SqlConnection(connString) conn.Open()
Dim cmd As SqlCommand = New SqlCommand("SELECT Count(*) FROM Products WHERE ProdID=@pid", conn)
Dim prm As SqlParameter = New SqlParameter("@pid", SqlDbType.VarChar, 50)
prm.Value = Request.QueryString("pid")
cmd.Parameters.Add(prm)
Dim recCount As Integer = cmd.ExecuteScalar()
End Using

验证输入：可通过正确验证用户输入的类型和格式防范大多数SQL注入攻击，最佳方式是通过白名单，定义方法为对于相关的字段只接受特定的帐号号码或帐号类型，或对于其他仅接受英文字母表的整数或字母。很多开发人员都试图使用黑名单字符或转义的方式验证输入。总体上讲，这种方式通过在恶意数据前添加转义字符来拒绝已知的恶意数据，如单引号，这样之后的项就可以用作文字值。这种方式没有白名单有效，因为不可能事先知道所有形式的恶意数据。

对于安全操作
============

使用以下建议帮助防范对web应用的SQL注入攻击。

限制应用程序权限：限制用户凭据，仅使用应用运行所必需权限的。任何成功的SQL注入攻击都会运行在用户凭据的环境中，尽管限制权限无法完全防范SQL注入攻击，但可以大大增加其难度。

加强系统管理员口令策略：通常攻击者需要管理员帐号的功能才能使用特定的SQL命令，如果系统管理员口令较弱的话就比较容易暴力猜测，增加成功SQL注入攻击的可能性。另一个选项就是根本不使用系统管理员口令，而是为特定目的创建特定的帐号。

一致的错误消息方案：确保在出现数据库错误时向用户提供尽可能少的信息。不要泄漏整个错误消息，要同时在web和应用服务器上处理错误消息。当web服务器遇到处理错误时，应使用通用的web页面响应，或将用户重新定向到标准的位置。绝不要泄漏调试信息或其他可能对攻击者有用的细节。

有关如何在IIS中关闭详细错误消息的说明请见：
http://www.microsoft.com/windows2000/en/server/iis/default.asp?url= /windows2000/en/server/iis/htm/core/iierrcst.htm

使用以下句法在Apache服务器上取缔错误消息:

Syntax: ErrorDocument <3-digit-code>
Example: ErrorDocument 500 /webserver_errors/server_error500.txt

WebSphere之类的应用服务器通常默认安装启用了错误消息或调试设置。有关如何取缔这些错误消息的信息，请参考应用服务器文档。

存储过程：如果不使用的话，请删除master..Xp_cmdshell、xp_startmail、xp_sendmail、
sp_makewebtask之类的SQL存储过程。

SQL注入漏洞根本上还是取决于web应用程序的代码。尽管不是修复，但可以通过向IDS中添加结合了正则表达式的规则作为紧急措施检测SQL注入攻击。尽管这无法修复所有可能的SQL注入漏洞，但便于实施，并且要求攻击者必须要改进其方法才能实现成功的攻击。可如下使用正则表达式。

删除SQL元字符的正则表达式：
/(\%27)|(\')|(\-\-)|(\%23)|(#)/ix

可如下将上述正则表达式添加到Snort规则：
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL Injection- Paranoid";flow:to_server,established;uricontent:".pl";pcre:"/(\%27)|(\')|(\-\-)|(%23)|(#)/i"; classtype:Web-application-attack; sid:9099; rev:5;)

传统SQL注入攻击的正则表达式：
/\w*((\%27)|(\'))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/ix

删除有UNION关键字的SQL注入攻击的正则表达式：
/((\%27)|(\'))union/ix
(\%27)|(\')

可为其他的SQL查询（如select、insert、update、delete、drop等）编写类似的正则表达式。

在MS SQL服务器上检测SQL注入攻击的正则表达式：
/exec(\s|\+)+(s|x)p\w+/ix

如何修复跨站漏洞？

修复跨站脚本漏洞最终要求基于代码的修复。推荐措施包括实施安全编程技术确保正确过滤用户提供的数据，并编码所有用户提供的数据以防以可执行的格式向终端用户发送注入的脚本。

对于开发
========

可通过仔细验证所有输入和正确编码所有输出来防范跨站脚本攻击。可使用标准的ASP.NET验证控件或直接在代码中实施验证，要尽可能使用严格的模版。

输出编码要确保在将内容发送给客户端之前对任何可脚本化的内容都进行了正确的HTML编码。可通过HttpUtility.HtmlEncode函数实现，如以下Label控件示例所示：

Label2.Text = HttpUtility.HtmlEncode(input)

要考虑用户输入通过应用可能用到的所有路径。例如，如果数据是由用户输入的，存储在数据库中，然后再重新显示，就必须要确保在每次检索的时候都能正确编码。如果必须允许自由格式文本输入（如在消息板中），而又希望允许使用一些HTML格式，则可以通过仅明确允许很小的安全标签列表来安全的处理这种情况，如下所示：

C#示例：
StringBuilder sb = new StringBuilder(HttpUtility.HtmlEncode(htmlInputTxt.Text));
sb.Replace("", "");
sb.Replace("", "");
sb.Replace("", "");
sb.Replace("", "");
Response.Write(sb.ToString());

VB.NET示例：
Dim sb As StringBuilder = New StringBuilder( _
HttpUtility.HtmlEncode(input));
sb.Replace("", "");
sb.Replace("", "");
sb.Replace("", "");
sb.Replace("", "");
Response.Write(sb.ToString());

Java示例：
public static String HTMLEncode(String aText){
final StringBuilder result = new StringBuilder();
final StringCharacterIterator iterator = new StringCharacterIterator(aText);
char character = iterator.current();
while (character != CharacterIterator.DONE ){
if (character == '<') {
result.append("<");
}
else if (character == '>') {
result.append(">");
}
else if (character == '&') {
result.append("&");
}
else if (character == '\"') {
result.append(""");
}
else {
//the char is not a special one
//add it to the result as is
result.append(character);
}
character = iterator.next();
}
return result.toString();
}

以下建议可帮助构建能够抵御跨站脚本攻击的web应用。

定义允许的内容。确保web应用对所有输入参数（cookies、头、查询字符串、表单、隐藏字段等）验证严格定义的预期结果。

检查POST和GET请求的响应，确保返回内容是预期的且有效。

通过编码用户提供的数据从用户输入中删除冲突字符、括号、单双引号。这可以防范以可执行的方式向终端用户发送注入的脚本。

在可能的时候将所有客户端提供的数据仅限于字母数字的数据。使用这种过滤方案时，如果用户输入了<script>alert( 'aaa') </script>，就会被减少为scriptalert( 'aaa')script。如果必须使用非字母数字字符，在HTTP响应中使用之前将其编码为HTML实体，这样就无法将其用于修改HTML文档的结构。

使用双重用户认证机制而不是单重认证。

在修改或使用脚本之前确认其来源。

在自己的代码中使用时不要明确的信任任何来自他人的脚本，无论是从web下载还是来自熟人。

大多数服务器端脚本语言都提供了内嵌方式将输入变量的值转换为正确的不可解释HTML。应使用这种方式在将输入显示给客户端之前过滤所有输入。

PHP: string htmlspecialchars (string string [, int quote_style])

ASP / ASP.NET: Server.HTMLEncode (strHTML String)

对于安全操作
============

服务器端编码指的是首先通过编码函数发送所有的动态内容，使用所选择字符集中的代码替换Scripting标签，这可以帮助防范跨站脚本攻击。服务器端编码的缺点是可能耗费资源，对一些web服务器的性能产生负面影响。

如果必须允许站点用户使用HTML标签，如允许用户使用的格式化标签的公告栏，则应限制可使用的标签。创建可接受标签的列表，如粗体字、斜体字或下划线，并仅允许使用这些，拒绝任何其他标签。以下是一些可帮助检测跨站脚本的正则表达式。

简单跨站脚本攻击的正则表达式：
/((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/ix

应如下将上述正则表达式添加到新的Snort规则：

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"NIICross-Site Scripting attempt"; flow:to_server,established;pcre:"/((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i";classtype:Web-application-attack; sid:9000; rev:5;)

跨站脚本攻击的偏执行正则表达式：
/((\%3C)|<)[^\n]+((\%3E)|>)/I

这条特征仅仅查找起始的HTML标签及其对等的16进制，之后的一个或多个字符为非换行符，再之后为结尾标签或其对等的16进制。这可能导致一些误报，具体取决于Web应用和Web服务器的架构。但这种方式可以确保捕获任何攻击，甚至远程类似的跨站脚本攻击。对于公众方面，可以加强教育程序，帮助用户防范可用于帐号劫持和其他形式身份窃取的在线欺诈，如网络钓鱼。