WEB应用安全开发与测试
web安全漏洞原理、渗透测试、漏洞整改、安全开发
目录:
- web安全现状
- 现网漏洞分析
- 漏洞形成原理
- 漏洞危害
- 安全漏洞测试方法
- 漏洞整改办法
- 渗透思路与测试方法概括
- 安全开发设计
web安全现状
- 复杂应用系统代码量大、开发人员多、难免出现疏忽;
- 系统屡次升级、人员频繁变更,导致代码不一致;
- 历史遗留系统、试运行系统等多个web系统共同运行于同一台服务器上;
- 开发人员未经过安全编码培训;
- 定制的开发系统的测试程度不如标准的产品;
- 当前web是重点攻击目标
SQL injection-分析
- SQL注入本质:字面量部分被当做SQL语句执行,数据与代码的界限被打破
- 发生场景:select、insert、update、delete等有涉及SQL语句
- 攻击对象:服务端
SQL injection-案例与危害
- 漏洞危害:将整个数据库拖走【爆库名、爆表名、爆字段名、爆字段内容】、提权获取服务器控制权限
- 测试思路:打破字面量(字符型、int型),尝试是否可改变SQL语句的构造。
通过注入神器SQLMAP替代手工注入,如执行:--tables -D "BASSWEB",得到所有的BASSWEB库下面的所有表名。通过该工具可以完成脱库。
SQL injection-整改建议
- 参数化查询,做到了数据与代码分离,是防御sql注入的最佳方式
备注:SQL注入攻击的字符串好比笼中的狮子,无论攻击字符串多危险,只要它被解析为字面量就相安无事
- 过滤器:对输入的特殊字符进行过滤包括:<> “” \ % ; () & + - ' 乃至select 、order by 等sql关键字进行过滤。
优点:整改量小,且不需要去找出每个注入点就可以整改。
缺点:可能影响应用
XML injection
- 和SQL注入原理一样,XML是存储数据的地方,在查询或修改时,如果没有做转义,直接输入或输出数据,都将导致XML注入漏洞。攻击者可以修改XML数据格式,增加新的XML节点,对数据处理流程产生影响。
满足XML注入攻击的两个条件:
1)用户能控制数据的输入
2)程序拼凑了数据
解决方案:
在XML保存和展示前,对用户输入数据中包含的“语言本身的保留字符”进行转义即可。
& --> &
< --> <
> -->>
"-->"
'-->'
code injection
- Web应用中允许接收用户输入的一段代码,之后在web应用服务器上执行这段代码,并返回给用户。所以恶意用户可以写一个远程控制木马,直接获取服务器控制权限。
- 代码注入与命令注入往往都是由一些不安全的函数或者方法引起的,其中典型的代表是eval();
- 执行代码的参数,或文件名,禁止和用户输入相关,只能由开发人员定义代码内容,用户只能提交“1、2、3”参数,代表相应代码。
System command injection
- 系统命令执行攻击,是指代码中有一段执行系统命令的代码,但是系统命令需要接收用户输入,恶意攻击者可以通过这个功能直接控制服务器。
- 所有需要执行的系统命令,必须是开发人员定义好的,不允许接收用户传来的参数,加入到系统命令中去。
XSS(跨站)--漏洞本质
- XSS本质:HTML注入,混淆了原本语义,产生了新的语义(反射型与存储型)
- XSS发生场景:HTML标签、HTML属性、script标签、事件、CSS、URL
- XSS渗透思路:尝试改变语义,执行用户的JS
- 攻击对象:与SQL注入攻击的是服务端不同,XSS攻击对象为用户。
XSS防御--利用OWASP的API
- 使用带有httpOnly属性的cookier(不能防止XSS,但能防止cookie窃取)
- 在HTML标签中输出,对变量使用HtmlEncode
- 在HTML属性中输出,对变量使用HtmlEncode
- 在<script>标签中输出,对变量使用javascriptEncode
- 在事件中输出,对变量使用javascriptEncode
- 在CSS中输出,推荐使用OWASP ESAPI中的encodeForCSS()函数
- 在地址中输出,应先检查变量是否以http开头,如果不是则自动添加,然后在对变量进行URLencode
- 处理富文本,使用XSS规则引擎进行编码过滤,例如OWASP的一个开源项目Anti-Samy
XSS防御--过滤器
- 过滤器:对单引号、双引号、尖括号、括号、& 、/ 等特殊字符进行过滤,更进一步甚至可以对script、iframe等进行过滤。
优点:简单、易处理
缺点:由于方法简单暴力,因此可能影响应用
- 与应用冲突的建议
抓取系统中所有有特殊字符输入需求的页面,形成白名单,然后接受风险或根据应用规格改写针对这类页面的过滤器
根据功能需求,完善过滤器,原则是只要无法去执行用户拼接进去的代码
- 注意
测试过程有发现,直接无法执行,但是进行URL编码后可以执行
伪造跨站请求(CSRF)
- 漏洞原理:通过伪装来自受信任用户的请求改变服务端数据(见到杀人)
- 攻击条件:重要操作的所有参数都是可以被攻击者猜解到
- 渗透思路:对改变服务端数据的操作中(更改用户信息),如果没有随机数,都会产生类似攻击。
- 漏洞攻击过程示意图:
伪造跨站请求(CSRF)--防御
- Anti CSRF Token:Token是根据“不可预测性原则”设计的方案
- 在用户登录时,设置一个CSRF的随机TOKEN,同时种植在用户的cookie中,当用户浏览器关闭、或用户再次登录、或退出时,清除token。
- 在表单中,生成一个隐藏域,它的值就是COOKIE中随机TOKEN。
- 表单被提交后,就可以在接收用户请求的web应用中,判断表单中的TOKEN值是否和用户COOKIE中的TOKEN值一致,如果不一致或没有这个值,就判断为CSRF攻击,同时记录攻击日志
- 备注:token需要足够随机,如果要同时抗重放攻击,那该TOKEN就要一次失效。
url redirect
- 漏洞描述:WEB应用程序接收到用户提交的URL参数后,没有对参数做“可信任URL”的验证,就向用户浏览器返回跳转到该URL的指令。
- 漏洞危害:形成自由重定向(钓鱼攻击)或HTTP消息头注入
- 渗透思路:将重定向的URL改为自己指定的URL(网络可达)
- 可跳转到任一一个网站,非法者可利用这进行钓鱼,搜集合法用户的帐号密码等等。
url redirect --防御
- 为确保用户点击的URL 是从应用程序中生成的URL,所以要做TOKEN验证;
- 当用户访问需要生成跳转URL的页面时,首先生成随机token,并放入cookie
- 应用程序在跳转前,判断token是否和cookie中的token一致,如果不一致,就判定为URL跳转攻击,并记录日志
- 需要判断域名白名单后,才能跳转【可能存在被绕过风险】
- 使用编号指定重定向的目标URL
- 固定重定向的目标URL【评估、固定、不由外界指定】