图片来源网络
在程序员的世界里有一句经典的至理名言：永远不要相信用户的输入。相信很多开发者都有过类似的踩坑经历，所谓“幸福的人都是相似的，而编程的人是幸福的”。
初入职时，作为一名后端工程师，每次实现接口后，老大(我的组长)都会过来帮我瞄一眼，然后提出一堆改进意见，其中最常被提到的一点就是：永远不要相信用户的输入。我不以为意，没怎么去改相关逻辑，这么做的后果就是老大下次再帮我检查时，总会伴随一阵悦耳的争辩声。
Round 1
你这里为什么不加个类型检查？万一接收到的值不是数组怎么办？
怎么会呢，这些接口类型都是和前端定好的呀。
前端传入的数据是可以被篡改的，万一有人模拟了一个前端请求，发送一个其他类型的变量，那你的程序不就炸了？
那样的话程序会返回服务器异常，攻击者也不会得到什么有用的信息吧...
是没什么损失，但为什么要给别人留下这么个漏洞呢？
哦哦...
Round 2
这个接口传入的是图片对吧，为什么不检查下图片的大小？
这个，前端已经检查过了，太大的图片前端会先进行压缩的。
不是和你说过了吗，永远不要相信前端的输入！万一有攻击者模拟前端接口发来很大的图片呢？
额，不是还有nginx可以挡一道吗？太大的图片应该直接无法响应吧。
nginx的确能做这个，但这些也是需要配置参数的，万一不小心参数设太大了没发现怎么办？
哦，那就只能接收并保存下来了，不过我们的图片不都放在s3上吗，大一点也没什么关系吧，存储也挺便宜的...
你太天真了！首先，s3也是要花钱的，虽然空间不贵，但流量贵啊，万一真被人发现这个漏洞，他们完全可以把大量的图片通过你这里上传，然后根据返回值里的图片链接去获取。甚至如果有不怀好意的人传了些不该传的东西上去，那咱说不定都要去局里坐坐，这可不是开玩笑。
Game Over
这下我算彻底服了，只好满口答应，然后老老实实把该补的补上。嘴上虽这么说，但心里难免还有点疙瘩，这些都是特殊情况嘛，哪有那么容易就发生。事情总是这样，只要还没在自己身上发生，就会抱有侥幸心理，认为它一定不会发生，等到真的发生了，又来责怪自己当初怎么那么不小心。笔者就有过这么个经历，虽没犯下什么大错，但也足够长点记性了。
话说最近在做微信公众号开发，某天PM(产品经理)姐姐拿着个新需求过来，说是要加一个批量导入历史用户的功能，我扫了一眼开发文档，在用户管理文档中找到了获取用户基本信息这一项，心想不正是这个接口么，于是自信地回了句：“明天下班前给你”，转头就热火朝天地敲起了键盘。
整个流程比较清晰，先通过接口调用凭据access_token获取用户的openid列表，再调用获取用户基本信息接口来得到用户的昵称等信息，再将获取到的信息存到数据库即可。不过，作为一个严谨的开发，当然不能这么草率，还要考虑下效率和安全的问题。微信公众号里的用户动不动就上万，要一个个去获取基本信息那绝对是不妥当的，这一点微信团队的大佬们当然也想到了，所以提供了一个批量获取微信用户信息的接口，甚是方便。
另外，将数据存储到数据库时，当然也不能一条条地存入，这样一不小心得把数据库整挂了。应该在程序里构造sql语句，累计到一定的用户量之后再以批量的方式插入，这样不仅减少了操作数据库的次数，而且直接执行sql语句的方式也更加高效。
考虑完这两点后，就开始敲代码了。手指翻飞间，几个接口函数已经基本完成，打开编译器，一路绿灯，又麻利地打开本地的前端服务，准备开始调试。点击导入历史用户按钮，后端收到请求，调试器里查看，微信正确地返回了用户列表，因为线下的环境只是个测试号，所以只有20人左右，继续点击下一步，用户信息也成功获取，下一步，sql语句执行成功，全部用户导入完毕，到数据库里一看，数据确实都存下来了，搞定！
接下来，就是将程序上线了。虽然只是个小功能，可一旦要上线都是需要找老大来的，毕竟万一线上的代码真出了问题这锅最后还得到他头上。于是我就跑去找来了他，他当然也知道我今天在开发这个功能，看我不到半天就完成了，还捎带夸了句：完成地挺快呵。我自然是轻扬起嘴角，淡淡地回了句：这活还蛮简单的。
然而，这种笑容很快就消失了，因为我看到坐在我电脑前的老大眉头紧缩，顿觉头顶乌云密布。果然，不到一会儿，就传来了老大的“盘问”。
你直接用sql语句来插入数据的？
嗯，感觉这样子更方便一点，效率也更快点。
这个想法是没错，但你这里有个问题啊，在构造sql语句的时候，要特别注意单引号的使用，你看你这里在每个变量的两边显式地加入了单引号，那要是变量的字符串里本身就包含单引号怎么办呢？
啊，变量的值怎么可能会有单引号啊，这一点我没想到诶。
怎么不可能？你这里的值是微信用户的信息对吧，万一哪个家伙无聊在昵称里加了个单引号呢，这完全是可能的，这种时候你的sql语句就会被这个单引号提前封闭，就会产生语法错误，也就无法正常地执行了。更要命的是，这个时候用户单引号后面的部分就成为了sql命令的一部分被执行了，万一来个drop database之类的，再加个单引号把原来的部分还原，那这就成了典型的注入攻击了。到时候你哭都来不及。
哇靠，原来还有这种操作啊，我如梦初醒，不觉后背发凉。之前听老大提起过在php时代著名的注入攻击的案例，没想到今天自己竟差点犯了这个错误，真是罪过。那该怎么解决呢？我向老大请教。
这个其实也挺简单，只要把可能存在的特殊字符给转义就行了，这样它们就不会变成sql的一部分被执行。
嗯，有道理。于是我就噼里啪啦改起来，不一会儿就把该转义的给转义了，老大看完微微点头，然后再次强调说，特别是涉及到数据库的操作时，一定要严格地检查用户的输入，考虑所有可能的情况，防止出现这样的问题。我毕恭毕敬地听着，点头如捣蒜。
不过事情还没完。老大紧接着又指出另一个问题：你在接收到微信服务器返回的用户信息列表时，有检查它的类型吗？
我有点疑惑，这个类型不是在微信的文档里写好的嘛，只能是JSON啊，难道这也需要检查吗？
老大貌似看出了我的疑虑，问到：万一用户的信息里确实有一些特殊的字符，没办法用JSON的方式传输呢？是不是需要先将JSON做个序列化再传输呢？而你没有判断返回值的类型，完全按照JSON的格式来处理，这样后面有可能会出错的。
我还是有点疑惑，不就是个昵称嘛，能有什么特别的字符呢？
老大看了看我，建议我现在去试下微信修改昵称的功能。这不看还真不知道，在改昵称的时候原来可以插入表情的啊，还不止是微信官方提供的表情，而是能添加自己私藏的任意表情，表情是海量的，而JSON能识别的字符集是有限的，这么一来也就自然会出现一些JSON无法识别的字符。
看到这，我算是相信了，于是又把类型检查给加上了，并且当接收到的类型是字符串时，对其进行了处理，消除了里面可能存在的非JSON字符。老大看了看我，这次算是露出了比较满意的表情。
最后，又检查了一遍，为了验证刚才老大的两个想法，我还特意加了一个记录日志的操作，看看接收到的信息到底都是些啥。确认无误后，老大把程序更新到了线上。两三分钟后，更新完成，我迫不及待地尝试了下这个新功能。说来您还真别不信，线上用户的公众号总共有两万多关注者，这些人里面居然真的有人在昵称里使用了单引号，而且这类人还不少，大概三四百人里就有一个。而且返回的用户信息列表居然真的不全是JSON格式的，而是有部分string格式的，将这些string解析后得到的JSON里面，确实包含了一些无法识别的字符。
我看着日志里的结果，又看了看微信公众平台的官方文档，再回头看看老大那挂着浅浅笑容的脸颊，不禁肃然起敬。一方面是觉得尽管诸如微信这样的官方文档也难免会有疏漏之处，不可一味地根据主观意向来判断。再者，则是对老大的远见卓识佩服之至。
我记得曾在知乎上看到过一个问题，大意是说
做一个优秀的程序员到底难在哪里？
答案里有一条是这么写的：
由于你是一个优秀的（或仅仅是经验丰富的）程序员，你可以看出项目代码里存在着的隐患。你选择防患于未然，修复这些问题，但由于问题并没有真的发生，你所做的一切，在不那么优秀的程序员同事的眼中（以及老大眼中），看起来并没有什么产出。
诚哉斯言。回想起先前的经历，要不是老大及时指出代码里可能存在的错误，那肯定是要出问题的，虽然这一次不一定导致什么严重的后果，但若问题不除，迟早要吃大亏。此时老大已经起身准备离开了，他还有一大堆的事情要忙呢。不过在临走前，他又一次嘱咐了我：永远不要相信用户的输入。
嗯，这次我是真的记住了。望着老大远去的背影，我在心里默念到。
大概，这就是我心目中优秀程序员该有的样子。
参考链接
网友评论