网站漏洞检测归类和解决方案模板.doc

网站漏洞检测归类和解决方案 本文由s8h4a2n6贡献 doc文档可能在WAP端浏览体验不佳。建议您优先选择TXT, 或下载源文件到本机查看。 一、 典型网站漏洞分类 根据风险等级, 网站漏洞一般可分为高风险、 中风险和低风险三种。其中高 风险漏洞是必须封堵的。中、 低风险漏洞中有一部分是必须封堵的。还有一部分 中、 低风险漏洞, 由于其封堵的代价可能远高于不封堵所造成的损失, 因而能够 进行选择性封堵。能够采取工具亿思平台进行其网站的漏洞扫描, 具体地址为: 典型网站漏洞的分类及相应的封堵要求如下表所示: 风险等级 高风险 1、 SQL 注入漏洞 2、 跨站漏洞 中、 低风险 1、 默认测试用例文件 2、 管理后台登陆入口 中、 低风险 1、 存在电子邮件地 址 漏洞名称 3、 XPATH 注入漏 3、 应用程序错误引起的 2、 无效链接 洞 信息泄露 4、 备份文件造成的源代 码泄漏 3、 Web 应用默认目 录 封堵要求 必须封堵 选择封堵 1 二、 典型网站漏洞影响及解决方案 1、 SQL 注入漏洞 漏洞影响: 本漏洞属于 Web 应用安全中的常见漏洞, 属于 OWASP TOP 10 ( ) 中的注入类漏洞。 很多 WEB 应用中都存在 SQL 注入漏洞。SQL 注入是一种攻击者利用代码 缺陷进行攻击的方式, 可在任何能够影响数据库查询的应用程序参数中利用。例 如 url 本身的参数、 post 数据或 cookie 值。 正常的 SQL 注入攻击很大程度上取决于攻击者使用从错误消息所获得信 息。可是, 即使没有显示错误消息应用程序仍可能受 SQL 注入的影响。 总体上讲, SQL 注入是对 web 应用而不是对 web 服务器或操作系统本身 的攻击。正如其名称所示, SQL 注入是对查询添加非预期 SQL 命令从而以数据 库管理员或开发人员非预期的方式操控数据库的行为。如果成功的话, 就能够获 得、 修改、 注入或删除有漏洞 web 应用所使用数据库服务器的数据。在某些环 境下, 可利用 SQL 注入完全控制系统。 解决方案: 防护建议包括部署分层安全措施( 包括在接受用户输入时使用参数化的查 询) 、 确保应用程序仅使用预期的数据、 加固数据库服务器防止不恰当的访问数 据。 建议使用以下措施防范 SQL 注入漏洞: 2 对于开发 = 使用以下建议编写不受 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); 应 用 程 序 没 有 包 含 用 户 输 入 向 服 务 器 发 送 SQL 语 句 , 而 是 使 用 -LocationID-参数替代该输入, 这样用户输入就无法成为 SQL 执行的命令。 3 这种方式能够有效的拒绝攻击者所注入的任何输入, 尽管仍会生成错误, 但仅为 数据类型转换错误, 而不是黑客能够利用的错误。 以下代码示例显示从 HTTP 查询字符串中获得产品 ID 并使用到 SQL 查询 中。 请注意传送给 SqlCommand 的包含有 SELECT 的字符串仅仅是个静态字符 串, 不是从输入中截取的。另外还请注意使用 SqlParameter 对象传送输入参数 的方式, 该对象的名称( pid) 匹配 SQL 查询中所使用的名称。 C#示例: string connString = WebConfigurationManager.ConnectionStringsmyConn.ConnectionStr ing; 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(); 4 VB.NET 示例: Dim connString As String = WebConfigurationManager.ConnectionStrings(myConn).ConnectionStr ing 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 注入攻击, 最佳方式是经过白名单, 定义方法为对于相关的字段只接受特定的帐号号码或帐 号类型, 或对于其它仅接受英文字母表的整数或字母。很多开发人员都试图使用 黑名单字符或转义的方式验证输入。总体上讲, 这种方式经过在恶意数据前添加 转义字符来拒绝已知的恶意数据, 如单引号, 这样之后的项就能够用作文字值。 5 这种方式没有白名单有效, 因为不可能事先知道所有形式的恶意数据。 对于安全操作 = 使用以下建议帮助防范对 web 应用的 SQL 注入攻击。 限制应用程序权限: 限制用户凭据, 仅使用应用运行所必须权限的。任何成功的 SQL 注入攻击都会运行在用户凭据的环境中, 尽管限制权限无法完全防范 SQL 注入攻击, 但能够大大增加其难度。 强系统管理员口令策略: 一般攻击者需要管理员帐号的功能才能使用特定的 SQL 命令, 如果系统管理员口令较弱的话就比较容易暴力猜测, 增加成功 SQL 注入 攻击的可能性。另一个选项就是根本不使用系统管理员口令, 而是为特定目的创 建特定的帐号。 一致的错误消息方案: 确保在出现数据库错误时向用户提供尽可能少的信息。不 要泄漏整个错误消息, 要同时在 web 和应用服务器上处理错误消息。当 web 服 务器遇到处理错误时, 应使用通用的 web 页面响应, 或将用户重新定向到标准 的位置。绝不要泄漏调试信息或其它可能对攻击者有用的细节。 有关如何在 IIS 中关闭详细错误消息的说明请见: 6 使用以下句法在 Apache 服务器上取缔错误消息: Syntax: ErrorDocument 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 7 可如下将上述正则表示式添加到 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 对于质量保证 = 8 解决 SQL 注入缺陷最终要求基于代码的修复, ”对于开发”和”对于安全操 作”部分所述的步骤提供了修复这些漏洞所必要的信息。以下步骤概述了如何对 应用程序手动测试 SQL 注入。 如何对应用程序手动测试 SQL 注入: 1. 在浏览器中打开希望测试 SQL 注入漏洞的 web 应用。 2. 将鼠标光标悬停在 Web 站点的链接上并注意底部的状态栏, 能够看到链接所 指 向 的 URL 。 找 到 其 中 带 有 参 数 的 URL , 如 注释: 如果没有在状态栏中看到任何 URL, 请点击链接然后查看地址栏, 直到 找到带有参数的 URL。 3. 找到带有参数的 URL 后, 点击链接进入网页, 在地址栏中能够看到状态栏中 的 URL。 4. 有两种测试 SQL 注入脚本的方法, 请使用全部两种方式依次测试每个参数值。 方法 1. 在地址栏中点击光标, 高亮显示参数值, 如高亮显示 name=value 中的 value 并 9 用单引号( ) 替换, 这时应类似于 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 10 7. 有时错误消息并不明显, 隐藏在页面源码中。如果要查看这些消息, 必须查 看页面的 HTML 源码并搜索错误。 如果要在 Internet Explorer 中实现这个操作, 点击 ”查看” 菜单, 然后选择 ”源码” 选项, 这能够打开记事本显示页面的 HTML 源码。在记事本中, 打开”编辑”菜单并选择”查找” 。这时会出现一个对话框 询问”查找内容” 。输入 Microsoft OLE DB 或ODBC然后点击”查找下一个” 。 8. 如果 6 或 7 步成功, 则 Web 站点存在 SQL 注入漏洞。 2、 跨站漏洞 漏洞影响: 跨站脚本攻击( 也称为 XSS) 指利用网站漏洞从用户那里恶意盗取信息。用 户在浏览网站、 使用即时通讯软件、 甚至在阅读电子邮件时, 一般会点击其中的 链接。攻击者经过在链接中插入恶意代码, 就能够盗取用户信息或在终端用户系 统上执行恶意代码。 成功的跨站脚本攻击所带来的主要问题包括: 帐号劫持 - 攻击者能够在会话 cookie 过期之前劫持用户的会话, 并以访问 ULR 用户的权限执行操作, 如发布数据库查询并查看结果。 恶意脚本执行 - 用户可能在不知情的情况下执行攻击者注入到动态生成页 面中的 JavaScript、 VBScript、 ActiveX、 HTML 甚至 Flash 内容。 蠕虫传播 - 经过 Ajax 应用, 跨站脚本能够以类似于病毒的方式传播。跨站 11 脚本负载能够自动将其自身注入到页面中, 并经过更多的跨站脚本轻易的重新注 入同一主机, 而所有这些都无需手动刷新页面。因此, 跨站脚本能够使用复杂的 HTTP 方式发送多个请求, 并以用户不可视的方式自我传播。 信息窃取 - 攻击者能够经过重新定向和伪造站点将用户连接到攻击者所选择的 恶意服务器并获得用户所输入的任何信息。 拒绝服务 - 一般攻击者经过在包含有跨站脚本漏洞的站点上使用畸形的显示请 求, 就能够导致主机站点重复的自我查询, 出现拒绝服务的情况。 浏览器重新定向 - 在某些使用帧的站点上, 用户可能在实际上已经被重新定向 到恶意站点的情况下误导为仍处在原始站点上, 因为浏览权地址栏中的 URL 仍 保持不变。这是由于没有重新定向整个页面, 而只是执行 JavaScript 的帧。 控制用户设置 - 攻击者能够恶意更改用户设置。 本漏洞属于 Web 应用安全常见漏洞。 解决方案: 推荐措施包括实施安全编程技术确保正确过滤用户提供的数据, 并编码所有 用户提供的数据以防以可执行的格式向终端用户发送注入的脚本。 对于开发 12 = 可经过仔细验证所有输入和正确编码所有输出来防范跨站脚本攻击。 可使用 标准的 ASP.NET 验证控件或直接在代码中实施验证, 要尽可能使用严格的模版。 输出编码要确保在将内容发送给客户端之前对任何可脚本化的内容都进行了正 确的 HTML 编码。可经过 HttpUtility.HtmlEncode 函数实现, 如以下 Label 控件示例所示: Label2.Text = HttpUtility.HtmlEncode(input) 考虑用户输入经过应用可能用到的所有路径。例如, 如果数据是由用户输入 的, 存储在数据库中, 然后再重新显示, 就必须要确保在每次检索的时候都能正 确编码。如果必须允许自由格式文本输入( 如在消息板中) , 而又希望允许使用 一些 HTML 格式, 则能够经过仅明确允许很小的安全标签列表来安全的处理这 种情况, 如下所示: C#示例: StringBuilder sb = new StringBuilder( HttpUtility.HtmlEncode(input); sb.Replace(, ); sb.Replace(, ); 13 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(); 14 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 请求的响应, 确保返回内容是预期的且有效。 经过编码用户提供的数据从用户输入中删除冲突字符、 括号、 单双引号。这 能够防范以可执行的方式向终端用户发送注入的脚本。 在可能的时候将所有客户端提供的数据仅限于字母数字的数据。使用这种过 滤方案时, 如果用户输入了, 就会被减少为 scriptalertdocumentcookiescript。如果必须使用非字母数字字 符, 在 HTTP 响应中使用之前将其编码为 HTML 实体, 这样就无法将其用于修 改 HTML 文档的结构。 使用双重用户认证机制而不是单重认证。 在修改或使用脚本之前确认其来源。 在自己的代码中使用时不要明确的信任任何来自她人的脚本, 无论是从 web 下载还是来自熟人。 大多数服务器端脚本语言都提供了内嵌方式将输入变量的值转换为正确的不 15 可解释 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, 请继续。 17 步 骤 3. 如 果 要 测 试 跨 站 脚 本 , 在 之 前 使 用 的 同 一 搜 索 或 登 录 框 中 输 入 字符串并发送给 Web 服务器。 步骤 4. 如果服务器所响应的弹出框显示 hello, 则站点受跨站脚本影响。 步骤 5. 即使步骤 4 失败, 站点没有返回这条信息, 仍可能存在风险。在浏览器 中点击”查看源码”选项, 查看 Web 页面的实际 HTML 代码。现在查找发送给 服 务 器 的 文本, 则 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 注入攻击过程中根据 18 数据库支持的 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 19 ( 5) 经过 MD5、 SSL 等加密算法, 对于数据敏感信息和在数据传输过程中加密, 即使某些非法用户经过非法手法获取数据包, 看到的也是加密后的信息。 4、 默认测试用例文件 漏洞影响: 发现目标网站存在测试应用程序。 这种类型的文件一般是由开发人员或者网 站管理员用于测试 web 应用程序的某个功能时留在服务器上的。这些文件可能 包含有敏感信息, 包括已验证的会话 ID, 用户名/密码等。如果攻击者获取到这 些敏感信息, 攻击者能够进一步获取其它敏感数据。 解决方案: 删除此类文件或限制此类文件的访问权限。 5、 管理后台登陆入口 漏洞影响: 检查到目标应用的后台登陆入口。管理员应用程序一般用于网站的后台管 理, 具有全部的权限。这些应用程序可能包含一些敏感信息或具有较低的安全保 护, 攻击者能够经过该文件获取敏感信息或者进入网站后台, 进行恶意操作。 解决方案: 加强访问此类文件的认证和使用安全。如果不需要此类文件, 请删除。修改 20 为不可预测的文件名。 6、 应用程序错误引起的信息泄露 漏洞影响: 如果攻击者经过伪造包含非应用程序预期的参数或参数值的请求, 来探测应 用程序 ( 如以下示例所示) 那么应用程序可能会进入易受攻击的未定义状态。 攻 , 击者能够从应用程序对该请求的响应中获取有用的信息, 且可利用该信息, 以找 出应用程序的弱点。 例如, 如果参数字段应该是单引号括起来的字符串( 如在 ASP 脚本或 SQL 查询中) , 那么注入的单引号将会提前终止字符串流, 从而更改脚本的正常流程/ 语法。错误消息中泄露重要信息的另一个原因, 是脚本编制引擎、 Web 服务器 或数据库配置错误。 以下是一些不同的变体: 1 除去参数 2 除去参数值 3 将参数值设置为空值 4 将参数值设置为数字溢出( +/- 99999999) 5 将参数值设置为危险字符, 如 ) 6 将某字符串附加到数字参数值 解决方案: 21 1 检查入局请求, 以了解所有预期的参数和值是否存在。 当参数缺失时, 发 出适当的错误消息, 或使用缺省值。 2 应用程序应验证其输入是否由有效字符组成( 解码后) 例如, 应拒绝包含 。 空字节( 编码为 %00) 、 单引号、 引号等的输入值。 3 确保值符合预期范围和类型。 如果应用程序预期特定参数具有特定集合中 的值, 那么该应用程序应确保其接收的值确实属于该集合。 例如, 如果应用程 序预期值在 10.99 范围内, 那么就该确保该值确实是数字, 且在 10.99 范围 内。 4 验证数据属于提供给客户端的集合。 5 请勿在生产环境中输出调试错误消息和异常。 7、 备份文件造成的源代码泄漏 漏洞影响: 检测到目标网站存在源代码的备份文件。源代码中可能包含有敏感信息, 并 且源代码能够有效的帮助攻击者理解网站应用逻辑, 为展开其它类型的攻击提供 有利信息, 降低攻击的难度。如果攻击者能够访问该文件, 就有可能获取到敏感 信息。本漏洞属于 Web 应用安全常见漏洞.。 解决方案: 如果不需要此类文件, 删除这些文件; 或者严格限制此类文件的访问权限 22 8、 存在电子邮件地址 漏洞影响: Spambot 搜寻因特网站点, 开始查找电子邮件地址来构建发送自发电子邮 件( 垃圾邮件) 的邮件列表。如果检测到含有一或多个电子邮件地址的响应, 可 供利用以发送垃圾邮件。 而且, 找到的电子邮件地址也可能是专用电子邮件地址, 对于一般大众应是不可访问的。 解决方案: 从 Web 站点中除去任何电子邮件地址, 使恶意的用户无从利用。可将电 子邮件地址存储为图片或将”改为”#” 。 9、 无效链接 漏洞影响: 无效链接是指存在于页面中, 但其指向的资源已经不存在。本漏洞属于 Web 应用安全常见漏洞。 解决方案: 可选择删除。 23 10、 Web 应用默认目录 漏洞影响: Web 应 用 架 构 中 的 目 录 都 采 用 常 见 的 目 录 名 。 如 图 片 目 录 images,javascript 目录 js,不同的目录潜在的危险是不同的。攻击者一般利用常 见目录中可能包含的敏感文件获取敏感信息。本漏洞属于 Web 应用安全常见漏 洞。 解决方案: 如果不需要这些目录, 能够删除此类目录; 或者限制目录的访问权限。 24