BS架构体系安全渗透测试基础.ppt

B S架构体系安全渗透测试基础 质量保证部朱晟 内容概要 前言当今世界 Internet 因特网 已经成为一个非常重要的基础平台 很多企业都将应用架设在该平台上 为客户提供更为方便 快捷的服务支持 这些应用在功能和性能上 都在不断的完善和提高 然而在非常重要的安全性上 却没有得到足够的重视 由于网络技术日趋成熟 黑客们也将注意力从以往对网络服务器的攻击逐步转移到了对Web应用的攻击上 根据最新调查 信息安全攻击有75 都是发生在Web应用而非网络层面上 同时 数据也显示 三分之二的Web站点都相当脆弱 易受攻击 就公司以前WEB项目外部应用的现状 90 的网站都受到过类似SQL注入等黑客的攻击 管理部分内容索引 B S架构常见安全问题 B S架构常见安全问题 当讨论起Web应用安全 我们经常会听到这样的回答 我们使用了防火墙 我们使用了网络脆弱扫描工具 我们使用了SSL技术 所以 我们的应用是安全的 现实真是如此吗 让我们一起来看一下Web应用安全的全景图 为何要进行安全测试 但是 即便有防病毒保护 防火墙和SSL 企业仍然不得不允许一部分的通讯经过防火墙 毕竟Web应用的目的是为用户提供服务 保护措施可以关闭不必要暴露的端口 但是Web应用必须的80和443端口 是一定要开放的 可以顺利通过的这部分通讯 可能是善意的 也可能是恶意的 很难辨别 这里需要注意的是 Web应用是由软件构成的 那么 它一定会包含缺陷 bugs 这些bug就可以被恶意的用户利用 他们通过执行各种恶意的操作 或者偷窃 或者操控 或者破坏Web应用中的重要信息 只要访问可以顺利通过企业的防火墙 Web应用就毫无保留的呈现在用户面前 只有加强Web应用自身的安全 才是真正的Web应用安全解决之道 风险性较高的攻击方法 跨站点脚本攻击 和 注入缺陷攻击 是目前Web应用中比例最高的两种攻击手段 还有如下八种风险性较高的攻击方法 MaliciousFileExecution 恶意文件执行 InsecureDirectObjectReference 不安全的直接对象引用 Cross SiteRequestForgery 跨站点的请求伪造 InformationLeakageandImproperErrorHandling 信息泄漏和不正确的错误处理 BrokenAuthentication SessionManagement 损坏的认证和Session管理 InsecureCryptographicStorage 不安全的密码存储 InsecureCommunications 不安全的通信 FailuretoRestrictURLAccess 未能限制URL访问 在这里 我简单介绍下这些缺陷 常见的Web应用攻击示例 1 跨站点脚本攻击 cross sitescr pting 简称XSS 首先来看一下跨站点脚本的利用过程 如图 在上图中 恶意攻击者 这里使用Evil org表示 通过E mail或HTTP将某银行的网址链接发给用户 银行用表示 该链接中附加了恶意的脚本 上图步骤一 用户访问发来的链接 进入银行网站 同时 嵌在链接中的脚本被用户的浏览器执行 上图步骤二 三 用户在银行网站的所有操作 包括用户的cookie和session信息 都被脚本收集到 并且在用户毫不知情的情况下发送给恶意攻击者 上图步骤四 恶意攻击者使用偷来的session信息 伪装成该用户 进入银行网站 进行非法活动 上图步骤五 因此 只要Web应用中 有可被恶意攻击者利用执行脚本的地方 都存在极大的安全隐患 黑客们如果可以让用户执行他们提供的脚本 就可以从用户正在浏览的域中偷到他的个人信息 可以完全修改用户看到的页面内容 跟踪用户在浏览器中的每一个动作 甚至利用用户浏览器的缺陷完全控制用户的机器 目前 跨站点脚本攻击是最大的安全风险 检查您的站点是否处于XSS攻击保护的方法 检查站点的确安全也可以通过手工完成 硬方法 或利用自动的Web应用程序安全漏洞评估工具 如appscan 它减轻了检查的负担 该工具爬遍站点 然后根据尝试参数 头 和路径找到的所有脚本 运行其知道的所有变化 在这两种方法中 用尽可能多的方式检查对应用程序的每个输入 所有脚本的参数 HTTP头 路径 如果响应页面包含浏览器可以执行的Javascr pt代码 那么XSS安全漏洞就已显露出来 举例来说 首先 找到带有参数传递的URL 如登录页面 搜索页面 提交评论 发表留言页面等等 其次 在页面参数中输入如下语句 如 Javascr pt VBscr pt HTML Flash 来进行测试 alert document cookie 最后 当用户浏览时便会弹出一个警告框 内容显示的是浏览者当前的cookie串 这就说明该网站存在XSS漏洞 试想如果我们注入的不是以上这个简单的测试代码 而是一段经常精心设计的恶意脚本 当用户浏览此帖时 cookie信息就可能成功的被攻击者获取 此时浏览者的帐号就很容易被攻击者掌控了 XSS攻击示例 大名鼎鼎的淘宝网也存在这样的漏洞 我们在搜索框中输入 ahref 这样 我们已经修改了淘宝原有的页面 在下面嵌入了百度的首页 效果如图 如何预防XSS漏洞 从应用程序的角度来讲 要进行以下几项预防 对Javascr pt VBscr pt HTML Flash等语句或脚本进行转义 在服务端正式处理之前提交数据的合法性 合法性检查主要包括三项 数据类型 数据长度 敏感字符的校验 进行检查等 最根本的解决手段 在确认客户端的输入合法之前 服务端拒绝进行关键性的处理操作 从测试人员的角度来讲 要从需求检查和执行测试过程两个阶段来完成XSS检查 在需求检查过程中对各输入项或输出项进行类型 长度以及取值范围进行验证 着重验证是否对HTML或脚本代码进行了转义 执行测试过程中也应对上述项进行检查 注入缺陷 2 注入缺陷目前的Web应用中 绝大多数都会向用户提供一个接口 用来进行权限验证 搜索 查询信息等功能 比如一个在线银行 首先会有对注册客户进行身份验证的登录界面 在正确登录后 会提供更多交互功能 如根据客户的银行卡号信息 查询客户的最近交易 转账细节等 这些都是注入缺陷的最佳利用场景 所谓注入缺陷 就是在上述场景中 用户输入的数据被当做命令和查询的一部分 送到后端的解释器中解释执行 如果用户的输入是正常合法的 Web应用自然会返回正常合理的结果 但是 如果恶意攻击者 利用输入数据可被后台执行的原理 偷梁换柱 使用非法的输入 脆弱的Web应用会怎样呢 下面举一个例子来说明注入缺陷是如何进行的 在一个交易网站中 用户必须输入产品ID号才可以查看该产品的详细信息 为了实现这个需求 通常会用SQL语句查询数据库来实现 开发人员在编写应用程序时 可能会使用如下的SQL语句来实现上述目的 这里仅为示例 1 Select fromproductswhereproduct id 用户输入的ID 这里的products是数据库中用来存放产品信息的表 号表示SQL语句需要和用户输入的真实ID进行拼接 如果用户输入325 则该语句在执行时变为 Select fromproductswhereproduct id 325 数据库会将ID为325的产品信息返回给用户 2 在界面上 需要用户输入产品ID的地方 黑客会输入如下数据 or 1 1可以看到 黑客并没有输入正常合法的产品编号 3 通过黑客的非法输入 需要执行的SQL语句变为 Select fromproductswhereproduct id or 1 1 可以看出 SQL语句的意义就完全改变了 当产品ID为空或者1 1时 返回产品所有信息 而1 1是永远成立的条件 因此 黑客并没有输入任何产品编号 就可以返回数据库中所有产品的详细信息 通过这个例子 我们可以看出 注入缺陷是风险非常高的安全漏洞 一旦Web应用中给用户提供了需要其输入数据的接口 就有可能遭到攻击 将后台的数据完全暴露在用户的面前 如何预防SQL注入 从应用程序的角度来讲 我们要做以下三项工作 转义敏感字符及字符串 SQL的敏感字符包括 exec xp sp declare Union cmd 0 x 和 空格 屏蔽出错信息 阻止攻击者知道攻击的结果在服务端正式处理之前提交数据的合法性 合法性检查主要包括三项 数据类型 数据长度 敏感字符的校验 进行检查等 最根本的解决手段 在确认客户端的输入合法之前 服务端拒绝进行关键性的处理操作 从测试人员的角度来讲 在程序开发前 即需求阶段 我们就应该有意识的将安全性检查应用到需求评审中 例如对一个表单需求进行检查时 我们一般检验以下几项安全性问题 需求中应说明表单中某一FIELD的类型 长度 以及取值范围 主要作用就是禁止输入敏感字符 需求中应说明如果超出表单规定的类型 长度 以及取值范围的 应用程序应给出不包含任何代码或数据库信息的错误提示 当然在执行测试的过程中 我们也需求对上述两项内容进行测试 信息泄漏和不正确的错误处理 此漏洞利用的重点在于应用程序未能正确处理自身发生的错误 技术重点在于某些应用程序出错时 会把错误信息反馈到用户端 这些错误信息通常可用于调试的目的 从错误反馈信息中获取有用的信息 从而加以利用 突破网站安全 当Web应用程序发生错误时 如果处理不得当 可能会把相关的错误信息反馈至客户浏览器 这种情况更多见于PHP MySQL的Web应用 一些程序人员没有正确的做异常处理 当发生错误里 系统向浏览器端返回了本来是用于调试目的的相关信息 这些信息往往可能含有重要的安全信息 例如 某个网站的MySQL停止了运行 而这时用户访问此网站时 发现网页提示如下信息 MySQLError LostconnectiontoMySQLserverduringquery从这个回馈来看 用户请求的页所使用的数据库是MySQL 这无疑暴露是安全人员所不希望看到的 高明的入侵者 会尽可能的使其在页面浏览或提交时 使用不正当的数据或方法 以此期望页面产生错误回馈 从而利用这些信息完成入侵 从服务器角度 关闭调试信息回馈功能 并且善用异常处理功能 可以尽可能避免此类安全漏洞 不安全的直接对象引用 不安全的直接对象引用漏洞利用的重点是web开发中 应用代码访问文件时没受到权限控制 技术重点在于利用有漏洞的web程序读取文件系统资料 本文主要介绍不安全的直接对象引用漏洞的过程而不是技术细节 以PHP为例 看以下这个场景 filea GET filename echo 下载此链接 如果恶意用户对之加以利用 就可能可以使用如下方式下载用户主机上其他的文件解决此问题的方法是必须控制web应用程序对文件的访问 跨站请求伪造 跨站请求伪造漏洞利用的重点攻击者了解受害者所在的站点 在于攻击者需要精心构造可以完成目标装点数据修改的URL 攻击者的目标站点具有持久化授权cookie或者受害者具有当前会话cookie 并且目标站点没有对用户在网站行为的第二授权 我们假定三个角色 攻击者 用户 网上银行 一个论坛 攻击的流程主要分以下几个步骤 1 用户连入网上银行操作 该网上银行使用持久化授权cookie 只要用户不清除cookies 任何时候连入网上银行时 该银行网站都认为该用户是有效的 2 攻击者在论坛上发表图片 内嵌有GET或POST方法的URL并指向该网上银行 如果该URL由一个银行的合法用户发出 则该URL会使用户帐户被修改 3 用户浏览此论坛并点击该图片 攻击者预设的URL被由用户发往银行站点 因该用户未清除cookie 该请求有效 用户帐户在用户并不知情的前提下被成功修改 我们注意到 这个过程很象跨站脚本攻击 但实际上 是完全不同的 跨站脚本攻击需要在客户端写入恶意代码 以搜集cookie等信息 而跨站请求伪造则根本不需要向用户端写入任何东西 直接利用银行授权的持久认证和用户未清理的cookie 这里的问题在于 论坛用户不能上传js脚本 于是直接利用URL来诱骗用户 以致于完成数据操作 由此可见 该攻击的重点在于要知道目标站点和目标用户 并且该受害站点没有使用更多的授权认证 对于web站点 将持久化的授权方法 例如cookie 切换为瞬时的授权方法 在每个form中提供隐藏field 这将帮助网站防止这些攻击 一种类似的方式是在form中包含秘密信息 用户指定的代号作为cookie之外的验证 未能限制URL访问 由于各页面以及web访问规则控制不严格 导致不具有权限的用户可以直接访问相关的URL资源 这种漏洞比较浅 常见的问题多见于程序在访问控制方面控制不够严格 比较突出的问题是 开发人员在开发过程中假设用户是友善而可信的 由于使用计算机的人也许并不是真正的用户 因此 权限控制也在很大范围上带来了问题 此问题比较浅显 应该通过严格的设计和测试予以避免 没有登录或注销登录后 直接输入登录后才能查看到的页面网址 含跳转页面 能直接打开页面 注销后 点击浏览器上的后退 可以进行操作 正常登录后 输入没有权限查看的页面网址 可以打开页面 不安全的密码存储 对于Web应用程序来说 妥善的保存密码 用户名 以及其它与身份验证有关的信息是非常重要的工作 对这些信息进行加密是非常有效的方式 但是一些企业会采用那些未经实践验证的加密解决方案 其中就可能存在漏洞 关于此类信息的