最近做了一个小程序，用 nestJS 做的服务端，数据库是 MySQL 。然后被SQL注入攻击了，第一次遇到，感觉还很有意思，记录一下。
其实是微信平台做的模拟攻击，所以也并没有任何实际破坏，仅仅是数据库里被塞入了多条不符合预期的数据。
背景是微信小程序在提审的时候提示了这个：
“安全测试”，模拟用户发送请求。有点意思，虽然比较少接触服务端内容，但是对于一些常见的网络攻击手段也有一定了解。比如ssh弱密码爆破，struts2，log4j2，redis，pg漏洞利用之类的，一般以为只有使用一些大的系统时因为系统本身的漏洞比较容易被攻破，我这是手写的程序，出入参都有校验，数据库只准本机链接，还是比较自信应该没有问题。
点击同意后，后台的日志系统就看到了密密麻麻的请求，基本没有看到有报错，觉得还可以啊，一切正常。
然后就翻车了。在后台查看历史记录时发现40多条空白记录，进数据库一看就觉得不太对。
那就修问题吧，仔细想了想涉及到写这张表的接口，想了半天没头绪，那就查日志看看。应用是使用 NestJS 编写的，用 PM2 部署的。
PM2 的日志查询是用 pm2 log 进行查看，但是这个命令只能查看最近的日志和实时的日志，之前的日志在 .pm2/logs 目录下，通过scp命令下载下来。
读日志时候遇到一点小问题，里面有很多乱码一样的东西：
这个不是编码问题，而是终端控制字符，用来让日志在终端里有颜色，查了下说是可以安装VT100什么的插件解决，但是最终效果也不是很好，不影响阅读，就算了，也许有专门用于读日志的软件？
从日志里可以很明显看到微信的模拟攻击是如何注入数据库的：用户1676请求历史绘图列表第1" union select 1,2-- 页 ，是在分页查询中加入的，查看代码发现这里确实没做好，赶紧补上一个parseInt和isNaN判断。
这种模拟攻击检查还挺好的，能有效帮助个人开发者检查一些漏洞，不知道微信的实现原理是什么，是靠静态分析小程序代码里请求相关的逻辑？如果把请求发送从字符串变成变量的形式，岂不是可以规避微信的检查？