前言
▶ 在上一篇文章中重点分析了SQL注入漏洞以及介绍了其修复方案，但是给出的修复方案并没有完全修复SQL注入漏洞。接下来将详细分析未完全修复的SQL注入漏洞的绕过方案和修复方法。
漏洞分析1（上一期未完全修复的SQL注入漏洞）
▶ 审计过程
▪看到 'lib/mysql.func.php'第28行，其中'$table'虽然是可变参数，但是其数据不是用户传递得到的，所以该变量安全。但是'$key'是用户传递过来的，它来自'$_POST'数组中的'键'，所以该变量用户可控。再注意观察，'$key'两旁并没有用引，所以这条SQL语句并不需要引号就可以闭合，那么 'mysql_real_escape_string'函数在此处也就没有作用了。
▶ 漏洞复现
▪只要将payload稍作修改，并将payload写在键值对的 '键'中，而不是'值'中即可绕过转义函数的限制。如下图所示，发送请求5s后才收到响应包，这说明 'sleep(5)'函数执行成功，存在SQL注入漏洞。
username=test&password=123456&email)/**/values(1,1,sleep(5));#=执行的SQL语句：
INSERT INTO admin_root(username,password,email)/**/values(1,1,sleep(5));#) VALUES('test','e10adc3949ba59abbe56e057f20f883e','')
▶ 修复方案
▪ 此处'mysql_real_escape_string'函数无效，那么可以采用白名单的方式来过滤非法字符。'$key'代表的是数据表中的字段名，所以可以用所有表中字段名建成一个白名单。将这个白名单写在 'lib/mysql.func.php'中，如下图所示：
$allow_columns = array('id', 'username', 'password', 'email', 'imageName', 'imagePath');
▪然后逐个判断 '$key'是否存在白名单中，如果不存在则直接删除这个键值对。
global $allow_columns;foreach ($data as $key=>$value) {if (!in_array($key, $allow_columns)) {unset($data[$key]);}}
▪ 再次测试，发现 'sleep(5)'没有执行。此时SQL注入漏洞已经完全修复。
漏洞分析2
▶ 审计过程
▪ 看到 'lib/mysql.func.php'的34行的update函数，该函数中未对传入数据中特殊字符转义，所以存在sql注入漏洞。
▪ 在函数中加入下面两行代码对特殊字符进行转义：
$key = mysql_real_escape_string($key);$value = mysql_real_escape_string($value);
▪ 判断'$key'是否在白名单中，不在白名单中则删除该键值对：
global $allow_columns;foreach ($data as $key=>$value) {if (!in_array($key, $allow_columns)) {unset($data[$key]);}}
▪ 现在虽然处理了参数'$data'传入的数据，但是在这个函数中还有一个参数'$where'可能存在sql注入漏洞。看到 'core/core.php'的44行，此处的'id={$id}'即函数 'update'中的 '$where'。接下来继续寻找 '$id'的源头，因为'$id'和 '$admin_user'的源头不同数据流终点相同，所以依次点击左边 'mysql.func.php:41 (Shared Sink) - [0/4]'下面的几个数据流就可以很快找到 '$id'的源头。
▪ 看到 'admin/doAdminAction.php'的第18行，'$id'来源于POST数据，然后'$id'传递给了'updateAdmin'函数。整个数据流中未对 'id'进行任何处理，所以一定存在sql注入。
▶ 漏洞复现
▪ 在浏览器中修改用户资料，同时用burpsuite抓取数据包，构造好payload并发送数据包。如下图所示程序成功执行了构造好的payload。
id=2 and sleep(5)&username=test&password=&email=test
▶ 修复方案
▪要注意其中的 '$where'，'$where'拼接在SQL语句中'WHERE'的后面，那么'$where'的格式应该为 'key1='value1' and/or key2='value2'或者没有引号的'key1=value1 and/or key2=value2'。如果 '$where'中存在引号则不能直接对 '$where'进行转义，需要先对接收到的数据转义，然后再将数据传递给变量'$where'。
▪继续看到 'lib/core.php'的第44行，此处'$id'为'int'型，所以可以通过 'intval'函数处理。或者在'$id'两旁加上单引号并用 'mysql_real_escape_string'函数处理。
▪ 在 '$id'传入函数前面添加下面代码即可：
$id = intval($id);
▪ 再次尝试，发现payload已经无效了。
▪通过mysql监控工具发现sql语句中的id并不等于 '2 and sleep(5)'，而是等于2。因为字符串经过 'intval'函数处理后就会变成整数。其他sql注入漏洞修复方法类似，请各位师傅尝试自行修复。
漏洞分析3
▶ 审计过程
▪ fortify提示没有设置'httponly'。如果没有设置 'httponly'，那么用户可以通过js获取cookie。如果仅仅是没有设置 'httponly'，那么攻击者无法利用这个漏洞。但是这与XSS结合，那么危害就很大了。
▶ 漏洞复现
▪ 登录网站后台，记得勾选'记住密码'，这样才会设置cookie。
▪ 登录网站后台后按下 'F12'调出控制台，然后在控制台输入以下js代码并执行。这句js代码的意思是获取cookie并在控制台输出。执行代码后发现成功输出的cookie。
console.log(document.cookie);
▶ 修复方案
▪cookie可以分为自定义设置的cookie和标识seesion的cookie。自定义生成的cookie是通过 'setcookie'函数或者 'setrawcookie'函数设置，这两个函数的第7个参数代表是否设置 'httponly'，默认为'false'。标识session的cookie，也就是 'PHPSESSID'会在启用session的时候存储在浏览器中。'PHPSESSID'开启 'httponly'既可以在配置文件 'php.ini'中修改'session.cookie_httponly = On' 也可以使用函数'ini_set("session.cookie_httponly", 1)'。要注意的是函数'ini_set'必须放在'session_start'函数前面，因为'session_start'函数执行的同时 'PHPSESSID'就设置好了。
> 'setcookie'和'setrawcookie'的区别是前者会对数据进行url编码，后者存储原始数据。
> 'ini_set'函数不能用在php5.2以前的版本。
在文件'include.php'中10行添加下列代码：
ini_set("session.cookie_httponly", 1)
▪然后将所有 'cookie'函数的第七个参数设置成 'true'，例如 'setcookie("adminId", $id, time()+7*24*3600, null, null, null, true);'。
▪删除所有cookie，再次登录后尝试用js获取cookie，发现已经无法通过js获取cookie了。
来源 | 刘正波
西柚网安
扫描二维码并关注
网安知识一网打尽
原文始发于微信公众号（西柚网安）：AKun Wallpaper 代码审计——实战分析（四）
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论