常见的Web安全防范

不是所有Web开发者都有安全的概念,特别是前端开发者基本上不太关心Web安全,认为那是后端开发者应该关注的。其实对于Web安全前后端没有必要分那么清。相对而言,前端代码很容易暴露客户端上,相对没那么安全,所以原则上是后端为主,前端为辅。

通常我们所说的Web安全问题有三个详解SQL注入、XSS攻击和CSRF攻击。

SQL注入

SQL 注入,顾名思义就是通过注入 SQL 命令来进行攻击,更确切地说攻击者把SQL命令插入到web表单或请求参数的查询字符串里面提交给服务器,从而让服务器执行编写的恶意的 SQL 命令。
对于web开发者来说,SQL注入已然是非常熟悉的,而且SQL注入已经生存了10多年,目前已经有很成熟的防范方法,所以目前的web应用都很少会存在漏洞允许进行SQL注入攻击。 除非是入门开发人员,在开发的时候仍使用旧的技术去实现(比如Java的Statement和 PreparedStatement)。

产生的原因

从上面可知,SQL注入是通过让服务器执行了恶意的SQL命令从而进行攻击的,那么主要问题就出在于服务器是如何生成SQL语句的。其实绝大多数拥有SQL注入漏洞的Web系统,在生成SQL语句的时候,采用的是拼接字符串的方式,并且没有对要组装成 SQL 语句的参数进行检验和过滤。

实例

看下面PHP代码:

$user = mysql_query('SELECT * FROM USERS WHERE UserName="'.$_GET['user'].'"');

那么当请求中 user 参数为 “;DROP TABLE USERS时,合成的SQL语句是:

SELECT * FROM USERS WHERE UserName="";DROP TABLE USERS"

这里产生什么结果就不需要解释了吧 🙂 另外,通过 SQL 注入,往往还能拿到系统权限。

如何防护

推荐所有SQL语句都使用参数化查询,通常使用成熟一些的后台框架都能避免这个问题。

XSS攻击

XSS,全名:cross-site scripting(跨站点脚本),是当前web应用中最危险和最普遍的漏洞之一。攻击者尝试注入恶意脚本代码到受信任的网站上执行恶意操作,用户使用浏览器浏览含有恶意脚本页面时,会执行该段恶意脚本,进而影它与SQL注入很类似,同样是通过注入恶意指令来进行攻击。但 SQL注入是在服务器端上执行的,而XSS攻击是在客户端上执行的,这点是他们本质区别。

分类

XSS 攻击的分类没有标准,但普遍分为三类:

  • 反射型XSS(非持久性跨站攻击)
  • 存储型XSS(持久性跨站攻击
  • DOM Based XSS(基于dom 的跨站点脚本攻击)

下面将直接以一些小例子来说明以上三种类别的 XSS 攻击分别是怎样的。

反射型XSS(非持久性跨站攻击)

一般是利用网站某些页面会直接输出请求参数的特性,通过在url的请求参数包含恶意脚本,导致用户打开该 url 的时候,执行恶意脚本。

其攻击过程如下:

用户A经常浏览某网站。用户A使用用户名/密码进行登录该站点,并存储敏感信息(比如银行帐户信息)。黑客B发现某站点包含反射性XSS漏洞,于是编写一个利用漏洞的URL,并将其冒充为来自某站点的邮件发送给A。
用户在登录到该信任站点后,浏览黑客B提供的URL。嵌入到URL中的恶意脚本在用户A的浏览器中执行,就像它直接来自信任站点的服务器一样。此脚本盗窃敏感信息(授权、信用卡、帐号信息等)然后在用户A完全不知情的情况下将这些信息发送到黑客B的Web站点。

存储型XSS(持久性跨站攻击)

该种类型的攻击一般是通过表单输入(比如发布文章、回复评论等功能中)插入一些恶意脚本,并且保存到数据库,待其他用户加载对应的页面的时候,该段脚本就会被加载并执行。

与反射型XSS 相比,该类的攻击更具有危害性,因为它影响的不只是一个用户,而是大量用户,而且该种类型还可进行蠕虫传播。其攻击过程如下:

某网站允许用户发布信息/浏览已发布的信息。黑客注意到该站点具有存储型XSS,于是发布一个热点信息,吸引其它用户纷纷阅读。某网站管理员或任何的其他用户浏览该信息,其会话cookies或者其它信息将被黑客盗走。

DOM Based XSS(基于 Dom 的跨站点脚本)

基于DOM的跨站点脚本与前面两种类型有什么区别呢?其实它注入的方式是基于前面两种类型的方式的,只不过是注入的脚本是通过改变DOM来实施的。采用该种方式有一个好处就是从源代码中不易被发现而已。

产生的原因

主要原因与 SQL 注入很类似,都是由于开发人员没有对用户输入进行编码和过滤。另一个原因是,这种攻击方法有很多变体,要设计出一个能完全防御的 XSS 过滤器是非常困难的。

如何防护

基于上面漏洞产生的原因,我们若要想防御该种攻击,就需要从源头抓起(用户输入),制定一套合理且安全的 XSS 过滤规则。

  • 对 HTML 标签及一些特殊符号进行转义

该种方法是一种非常简单的过滤方法,仅仅是通过转义的方式将一些HTML标签和属性转义,比如 < 转义成 &lt ;, 这样脚本就运行不了。当然简单的过滤方式也就代表很容易就会被绕过。

另外如果需要使用含有富文本的功能时,使用这样的过滤就会使富文本失去作用。

  • 使用白名单、黑名单的方式进行过滤

白名单、黑名单顾名思义是要定义哪些东西是可通过的,哪些东西不可通过。比如常见 <b>、<p>等等标签,不可通过的比如javascript、<a>、<script>、<iframe>、onload等等一些属性,将其进行转义。

当然使用该种方法也有自身的缺点,你并不可能穷举出所有元素,也可能会某些元素在黑名单内,但在某些情况它是需要使用的,这就需要我们在设计XSS过滤器的时候权衡好,取最合理最适合需求的设计。

XSS攻击作为Web业务的最大威胁之一,不仅危害Web业务本身,对访问Web业务的用户也会带来直接的影响,如何防范和阻止XSS攻击,保障Web站点的业务安全,是定位于业务威胁防御的入侵防御产品的本职工作。

CSRF攻击

CSRF,全名:Cross site Request Forgery(跨站域请求伪造)。尽管听起来像跨站脚本(XSS),但它与XSS非常不同,XSS利用站点信任用户,而CSRF则利用用户信任站点。与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少)和难以防范,所以被认为比XSS更具危险性。一般的攻击方式是,通过请求伪造盗取用户的cookie信息,进而进行操作。其攻击过程如下:

  • 首先用户A请求登陆了服务器B,这时服务器B响应了用户 A,并且会返回唯一标识的该用户的cookie信息。
  • 用户A在未退出服务器B时,访问了带有恶意脚本的服务器C,服务器C响应给用户A一个恶意页面,并且通过恶意脚本伪装用户A向服务器B发送请求,此时服务器B误以为是用户A请求,故响应并返回了用户A的cookie信息。
  • 服务器C收到用户A与 服务器B的cookie信息后,保存起来,并利用该信息伪装成用户A去访问服务器B,再进行相应的破坏。

产生的原因

其主要原因是服务B没有对请求的发起源进行合理的检验,即不加分析地认为请求者一定是正常的用户,就响应了用户信息给非法分子。

如何防护

  • 验证 HTTP Referer的值
  • 使用请求令牌

验证 HTTP Referer

熟悉HTTP协议的人都知道,HTTP 的头部 有一个Referer信息的字段,它记录着该次HTTP请求的来源地址(即它从哪里来的)。

既然CSRF攻击伪造的请求是从服务器C发送过来的,那么我们就禁止跨域访问,在服务器端增加过滤器的过滤,过滤掉那些不是从本服务器B发出的请求,这样可以在一定程度上避免CSRF攻击。

使用请求令牌

该种方式是参考同步令牌所设计的,同步令牌是用于防止表单重复提交的场景。

请求令牌的工作方式:

  1. 用户A访问服务器B
  2. 服务器B以某种随机生成策略生成随机字符串,并作为令牌(token)保存在session里面,然后夹带着响应返回给用户,并以隐藏域的形式保存在页面中
  3. 用户每次请求都会夹带着token反馈给服务器
  4. 服务器接收到每次请求,都会先进行令牌验证,若令牌验证不通过,则认为该次请求是非法的,拒绝响应。

由于CSRF是通过在服务器C上伪造请求的方式来访问服务器B,所以它是获取不了页面中的token字符串,所以在一定程度上是能防御的。

CSRF攻击是一种请求伪造的攻击方式,它利用的是服务器不能识别用户的类型从而盗取用户的信息来攻击。因此要防御该种攻击,因为从服务器端着手,增强服务器的识别能力,设计良好的防御机制。

发表评论

电子邮件地址不会被公开。 必填项已用*标注