网站漏洞分类、影响和解决方案.doc

典型网站漏洞分类、影响及解决方案（V1.0）中国移动通信集团安徽有限公司二一年九月目录一、典型网站漏洞分类3二、典型网站漏洞影响及解决方案31、SQL注入漏洞32、跨站漏洞93、XPATH注入漏洞144、默认测试用例文件155、管理后台登陆入口166、应用程序错误引起的信息泄露167、备份文件造成的源代码泄漏178、存在电子邮件地址189、无效链接1810、Web应用默认目录19一、 典型网站漏洞分类根据风险等级，网站漏洞通常可分为高风险、中风险和低风险三种。其中高风险漏洞是必须封堵的。中、低风险漏洞中有一部分是必须封堵的。还有一部分中、低风险漏洞，由于其封堵的代价可能远高于不封堵所造成的损失，因而可以进行选择性封堵。典型网站漏洞的分类及相应的封堵要求如下表所示：风险等级高风险中、低风险中、低风险漏洞名称1、 SQL注入漏洞2、 跨站漏洞3、 XPATH注入漏洞1、 默认测试用例文件2、 管理后台登陆入口3、 应用程序错误引起的信息泄露4、 备份文件造成的源代码泄漏1、 存在电子邮件地址2、 无效链接3、 Web应用默认目录封堵要求必须封堵选择封堵二、 典型网站漏洞影响及解决方案1、 SQL注入漏洞漏洞影响：本漏洞属于Web应用安全中的常见漏洞，属于OWASP TOP 10 （2007）中的注入类漏洞。很多WEB应用中都存在SQL注入漏洞。SQL注入是一种攻击者利用代码缺陷进行攻击的方式，可在任何能够影响数据库查询的应用程序参数中利用。例如url本身的参数、post数据或cookie值。正常的SQL注入攻击很大程度上取决于攻击者使用从错误消息所获得信息。但是，即使没有显示错误消息应用程序仍可能受SQL注入的影响。总体上讲，SQL注入是对web应用而不是对web服务器或操作系统本身的攻击。正如其名称所示，SQL注入是对查询添加非预期SQL命令从而以数据库管理员或开发人员非预期的方式操控数据库的行为。如果成功的话，就可以获得、修改、注入或删除有漏洞web应用所使用数据库服务器的数据。在某些环境下，可利用SQL注入完全控制系统。解决方案：防护建议包括部署分层安全措施（包括在接受用户输入时使用参数化的查询）、确保应用程序仅使用预期的数据、加固数据库服务器防止不恰当的访问数据。建议使用以下措施防范SQL注入漏洞：对于开发=使用以下建议编写不受SQL注入攻击影响的web应用。 参数化查询：SQL注入源于攻击者控制查询数据以修改查询逻辑，因此防范SQL注入攻击的最佳方式就是将查询的逻辑与其数据分隔，这可以防止执行从用户输入所注入的命令。这种方式的缺陷是可能对性能产生影响（但影响很小），且必须以这种方式构建站点上的每个查询才能完全有效。只要无意中绕过了一个查询，就足以导致应用受SQL注入的影响。以下代码显示的是可以进行SQL注入的SQL语句示例。 sSql = SELECT LocationName FROM Locations ; sSql = sSql + WHERE LocationID = + RequestLocationID; oCmd.CommandText = sSql;下面的例子使用了参数化的查询，不受SQL注入攻击的影响。 sSql = SELECT * FROM Locations ;sSql = sSql + WHERE LocationID = LocationID; oCmd.CommandText = sSql; oCmd.Parameters.Add(LocationID, RequestLocationID); 、555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555应用程序没有包含用户输入向服务器发送SQL语句，而是使用-LocationID-参数替代该输入，这样用户输入就无法成为SQL执行的命令。这种方式可以有效的拒绝攻击者所注入的任何输入，尽管仍会生成错误，但仅为数据类型转换错误，而不是黑客可以利用的错误。 以下代码示例显示从HTTP查询字符串中获得产品ID并使用到SQL查询中。请注意传送给SqlCommand的包含有SELECT的字符串仅仅是个静态字符串，不是从输入中截取的。此外还请注意使用SqlParameter对象传送输入参数的方式，该对象的名称（pid）匹配SQL查询中所使用的名称。C#示例：string connString = WebConfigurationManager.ConnectionStringsmyConn.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.QueryStringpid; cmd.Parameters.Add(prm); int recCount = (int)cmd.ExecuteScalar(); VB.NET示例： Dim connString As String = WebConfigurationManager.ConnectionStrings(myConn).ConnectionStringUsing 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中关闭详细错误消息的说明请见：/windows2000/en/server/iis/default.asp?url= /windows2000/en/server/iis/htm/core/iierrcst.htm使用以下句法在Apache服务器上取缔错误消息:Syntax: ErrorDocument Example: ErrorDocument 500 /webserver_errors/server_error500.txtWebSphere之类的应用服务器通常默认安装启用了错误消息或调试设置。有关如何取缔这些错误消息的信息，请参考应用服务器文档。 存储过程：如果不使用的话，请删除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)pw+/ix对于质量保证=解决SQL注入缺陷最终要求基于代码的修复，“对于开发”和“对于安全操作”部分所述的步骤提供了修复这些漏洞所必要的信息。以下步骤概述了如何对应用程序手动测试SQL注入。 如何对应用程序手动测试SQL注入：1. 在浏览器中打开希望测试SQL注入漏洞的web应用。 2. 将鼠标光标悬停在Web站点的链接上并注意底部的状态栏，可以看到链接所指向的URL。找到其中带有参数的URL，如/articleid.asp?id=42 注释：如果没有在状态栏中看到任何URL，请点击链接然后查看地址栏，直到找到带有参数的URL。 3. 找到带有参数的URL后，点击链接进入网页，在地址栏中可以看到状态栏中的URL。 4. 有两种测试SQL注入脚本的方法，请使用全部两种方式依次测试每个参数值。 方法1. 在地址栏中点击光标，高亮显示参数值，如高亮显示name=value中的value并用单引号（）替换，这时应类似于name=。方法2. 在地址栏中点击光标，在value中间输入单引号（），这时应类似于name=value。 5. 点击GO键将请求发送到Web服务器。6. 分析Web服务器响应中的错误消息，大多数数据库错误消息都类似于以下示例： Example error 1:Microsoft OLE DB Provider for SQL Server error 80040e14 Unclosed quotation mark before the character string 51 ORDER BY some_name. /some_directory/some_file.asp, line 5 Example error 2: ODBC Error Code = S1000 (General error)OracleODBCOraORA-00933: SQL command not properly ended Example error 3: Error: 1353 SQLSTATE: HY000 (ER_VIEW_WRONG_LIST)Message: Views SELECT and views field list have different column counts 7. 有时错误消息并不明显，隐藏在页面源码中。如果要查看这些消息，必须查看页面的HTML源码并搜索错误。如果要在Internet Explorer中实现这个操作，点击“查看”菜单，然后选择“源码”选项，这可以打开记事本显示页面的HTML源码。在记事本中，打开“编辑”菜单并选择“查找”。这时会出现一个对话框询问“查找内容”。输入Microsoft OLE DB或ODBC然后点击“查找下一个”。 8. 如果6或7步成功，则Web站点存在SQL注入漏洞。2、 跨站漏洞漏洞影响：跨站脚本攻击（也称为XSS）指利用网站漏洞从用户那里恶意盗取信息。用户在浏览网站、使用即时通讯软件、甚至在阅读电子邮件时，通常会点击其中的链接。攻击者通过在链接中插入恶意代码，就能够盗取用户信息或在终端用户系统上执行恶意代码。成功的跨站脚本攻击所带来的主要问题包括：帐号劫持 - 攻击者可以在会话cookie过期之前劫持用户的会话，并以访问ULR用户的权限执行操作，如发布数据库查询并查看结果。 恶意脚本执行 - 用户可能在不知情的情况下执行攻击者注入到动态生成页面中的JavaScript、VBScript、ActiveX、HTML甚至Flash内容。 蠕虫传播 - 通过Ajax应用，跨站脚本可以以类似于病毒的方式传播。跨站脚本负载可以自动将其自身注入到页面中，并通过更多的跨站脚本轻易的重新注入同一主机，而所有这些都无需手动刷新页面。因此，跨站脚本可以使用复杂的HTTP方式发送多个请求，并以用户不可视的方式自我传播。信息窃取 - 攻击者可以通过重新定向和伪造站点将用户连接到攻击者所选择的恶意服务器并获得用户所输入的任何信息。拒绝服务 - 通常攻击者通过在包含有跨站脚本漏洞的站点上使用畸形的显示请求，就可以导致主机站点反复的自我查询，出现拒绝服务的情况。 浏览器重新定向 - 在某些使用帧的站点上，用户可能在实际上已经被重新定向到恶意站点的情况下误导为仍处在原始站点上，因为浏览权地址栏中的URL仍保持不变。这是由于没有重新定向整个页面，而只是执行JavaScript的帧。 控制用户设置 - 攻击者可以恶意更改用户设置。本漏洞属于Web应用安全常见漏洞。解决方案：推荐措施包括实施安全编程技术确保正确过滤用户提供的数据，并编码所有用户提供的数据以防以可执行的格式向终端用户发送注入的脚本。对于开发=可通过仔细验证所有输入和正确编码所有输出来防范跨站脚本攻击。可使用标准的ASP.NET验证控件或直接在代码中实施验证，要尽可能使用严格的模版。输出编码要确保在将内容发送给客户端之前对任何可脚本化的内容都进行了正确的HTML编码。可通过HttpUtility.HtmlEncode函数实现，如以下Label控件示例所示：Label2.Text = HttpUtility.HtmlEncode(input)考虑用户输入通过应用可能用到的所有路径。例如，如果数据是由用户输入的，存储在数据库中，然后再重新显示，就必须要确保在每次检索的时候都能正确编码。如果必须允许自由格式文本输入（如在消息板中），而又希望允许使用一些HTML格式，则可以通过仅明确允许很小的安全标签列表来安全的处理这种情况，如下所示：C#示例：StringBuilder sb = new StringBuilder(HttpUtility.HtmlEncode(input); 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 aTagFragment) final StringBuffer result = new StringBuffer(); final StringCharacterIterator iterator = new StringCharacterIterator(aTagFragment);char character = iterator.current();while (character != StringCharacterIterator.DONE ) if (character = = ) result.append() result.append(); else 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请求的响应，确保返回内容是预期的且有效。通过编码用户提供的数据从用户输入中删除冲突字符、括号、单双引号。这可以防范以可执行的方式向终端用户发送注入的脚本。在可能的时候将所有客户端提供的数据仅限于字母数字的数据。使用这种过滤方案时，如果用户输入了alertdocumentcookie( aaa) ，就会被减少为scriptalertdocumentcookiescript。如果必须使用非字母数字字符，在HTTP响应中使用之前将其编码为HTML实体，这样就无法将其用于修改HTML文档的结构。使用双重用户认证机制而不是单重认证。在修改或使用脚本之前确认其来源。在自己的代码中使用时不要明确的信任任何来自他人的脚本，无论是从web下载还是来自熟人。大多数服务器端脚本语言都提供了内嵌方式将输入变量的值转换为正确的不可解释HTML。应使用这种方式在将输入显示给客户端之前过滤所有输入。 PHP: string htmlspecialchars (string string , int quote_style)ASP / ASP.NET: Server.HTMLEncode (strHTML String)对于安全操作=服务器端编码指的是首先通过编码函数发送所有的动态内容，使用所选择字符集中的代码替换Scripting标签，这可以帮助防范跨站脚本攻击。服务器端编码的缺点是可能耗费资源，对一些web服务器的性能产生负面影响。 如果必须允许站点用户使用HTML标签，如允许用户使用的格式化标签的公告栏，则应限制可使用的标签。创建可接受标签的列表，如粗体字、斜体字或下划线，并仅允许使用这些，拒绝任何其他标签。以下是一些可帮助检测跨站脚本的正则表达式。简单跨站脚本攻击的正则表达式： /(%3C)|)/ix应如下将上述正则表达式添加到新的Snort规则：alert tcp $EXTERNAL_NET any - $HTTP_SERVERS $HTTP_PORTS (msg:NIICross-Site Scripting attempt; flow:to_server,established;pcre:/(%3C)|)/i;classtype:Web-application-attack; sid:9000; rev:5;)跨站脚本攻击的偏执行正则表达式：/(%3C)|)/I这条特征仅仅查找起始的HTML标签及其对等的16进制，之后的一个或多个字符为非换行符，再之后为结尾标签或其对等的16进制。这可能导致一些误报，具体取决于Web应用和Web服务器的架构。但这种方式可以确保捕获任何攻击，甚至远程类似的跨站脚本攻击。对于公众方面，可以加强教育程序，帮助用户防范可用于帐号劫持和其他形式身份窃取的在线欺诈，如网络钓鱼。 对于质量保证=修复跨站脚本漏洞最终要求基于代码的修复。“对于开发”和“对于安全操作”部分所述步骤可为开发人员提供修复这些问题所需的信息。以下步骤概括了如何对应用程序手动测试跨站脚本。 步骤1. 在浏览器中打开任意Web站点，查找可接受用户输入的位置，如搜索表单或某些登录页面。在搜索框中输入test并发送给Web服务器。步骤2. 寻找返回类似于Your search for test did not find any items或Invalid login test页面的WEB服务器。如果结果页面中出现了test，请继续。 步骤3. 如果要测试跨站脚本，在之前使用的同一搜索或登录框中输入alert(hello)字符串并发送给Web服务器。步骤4. 如果服务器所响应的弹出框显示hello，则站点受跨站脚本影响。步骤5. 即使步骤4失败，站点没有返回这条信息，仍可能存在风险。在浏览器中点击“查看源码”选项，查看Web页面的实际HTML代码。现在查找发送给服务器的字符串，如果在源码中看到整个alert(hello)文本，则Web服务器受跨站脚本的影响3、 XPATH注入漏洞漏洞影响：XPath注入攻击利用两种技术，即XPath扫描和 XPath查询布尔化。通过该攻击，攻击者可以控制用来进行XPath查询的XML数据库。这种攻击可以有效地对付使用XPath查询（和XML数据库） 来执行身份验证、查找或者其它操作。XPath注入攻击同SQL注入攻击类似，但和SQL注入攻击相比较，XPath在以下方面具有优势。（1） 广泛性。XPath注入攻击利用的是XPath语法，由于XPath是一种标准语言，因此只要是利用XPath语法的Web 应用程序如果未对输入的XPath查询做严格的处理都会存在XPath注入漏洞，所以可能在所有的XPath实现中都包含有该弱点，这和SQL注入攻击有 很大区别。在SQL注入攻击过程中根据数据库支持的SQL语言不同，注入攻击的实现可能不同。（2） 危害性大。XPath语言几乎可以引用XML文档的所有部分，而这样的引用一般没有访问控制限制。但在SQL注入攻击中，一个“用户”的权限可能被限制到 某一特定的表、列或者查询，而XPath注入攻击可以保证得到完整的XML文档，即完整的数据库。只要Web服务应用具有基本的安全漏洞，即可构造针对 XPath应用的自动攻击。解决方案：目前专门的XPath攻击防御技术还不是太多，但是SQL注入攻击防御技术可以加以改进，应用到XPath注入攻击防御。具体技术总结如下：（1）数据提交到服务器上端，在服务端正式处理这批数据之前，对提交数据的合法性进行验证。（2）检查提交的数据是否包含特殊字符，对特殊字符进行编码转换或替换、删除敏感字符或字符串。（3）对于系统出现的错误信息，以IE错误编码信息替换，屏蔽系统本身的出错信息。（4）参数化XPath查询，将需要构建的XPath查询表达式，以变量的形式表示，变量不是可以执行的脚本。如下代码可以通过创建保存查询的外部文件使查询参数化：declare variable $loginID as xs：string external；declare variable $password as xs：string external；/users/userloginID=$loginID and password= $password（5）通过MD5、SSL等加密算法，对于数据敏感信息和在数据传输过程中加密，即使某些非法用户通过非法手法获取数据包，看到的也是加密后的信息。4、 默认测试用例文件漏洞影响：发现目标网站存在测试应用程序。这种类型的文件通常是由开发人员或者网站管理员用于测试web应用程序的某个功能时留在服务器上的。这些文件可能包含有敏感信息，包括已验证的会话ID，用户名/密码等。如果攻击者获取到这些敏感信息，攻击者可以进一步获取其他敏感数据。解决方案：删除此类文件或限制此类文件的访问权限。5、 管理后台登陆入口漏洞影响：检查到目标应用的后台登陆入口。管理员应用程序一般用于网站的后台管理，具有全部的权限。这些应用程序可能包含一些敏感信息或具有较低的安全保护，攻击者可以通过该文件获取敏感信息或者进入网站后台，进行恶意操作。解决方案：加强访问此类文件的认证和使用安全。如果不需要此类文件，请删除。修改为不可预测的文件名。6、 应用程序错误引起的信息泄露漏洞影响：如果攻击者通过伪造包含非应用程序预期