zoukankan      html  css  js  c++  java
  • XSS跨站脚本攻击

    基本概念&原理

    XSS(又称CSS)攻击是一种经常出现在web应用中的计算机安全漏洞,恶意攻击者往Web应用页面里插入恶意html代码,当用户浏览该页面时,嵌入在Web里面的html代码会被执行,从而达到恶意用户的特殊目的。如,盗取用户Cookie、破坏页面结构、重定向到其它网站等。

    XSS攻击类似于SQL注入攻击,SQL注入攻击中以SQL语句作为用户输入,从而达到查询/修改/删除数据的目的,而在xss攻击中,通过插入恶意脚本,实现对用户游览器的控制,获取用户的一些信息。攻击之前,我们先找到一个存在XSS漏洞的网站,XSS漏洞分为两种,一种是DOM Based XSS漏洞,另一种是Stored XSS漏洞。理论上,所有可输入的地方没有对输入数据进行处理的话,都会存在XSS漏洞,漏洞的危害取决于攻击代码的威力,攻击代码也不局限于script。

    XSS攻击的危害包括
    1、盗取各类用户帐号,如机器登录帐号、用户网银帐号、各类管理员帐号
    2、控制企业数据,包括读取、篡改、添加、删除企业敏感数据的能力
    3、盗窃企业重要的具有商业价值的资料
    4、非法转账
    5、强制发送电子邮件
    6、网站挂马
    7、控制受害者机器向其它网站发起攻击


    XSS漏洞的分类
    按照攻击原理分为三种类型:

    • DOM的XSS是XSS的一种形式,其中从源到接收的整个受污染的数据流在浏览器中发生,即数据的来源是在DOM中,接收器也在DOM中,数据流永远不会离开浏览器。例如,源(读取恶意数据)可以是该页面的URL(例如,document.location.href),或者它可以是HTML的元素,并且接收器是一个敏感的方法调用,导致执行恶意数据(例如,文件撰写document.write)的执行。如果用户的输入被用于修改原有HTML的DOM内容,就会引入这一类攻击。 其攻击过程如下所示:
      • Alice给Bob发送一个恶意构造了Web的URL。
      • Bob点击查看这个URL,并在这个页面中输入了一些数据。
      • 恶意页面中的JavaScript打开一个具有漏洞的HTML页面并将其安装在Bob电脑上。
      • 具有漏洞的HTML页面包含了在Bob电脑本地域执行的JavaScript。
      • Alice的恶意脚本可以在Bob的电脑上执行Bob所持有的权限下的命令。

    典型的一个栗子:输入的内容用于作为某个节点的innerHTML,如果不对输入作验证,则会被注入攻击代码。 

        如下的一段脚本注入后,就会获取用户的Cookie
        <script language=”javascript”>
              var cockieInfo =window.cockie;
              //send cockieInfo to luminji
        </javascript>

    反射型XSS(非持久或II型XSS),发生条件:当攻击者在单个HTTP响应中注入浏览器可执行代码时发生。注入攻击不是存储在应用程序中; 只影响打开这个恶意制作的链接或第三方网页的受害者用户,非持久性的攻击。攻击载体被包括作为特制URI或HTTP参数,由应用程序不正确地处理的一部分,并返回到受害者。当用户被诱骗点击一个恶意链接,提交特制的形式,或者甚至只是浏览到恶意网站,注入的代码就传播到脆弱的网站,这反映攻击回到了用户的浏览器。然后浏览器执行的代码,因为它从一个“可信”的服务器来,不同的是Web客户端使用Server端脚本生成页面为用户提供数据时,如果未经验证的用户数据被包含在页面中而未经HTML实体编码,客户端代码便能够注入到动态页面中。将用户输入“反射”回浏览器,即将用户的输入变成HTML传输回客户端。其攻击过程如下:

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

    典型的一个栗子: Response.Write(“<script>alert(/xss/);</script>”)

    存储型XSS(持久性或I型XSS),攻击者将攻击脚本永久保存在目标服务器上,比如数据库中、消息论坛、访问者日志、评论栏等。使得所有访问该页面的用户都面临信息泄漏的可能,其中也包括了Web服务器的管理员。它把攻击脚本放置在服务器端,一旦被注入,可被多人多次利用。如,发表博文,就可以引入存储性的XSS。其攻击过程如下:

      • Bob拥有一个Web站点,该站点允许用户发布信息/浏览已发布的信息。
      • Charly注意到Bob的站点具有类型C的XSS漏洞。
      • Charly发布一个热点信息,吸引其它用户纷纷阅读。
      • Bob或者是任何的其他人如Alice浏览该信息,其会话cookies或者其它信息将被Charly盗走。
      • 类型A直接威胁用户个体,而类型B和类型C所威胁的对象都是企业级Web应用。

     

    标准XSS

    基于DOM的XSS

    根本原因

    在HTML出站页面中不安全地嵌入客户端输入

    不安全的引用和使用(在客户端代码中)DOM对象,这些对象不完全由服务器提供的页面控制

    所有者

    Web开发人员(CGI)

    Web开发人员(HTML)

    页面性质

    仅动态(CGI脚本)

    通常是静态的(HTML),但不一定。

    漏洞检测

    • 手动故障注入
    • 自动故障注入
    • 代码审查(需要访问页面的源代码)
    • 手动故障注入
    • 代码审查(可以远程进行!)

    攻击检测

    • Web服务器日志
    • 在线攻击检测工具(IDS,IPS,Web应用防火墙)

    如果逃避技术适用和使用 - 无法进行服务器端检测

    有效的防御

    • 在服务器端的数据验证
    • 攻击防范实用程序/工具(IPS,应用程序防火墙)
    • 在客户端的数据验证(在Javascript)
    • 使用备用服务器替代

     

    基于特征的防御
    XSS漏洞和著名的SQL注入漏洞一样,都是利用了Web页面的编写不完善,所以每一个漏洞所利用和针对的弱点都不尽相同。这就给XSS漏洞防御带来了困难:不可能以单一特征来概括所有XSS攻击。
    传统XSS防御多采用特征匹配方式,在所有提交的信息中都进行匹配检查。对于这种类型的XSS攻击,采用的模式匹配方法一般会需要对“javascript”这个关键字进行检索,一旦发现提交信息中包含“javascript”,就认定为XSS攻击。这种检测方法的缺陷显而易见:骇客可以通过插入字符或完全编码的方式躲避检测:
    躲避方法1)在javascript中加入多个tab键,得到
    1
    < IMG SRC="jav ascript:alert('XSS');" >;
     
    躲避方法2) 在javascript中加入(空格)字符,得到
    1
    < IMG SRC="javascri pt:alert('XSS');" >;
     
    躲避方法3) 在javascript中加入(回车)字符,得到
    1
    2
    < IMG SRC="jav
    ascript:alert('XSS');" >;
     
    躲避方法4)在javascript中的每个字符间加入回车换行符,得到
    1
    2
    < IMG SRC="javascrip
    t:alert('XSS');" >
     
    躲避方法5)对"javascript:alert('XSS')"采用完全编码,得到
    1
    < IMGSRC=javascrip?74:alert('XSS') >
    上述方法都可以很容易的躲避基于特征的检测。而除了会有大量的漏报外,基于特征的还存在大量的误报可能:在上面的例子中,对上述某网站这样一个地址,由于包含了关键字“javascript”,也将会触发报警。
     
     
    基于代码修改的防御
    和SQL注入防御一样,XSS攻击也是利用了Web页面的编写疏忽,所以还有一种方法就是从Web应用开发的角度来避免:
    步骤1、对所有用户提交内容进行可靠的输入验证,包括对URL、查询关键字、HTTP头、POST数据等,仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交,对其他的一律过滤。
    步骤2、实现Session标记(session tokens)、CAPTCHA系统或者HTTP引用头检查,以防功能被第三方网站所执行。
    步骤3、确认接收的的内容被妥善的规范化,仅包含最小的、安全的Tag(没有javascript),去掉任何对远程内容的引用(尤其是样式表和javascript),使用HTTP only的cookie。
    当然,如上操作将会降低Web业务系统的可用性,用户仅能输入少量的制定字符,人与系统间的交互被降到极致,仅适用于信息发布型站点。并且考虑到很少有Web编码人员受过正规的安全培训,很难做到完全避免页面中的XSS漏洞。
  • 相关阅读:
    抽象工厂模式
    python 工厂方法
    采用__call__ 实现装饰器模式
    策略模式
    采集15个代理IP网站,打造免费代理IP池
    grid网格布局——色子布局
    观察者模式
    搭建免费代理池---采集代理(1)
    python 爬虫 user-agent 生成
    多进程 + 多线程抓取博客园信息
  • 原文地址:https://www.cnblogs.com/hsmwlyl/p/10675045.html
Copyright © 2011-2022 走看看