AKun Wallpaper 代码审计实战分析4
前言
在上一篇文章中重点分析了SQL注入漏洞以及介绍了其修复方案，但是给出的修复方案并没有完全修复SQL注入漏洞。接下来将详细分析未完全修复的SQL注入漏洞的绕过方案和修复方法。
AKun Wallpaper 代码审计实战分析1：https://blog.csdn.net/rpsate/article/details/122354690
AKun Wallpaper 代码审计实战分析2：https://blog.csdn.net/rpsate/article/details/122387998
AKun Wallpaper 代码审计实战分析3：https://blog.csdn.net/rpsate/article/details/122400520
漏洞分析1（上一期未完全修复的SQL注入漏洞）
审计过程
看到 lib/mysql.func.php第28行，其中 $table虽然是可变参数，但是其数据不是用户传递得到的，所以该变量安全。但是 $key是用户传递过来的，它来自$_POST数组中的键，所以该变量用户可控。再注意观察，$key两旁并没有用引，所以这条SQL语句并不需要引号就可以闭合，那么 mysql_real_escape_string函数在此处也就没有作用了。
漏洞复现
只要将payload稍作修改，并将payload写在键值对的 键中，而不是值中即可绕过转义函数的限制。如下图所示，发送请求5s后才收到响应包，这说明 sleep(5)函数执行成功，存在SQL注入漏洞。
payload：
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了。
