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【评估、固定、不由外界指定】
