大家好，我是Z哥。
不知道大家有没有发现。如今，曝光某些知名公司信息泄露的事件频率越来越高。与之对应的，网络安全问题也越来越受到重视。
从百度指数摘录了两张图给大家分享下。
可以看到，对网络安全相关的信息和关注度在逐渐走高，特别是近几年的几次大型数据泄露等安全事件引起了不小的舆论轰动。
说实话，现在在企业做CTO风险还是蛮大的，万一所在的企业出现什么网络安全事件，CTO也得承担责任。
虽然说我们广大程序员们不用承担责任，但是一旦经你手发生的安全事件，你自然也会受到或多或少的牵连。
写这篇文章的时候正好想起一个段子，分享给大家图个乐：
这可能也是目前PHP的声音越来越小的原因之一吧。
其实排除一些特定框架中的特定安全问题，具有普遍性的安全问题也不少。其中最常见的就属以下几种，我觉得我们每一位程序员应该都要知道如何尽量避免这些常见问题的发生。
SQL注入应该是最多人知道的一个安全问题。原因是由于SQL语句的编写是通过字符串拼接进行的，包括参数。那么一旦用户输入的参数改变了整个语句的含义，执行SQL语句的结果就变得不可预期了。比如，
SELECT * FROM user WHERE id = ‘1 or 1 = ‘1’ 。加粗部分就是用户输入的内容。
如果上面的这段SQL语句被执行，用户信息就全部泄露了。
SQL注入还有很多变种，比如故意让语句执行报错之类，从错误信息中获取重要信息。
如何防范呢？只要避免SQL拼接，使用参数化的方式执行SQL即可。比如上面这个例子，如果@id参数的数据类型是int，那么「or 1=‘1」自然无法转换成int类型。
XSS最常出现在一些内容型站点上，因为他主要针对的是根据服务端数据动态渲染html的页面。
比如，当我在某个社区回复帖子的时候，故意输入了「楼主牛逼～</div><script>alert(250)</script>」。如果服务端没有做好相应的处理，直接把内容原封不动的存到了数据库，那么当帖子翻到我的回复所在的楼层，就会在显示“楼主牛逼”字样的同时出现一个提示“250”的弹窗。
当然，只是弹个窗没啥意思。如果脚本中获取用户本地的cookie信息上传到指定服务器，那么其他人就可以利用该用户的cookie登陆他的账号了，想想就有点后怕。
如何防范呢？要么就是过滤掉这种html标签，因为大多数场景纯文本就能满足。如果实在有富文本的需求，可以进行一次转义，作为字符来存储，避免将html标签直接保存下来。
另外，针对cookie可以设置一下httponly，这样的话js就无法获取cookie信息了。
CSRF就是利用浏览器的缓存以及网站的登陆状态记忆功能，通过恶意脚本向你刚访问过的网站发起请求，让网站误认为是你本人在操作。
比如，你刚访问过某银行网站，甚至正在另一个标签页里打开着这个银行网站。然后此时不小心点又开了一个钓鱼网站，页面里面的脚本发起向该银行网站的转帐请求，你的银行账户就莫名其妙少了一笔钱。（当然现在的银行网站都考虑了这个问题）
如何防范呢？作为网站的开发者，最简单的方式就是对referer做判断，看发起该请求的来源是否可信。当然更好的方式是给每一个正常登陆的用户分配一个token，用户发起的每次请求都对这个token做一下有效性验证。
「越权」顾名思义，就是超越应有的权限。比如，某个电商网站查看订单信息的url是http://www.dianshang.com/order/10001。这样的格式，如果我手动把url最后的数字修改成10002发起请求，如果服务端没有校验当前登陆人的信息，那么这个10002的订单信息就被越权获取了。
如何防范呢？主要有两点。
其实还有很多安全问题，比如支付漏洞（支付金额未校验）、上传攻击等等。但是处理起来的大体思路上和上面提到的这4个是类似的。
为了便于大家理解以及在编码时更具安全意识，我给大家提炼了一些思路。
如果这些还嫌多，记不住。那么脑子里记住一个词——「严进严出」。
好了，总结一下。
这篇呢，Z哥提醒广大程序员一定要在写代码的时候有安全意识。因为网络安全的重要性会随着互联网的进一步深入到我们的生活变得更加重要。
最常见的4种安全问题，你一定得知道如何应对。
对于其他的安全问题，只要时刻带着「严进严出」的思想去coding，相信也能杜绝掉大部分的隐患。
不知道你有经历过什么惊心动魄的网络安全事件吗？欢迎在评论区分享你的经验给大家哦。
京公网安备 11010802035086号