Web安全漏洞梳理（一）

写在前面

根据自己的学习和工作经验总结下常见漏洞类型和经常会遇到的问题。

一、注入攻击

注入攻击的本质，是把用户输入的数据当作代码执行。

1、SQL注入

漏洞原理&&场景&&危害

web应用程序对用户的输入未进行合法性判断或者过滤不严，导致服务器可以拼接执行恶意的SQL语句。

涉及到操作数据库的功能，如搜索产品、查询用户、排序

可导致：

  1. 机密数据被窃取。
  2. 核心业务数据被篡改。
  3. 网页被篡改。
  4. 数据库所在服务器被攻击变为傀儡主机，甚至企业网被入侵。

修复建议

  1. （最推荐）操作数据库时，应使用预处理/预编译，避免使用SQL拼接。
    mybatis：
    1)使用#符
    2)无法使用#符的场景（排序），使用白名单
    jdbc：
    1)SQL中使用?占位符
    2)使用PreparedStatement

  2. 语义分析过滤SQL注入

  3. 白名单过滤，只允许使用的SQL语句通过

  4. 黑名单过滤，过滤详细规则见：mysql注入黑名单过滤、oracle注入黑名单过滤

  5. 前端加密，将请求使用js加密，并做好js混淆。增加解密难度，至少能防住扫描器

测试方法

首先找注入点：

  1. 输入单引号，看页面报错信息
  2. 涉及数据库操作功能的每个参数都要测试，比如搜索、登录、修改数据、提交表单等。若是使用mybatis的多数问题出在order参数
  3. xray等被动扫描器

找到注入点之后，看功能可使用sqlmap查其他数据。
！！！涉及post提交表单或者直接修改数据的真实环境功能千万别用，会产生大量数据，或者数据库被批量修改！！！

2、代码执行/注入&命令执行/注入

区别与联系

注入/执行 我理解是一个意思，不同的人的习惯叫法不一样。

《白帽子讲web安全》：代码注入和命令注入都是由一些不安全的函数或者方法引起的。代码注入多见于脚本语言，有时候代码注入也可以导致命令注入。
严格来说，PHP、JSP的动态include（文件包含漏洞）导致的代码执行，都算代码注入

《web安全深度剖析》：命令执行漏洞是直接调用操作系统命令，故这里叫做OS命令执行漏洞，可执行外部应用程序的函数导致的叫命令执行。而代码执行漏洞靠执行脚本调用操作系统命令

php代码注入函数

eval()  //可以将字符串按照PHP代码来执行，即动态执行PHP代码
preg_replace()
ob_start()
array_map()  //返回用户自定义函数处理后的数组

php命令注入函数

//这类函数可执行外部应用程序
system()
shell_exec()
exec()
passthru()

java代码注入函数

javascript脚本引擎

engine.eval()

Java命令注入函数

runtime.exec()

jsp代码注入函数/文件包含

动态include

根据以上总结，两本书讲的意思大致一样，调用函数执行的是脚本代码的是代码注入，调用函数执行的是外部应用程序命令，比如系统命令的，是命令注入。

漏洞原理&&场景&&危害

命令执行执行的是系统中的命令,使目标服务器的命令在目标服务器上去执行我们想要执行的命令，系统命令的执行还是要基于某些函数的调度去实现的。

代码执行是指应用程序过滤不严，用户可以通过请求将代码注入到应用中执行

第三方框架漏洞、使用到命令执行、代码执行函数的功能。

可继承Web服务程序的权限去读写文件。执行系统命令反弹shell，控制整个网站甚至控制服务器

修复建议

Java：
1）不使用Runtime.exec,使用api获取相应信息
2）如必须使用Runtime.exec，使用白名单或者过滤

其他命令执行

本地命令执行----CSV注入

能控制数据导出excel的地方,插入代码

=1+cmd|' /C calc'!A0

导出成excel，点击代码执行弹出计算器excel2007

高版本的excel和WPS不能弹，但是插入太多代码会卡掉

3、XSS

漏洞原理&&场景&&危害

XSS（跨站脚本攻击）本质上是一种“HTML注入”，指的是攻击者通过“HTML注入”篡改网页、插入恶意脚本，当用户浏览该页面时，嵌入其中Web里面的恶意脚本会被执行。
存储型XSS：用户插入的恶意脚本被存储到数据库中，每次访问页面都会被触发，具有持久性，危害较高。
反射型XSS：需要用户交互，当用户访问带有恶意脚本的链接后触发，只执行一次。
DOM型XSS：也是反射型，但是代码没有插入到后端，在前端解析DOM树执行js

所有涉及到用户可控的输入输出点。比如表单提交、搜索、留言板、附件名称等。

  1. 身份盗用：Cookie 是用户对于特定网站的身份验证标志，XSS 可以盗取到用户的 Cookie，从而利用该 Cookie 盗取用户对该网站的操作权限。如果一个网站管理员用户 Cookie 被窃取，可直接使用管理员身份登录系统执行敏感操作。
  2. 钓鱼欺骗：最典型的就是利用目标网站的反射型跨站脚本漏洞将目标网站重定向到钓鱼网站，或者注入钓鱼 JavaScript 以监控目标网站的表单输入。
  3. 获取页面敏感数据
  4. 网站挂马：在网页中插入木马服务器地址，存在漏洞的用户访问时被定向木马服务器上，攻击者可直接获取用户系统权限。
  5. XSS 蠕虫：在用户之间发生交互行为的页面，形成广泛的传播。
  6. 劫持用户 Web 行为：一些高级的 XSS 攻击甚至可以劫持用户的 Web 行为，监视用户的浏览历史，发送与接收的数据等等。
  7. 结合其他漏洞利用，如CSRF

修复建议

  • 应至少在输入和输出任意一项（最好是都做，因为只修输出很有可能还有其他输出点，只修输入有可能还有其他输入点）中进行适当的过滤或转义。【HTML实体化编码】
  • 对标识用户身份信息的关键cookie设置httponly，设置httponly，XSS就无法获取到cookie
  • 类似富文本等无法完全转义的情况，可以使用白名单。只允许用户输入安全的HTML标签，如<b>, <i>, <p>等，对其他数据进行HTML编码。

DOM XSS

参考：https://www.secpulse.com/archives/92286.html

1.对于写标签类的DOM型XSS，输出到HTML中(实体化转义)例如

document.getEelementById("id") = innerHTML = "<img src=x onerror=alert(1)>"
只需要将<>实体化即可，将<>替换成&lt;&gt;

2.对于跳转类的XSS，例如

location.href = "javascript:alert(1)"有一个简单的方法，就是将这个url创建成一个a标签，检查它的host是否合法，是否以http或指定的协议开头，否则视为非法跳转。

3.对于eval(string)类的XSS

不建议使用这种写法，一个负责的开发不应该写这种代码出来。

如果实在要用，需要过滤非常多的字符，双引号，单引号，反引号，等于号，小括号，点，加减乘除，和一些特殊的字符，例如name,top,parent,opener等等（以上列出不完全）

编辑器XSS

富文本编辑器处的XSS处理比较复杂，建议按照以下几条原则：

  1. 前后端同时校验规则
  2. 标签做白名单过滤（比如说a标签、p标签等），出现其他标签均做过滤。
  3. 所有标签不允许使用on事件
  4. src属性的值不允许是js代码（只能为http或者/path 之类的表示资源路径的）
  5. 属性使用白名单过滤，比如只允许width、value等属性

如果以上实现较困难，也可以尝试替换编辑器为ueditor最新版等较安全的编辑器

测试方法

  1. 找测试点，get、post的参数都可能存在。注意闭合
  2. 看数据包response，看浏览器源代码，有可能输出点在其他页面
  3. 插入XSS平台的payload来绕过，可以在XSS平台看数据,只勾选默认模块就行，勾多了数据过不来
  4. 如果有，但是被拦截了->尝试绕过，转码（html、unicode）、大小写等
  5. jsonp接口xss