网络安全逐渐成为程序员的必备技能

不知道大家有没有发现。如今，曝光某些知名公司信息泄露的事件频率越来越高。与之对应的，网络安全问题也越来越受到重视。

从百度指数摘录了两张图给大家分享下

可以看到，对网络安全相关的信息和关注度在逐渐走高，特别是近几年的几次大型数据泄露等安全事件引起了不小的舆论轰动。

其实排除一些特定框架中的特定安全问题，具有普遍性的安全问题也不少。其中最常见的就属以下几种，我觉得我们每一位程序员应该都要知道如何尽量避免这些常见问题的发生。

1.SQL 注入

2.跨站脚本攻击（XSS）

3.跨站请求伪造（CSRF）

4.越权漏洞

1. SQL 注入

SQL 注入应该是最多人知道的一个安全问题。原因是由于 SQL 语句的编写是通过字符串拼接进行的，包括参数。那么一旦用户输入的参数改变了整个语句的含义，执行 SQL 语句的结果就变得不可预期了。比如，

· 

SELECT * FROM user WHERE id = ‘1 or 1 = ‘1’ 。加粗部分就是用户输入的内容。

如果上面的这段 SQL 语句被执行，用户信息就全部泄露了。

SQL 注入还有很多变种，比如故意让语句执行报错之类，从错误信息中获取重要信息。

如何防范呢？只要避免 SQL 拼接，使用参数化的方式执行 SQL 即可。比如上面这个例子，如果 @id 参数的数据类型是 int，那么「or 1=‘1」自然无法转换成 int 类型。

 2. 跨站脚本攻击（XSS）

XSS 最常出现在一些内容型站点上，因为他主要针对的是根据服务端数据动态渲染 html 的页面。

比如，当我在某个社区回复帖子的时候，故意输入了「楼主牛逼～</div><script>alert(250)</script>」。如果服务端没有做好相应的处理，直接把内容原封不动的存到了数据库，那么当帖子翻到我的回复所在的楼层，就会在显示“楼主牛逼”字样的同时出现一个提示“250”的弹窗。

当然，只是弹个窗没啥意思。如果脚本中获取用户本地的 cookie 信息上传到指定服务器，那么其他人就可以利用该用户的 cookie 登陆他的账号了，想想就有点后怕。

如何防范呢？要么就是过滤掉这种 html 标签，因为大多数场景纯文本就能满足。如果实在有富文本的需求，可以进行一次转义，作为字符来存储，避免将 html 标签直接保存下来。

3. 跨站请求伪造（CSRF）

CSRF 就是利用浏览器的缓存以及网站的登陆状态记忆功能，通过恶意脚本向你刚访问过的网站发起请求，让网站误认为是你本人在操作。

比如，你刚访问过某银行网站，甚至正在另一个标签页里打开着这个银行网站。然后此时不小心点又开了一个钓鱼网站，页面里面的脚本发起向该银行网站的转帐请求，你的银行账户就莫名其妙少了一笔钱。（当然现在的银行网站都考虑了这个问题）

如何防范呢？作为网站的开发者，最简单的方式就是对 referer 做判断，看发起该请求的来源是否可信。当然更好的方式是给每一个正常登陆的用户分配一个 token，用户发起的每次请求都对这个 token 做一下有效性验证。

4. 越权漏洞

「越权」顾名思义，就是超越应有的权限。比如，某个电商网站查看订单信息的 url 是http://www.dianshang.com/order/10001。这样的格式，如果我手动把 url 最后的数字修改成 10002 发起请求，如果服务端没有校验当前登陆人的信息，那么这个 10002 的订单信息就被越权获取了。

如何防范呢？主要有两点。

做好权限校验，不要偷懒。

编号或者 id 类的数据，避免顺序增加。还有一个额外的好处是，避免竞争对手猜到你们的真实订单数。

其实还有很多安全问题，比如支付漏洞（支付金额未校验）、上传攻击等等。但是处理起来的大体思路上和上面提到的这 4 个是类似的。

为了便于大家理解以及在编码时更具安全意识，我给大家提炼了一些思路。

只要是外部输入的数据，一定要做好全面的校验，确保处理并返回的数据是符合预期的。

代码的实现尽量减少多余的外部交互。

错误处理的时候，一定不要将技术层面的异常信息抛出到用户端，特别是堆栈信息。

如果这些还嫌多，记不住。那么脑子里记住一个词——「严进严出」。

扫描下方二维码免费领取 10G 渗透课程+资料  先到先得哦!!!!