WEB应用安全技术交流.pdf

《WEB应用安全技术交流.pdf》由会员分享，可在线阅读，更多相关《WEB应用安全技术交流.pdf（50页珍藏版）》请在三一文库上搜索。

1、重庆易极付科技有限公司曾锋 WEB应用安全技术交流 漏洞解析篇 上传绕过漏洞 二 二 三 三 四 四 XSS漏洞 一 一 背景 逻辑缺陷漏洞 五 五 SQL注入漏洞 其他漏洞介绍 六 六 目录 总结 七 七 漏洞对企业带来的损失（数量） 乌云平台中，白帽子已累积为腾讯提交1273个漏洞 漏洞对企业带来的损失（类型） 漏洞对企业带来的损失（案例） 2014年曝光的部分安全漏洞: 1、携程网日志下载致用户银行卡等信息泄漏 2、小米科技“拖库“致800W用户信息泄露 3、openssl心脏出血漏洞影响所有使用https协议的站点 4、苹果iCloud漏洞导致大量明星艳照流出 据官方数据统计，约3/4

2、的攻击发生在应用层。 OWASP Top 10 2010-2013 上传绕过漏洞 二 二 三 三 四 四 XSS漏洞 一 一 SQL注入漏洞 逻辑缺陷漏洞 五 五 背景 其他漏洞介绍 六 六 目录 总结 七 七 1、原理 SQL注入原理：它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据 库引擎进行执行，通过输入（恶意）SQL语句得到一个存在安全漏洞的网站上的 数据库，而不是按照设计者意图去执行SQL语句。 2、案例 某高校招生办SQL注入漏洞 Step 1 使用渗透工具safe3 SI工具获取数据库数据，如图，获取到admin账户的md5密码 Step 2进行md5解密，得到明文：x

3、xxxx Step 3管理页面入口在前台页面，可直接利用 Step 4 利用获取的admin密码可成功登录 3、防御措施 防止特殊字符对现行语句的逻辑、语义的切割 不拼接sql语句 使用安全框架 校验传入参数，转移特殊字符 SQLSQL注入漏洞 二 二 三 三 四 四 XSS漏洞 一 一 上传绕过漏洞 逻辑缺陷漏洞 五 五 背景 其他漏洞介绍 六 六 目录 总结 七 七 1、原理 由于程序员在对用户文件上传部分的控制不足或者处理缺陷，而导致的用户可以越过 其本身权限向服务器上上传可执行的动态脚本文件。打个比方来说，如果你使用 windows 服务器并且以 asp 作为服务器端的动态网站环境，那

4、么在你的网站的上传 功能处，就一定不能让用户上传 asp 类型的文件，否则他上传一个 webshell，你服 务器上的文件就可以被他任意更改了。 上传检查 客户端检查 服务端检查 js检查扩展名 js限制content-type content-type 扩展名 黑白名单 文件头检测 加载检测 二次渲染检测 2、案例 某OA系统存在上传绕过漏洞 Step 1 在OA系统进行资讯内容修改时，上传图片处可绕过客户端后缀名限制，成功上 传一asp文件 Step 2 使用webshell管理工具执行该asp脚本，可对服务器上的文件进行任意操作 3、防御措施 定义上传文件类型白名单并在服务器端进行检测（

5、例如只允许上传jpg，txt） 对文件上传目录禁止脚本解析 判断文件扩展名与文件头是否相匹配(例如扩展名是jpg需检测文件头是否为 0xFFD8FF，判断扩展名需从后往前检测，检测需在服务端完成) 上传文件存储服务器与应用服务器分离 是否对文件进行重新编码（例如图片文件，服务端对上传的文件重新编码生成 新的图片文件然后再保存）（可选策略） SQLSQL注入漏洞 二 二 三 三 四 四 上传绕过漏洞 一 一 XSS漏洞 逻辑缺陷漏洞 五 五 背景 其他漏洞介绍 六 六 目录 总结 七 七 1、原理 依据攻击的形式，XSS可分为如下3类： a、反射式 b、存储式 c、DOM跨站 依据攻击者利用应用

6、程序的动态展示数据功能，在html页面里嵌入恶意代码。当 用户浏览该页之时，这些嵌入在html中的恶意代码会被执行。从而用户浏览器被 攻击者控制，达到攻击者的特殊目的。 反射式 反射式跨站的过程是客户端提交包含恶意html代码的请求至服务端，服务端未 对该代码做任何编码、转义处理，响应中原样返回这些代码，就会在浏览器中 执行。 存储式 存储式跨站的过程是客户端向服务端提交恶意代码，服务端（数据库）未对这些代 码做任何处理，原样存储下来。当前端浏览器再次请求该数据时，漏洞就会触发， 用户受到攻击。 DOM跨站 DOM跨站与前两种有一定的区别，是通过修改页面DOM节点数据信息而形成的XSS 跨站脚

7、本攻击，其注入的脚本不经过服务端，可直接在客户端执行。 2、案例 事件的经过线索如下： 20:14，开始有大量带V的认证用户中招转发蠕虫 20:30，某网站中的病毒页面无法访问 20:32，新浪微博中hellosamy用户无法访问 21:02，新浪漏洞修补完毕，影响32961人 a、漏洞过程 新浪微博hellosamy蠕虫 b、漏洞剖析 该漏洞的成因主要是新浪微博广场中的XSS漏洞引起的，攻击者构造恶意 链接：http:/ 点击该链接后便执行t.js脚本，完成如下操作： （1）发表微博 （2）关注攻击者微博帐号 （3）遍历关注用户列表并发送私信 PS：该案例由以下2个漏洞引起 （1）XSS：通

8、过该漏洞在链接中注入脚本，为t.js脚本的的执行埋下伏笔 （2）CSRF：t.js脚本的成功执行需要用户的合法cookie 3、防御措施 严格检查用户输入 尽量限制在HTML代码中插入不可信的内容（可被用户输入或修改的内容） 对于需要插入的不可信内容必须先进行转义（尤其对特殊字符、语法符合必须转 义或重新编码） 将Cookie设置为HttpOnly，防止被脚本获取 SQLSQL注入漏洞 二 二 三 三 四 四 上传绕过漏洞 一 一 逻辑缺陷漏洞 XSS漏洞 五 五 背景 其他漏洞介绍 六 六 目录 总结 七 七 1、原理 所有应用程序都是通过逻辑实现各种丰富多彩的功能的，要实现这些功能，必须

9、掌握大量的技巧并进行周密的安排。但是，有很多情况这些功能逻辑存在缺陷， 比如设计者的安全意识，比如考虑问题不周全等。即使是最简单的web应用程序， 每个阶段都会执行大量的逻辑操作，这些逻辑操作代表着一个复杂的攻击面，它 从没有消失，只是容易被遗忘。 常见的逻辑错误如下： a、欺骗密码找回功能 b、顺序执行缺陷 c、规避交易限制 d、时间刷新缺陷 2、案例 某电商支付逻辑漏洞 Step 1 在某电商平台购买价值1700元的商品，提交支付请求 Step 2 抓取该请求后，修改price字段为1元 Step 3 成功跳转到支付页面，可见修改订单金额成功 3、防御措施 应用程序的设计信息要清楚，并详细

10、记录在文档中，以便他人审查（主要是安 全检查人员） 执行安全测试时，需设计全面的逻辑缺陷测试用例，尽量覆盖设计过程中的每 一个应用场景 执行PRD（产品需求设计）安全评审，考虑用户的反常操作或输入是否对系统造 成不利影响 SQLSQL注入漏洞 二 二 三 三 四 四 上传绕过漏洞 一 一 其他漏洞介绍 XSS漏洞 五 五 背景 逻辑缺陷漏洞 六 六 目录 总结 七 七 1、CSRF CSRF原理：该漏洞是多窗口浏览器带来的，攻击者通过浏览器中共享的cookie伪 造恶意请求，通过伪造身份提交POST和GET请求来进行攻击。 案例 某站点更改密码存在CSRF漏洞 Step 1 更改密码处无需验证

11、旧密码，此处存在CSRF漏洞 Step 2 下图为构造的修改密码表单，黑客将该表单部署在服务器上，配置访问地址为 http:/ 防御措施 校验请求中referer信息 在功能请求页面设置csrf token，并在服务端对token进行验证 重要操作可考虑增加图片验证码校验 2、URL跳转攻击 Web应用程序接收到用户提交的URL参数后，没有对参数做“可信任URL”的验证， 就向用户浏览器返回跳转到该URL的指令。 钓鱼攻击： http:/ http:/ 案例 Step 1 攻击者可以发送http:/ 惑用户打开。 某电商平台钓鱼漏洞 Step 2 用户打开页面。显示需要登陆，于是用户输入了账户

12、和密码，登陆。 无论用户输入什么，都跳转到了恶意攻击者指定的钓鱼页面，这个页面显示给用户“会员登录名或密码错误”， 注意URL中的链接地址。 Step 3 用户看到“密码错误”，就再次输入密码。由于用户现在看到的页面，其实是恶意攻击者伪造的钓鱼程 序，而用户却以为这些操作都是在alibaba网站上做的，所以用户在钓鱼程序中输入了密码。 防御措施 在跳转请求中增加redirect_token签名 a、当用户访问需要生成跳转URL的页面时，首先生成随机token，并放入cookie。 b、在显示连接的页面上生成URL，在URL参数中加入token。 c、应用程序在跳转前，判断token是否和coo

13、kie中的token一致，如果不一致，就 判定为URL跳转攻击。 严格限制跳转url范围，可进行白名单配置 页面跳转操作可考虑设置白名单，判断目的地址是否在白名单列表中，如果不在 列表中，就判定为URL跳转攻击。 3、权限类漏洞 水平权限 Web应用程序接收到用户请求，修改某条数据时，没有判断数据的所属人，或判 断数据所属人时，从用户提交的request参数（用户可控数据）中，获取了数据所 属人id，导致恶意攻击者可以通过变换数据ID，或变换所属人id，修改不属于自 己的数据。 垂直权限 由于web应用程序没有做权限控制，或仅仅在菜单上做了权限控制，导致的恶意 用户只要猜测其他管理页面的URL

14、，就可以访问或控制其他角色拥有的数据或页 面，达到权限提升目的。 案例 买卖宝平行越权漏洞 Step 1 已知adminmang对应的商品orderid为31939648， adminmang2对应的商品orderid为31939693。下图为 adminmang的历史订单页面。 Step 2 使用账号adminmang2进行删除订单（ orderid为31939693 ）操作，修改请求中orderid为账号 adminmang的订单id，成功删除。 防御措施 严格校验用户权限与所操作行为是否匹配 严格校验用户与所操作资源间的对应关系 将身份/资源ID放在session中或加密后放在cooki

15、e中，限制用户直接修改 4、敏感信息泄露 由于没有一个通用标准的防御规则保护好系统中的敏感数据及配置信息，攻击者 可能会通过收集这些保护不足的数据，利用这些信息对系统实施进一步的攻击。 常见的敏感信息如下： a、中间件配置信息 b、 DNS信息 c、业务数据信息 d、用户信息 e、源码备份文件 f、版本管理工具信息 g、系统错误信息 h、敏感地址信息(后台或测试地址) 案例 某站点备份文件泄漏 Step 1 该站点备份文件地址： http:/ 容如下，可见已泄漏数据库接口信息 防御措施 正确处理好程序的异常以及函数调用的返回信息 对外使用时，采用统一的错误页面 关闭应用程序不必要的输出,如调试

16、，错误信息的输出 隐藏后台系统入口地址，对管理后台进行IP访问控制 SQLSQL注入漏洞 二 二 三 三 四 四 上传绕过漏洞 一 一 总结 XSS漏洞 五 五 背景 逻辑缺陷漏洞 六 六 目录 其他漏洞介绍 七 七 WEB安全漏洞防御总结 1、SQL语句建议采用 PreparedStatement 的填充参数方式，严禁使用字符串拼接 2、不管客户端是否做过数据校验，在服务端必须要有数据校验（长度、格式、 是否必填等等） 3、为防止XSS，对参数做html转义过滤（要过滤的字符包括：单引号、双引号、 大于号、小于号，&符号） 4、逻辑设计务必一致 5、使用 HTTPS 进行通信，以保证在网络传输过程中是安全的 Q&A