跨站脚本漏洞XSS

一、XSS跨站脚本基础

1、XSS漏洞介绍

跨站脚本攻击(Cross Site Scripting),为了不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆,故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意Script代码,当用户浏览该页之时,嵌入其中Web里面的Script代码会被执行,从而达到恶意攻击用户的目的。

2、XSS漏洞原理

形成XSS漏洞的主要原因是程序对输入和输出的控制不够严格,导致“精心构造”的脚本输入后,在输到前端时被浏览器当作有效代码解析执行从而产生危害。

3、XSS会造成危害

攻击者通过Web应用程序发送恶意代码,一般以浏览器脚本的形式发送给不同的终端用户。当一个Web程序的用户输入点没有进行校验和编码,将很容易的导致XSS。

1、网络钓鱼,包括获取各类用户账号
2、窃取用户cookies资料,从而获取用户隐私信息,或利用用户身份进一步对网站执行操作;
3、劫持用户(浏览器)会话,从而执行任意操作,例如非法转账、强制发表日志、电子邮件等
4、强制弹出广告页面、刷流量等
5、网页挂马;
6、进行恶意操作,如任意篡改页面信息、删除文章等
7、进行大量的客户端攻击,如ddos等
8、获取客户端信息,如用户的浏览历史、真实p、开放端口等
9、控制受害者机器向其他网站发起攻击;
10、结合其他漏洞,如csrf,实施进步危害;
11、提升用户权限,包括进一步渗透网站
12、传播跨站脚本蠕虫等

4、XSS的防御

形成XSS漏洞的主要原因是程序对输入和输出的控制不够严格,导致“精心构造”的脚本输入后,在输到前端时被浏览器当作有效代码解析执行从而产生危害。

因此在XSS漏洞的防范上,一般会采用“对输入进行过滤”和“输出进行转义”的方式进行处理: 输入过滤:对输入进行过滤,不允许可能导致XSS攻击的字符输入; 输出转义:根据输出点的位置对输出到前端的内容进行适当转义;

5、XSS常见出现的地方

1、数据交互的地方

get、post、cookies、headers

反馈与浏览

富文本编辑器

各类标签插入和自定义

2、数据输出的地方

用户资料

关键词、标签、说明

文件上传

6、XSS跨站脚本分类

6.1、反射型XSS

反射型XSS又称非持久性XSS,这种攻击往往具有一次性。 攻击者通过邮件等形式将包含XSS代码的链接发送给正常用户,当用户点击时,服务器接受该用户的请求并进行处理,然后把带有XSS的代码发送给用户。用户浏览器解析执行代码,触发XSS漏洞。

常见注入点:
网站的搜索栏、用户登录入口、输入表单等地方,常用来窃取客户端cookies或钓鱼欺骗.
例如:

当用户访问  url?uname=时,触发代码,弹出对话框。
6.2、存储型XSS

存储型XSS( Stored xss Attacks),也是持久型XSS,比反射型XSS更具有威胁性。攻击脚本将被永久的存放在目标服务器的数据库或文件中。这是利用起来最方便的跨站类型,跨站代码存储于服务端(比如数据库中)。

攻击者在发帖或留言的过程中,将恶意脚本连同正常信息一起注入到发布内容中。随着发布内容被服务器存储下来,恶意脚本也将永久的存放到服务器的后端存储器中。当其他用户浏览这个被注入了恶意脚本的帖子时,恶意脚本就会在用户的浏览器中得到执行。

常见注入点
论坛、博客、留言板、网站的留言、评论、日志等交互处。
6.3、DOM型XSS

DoM是文档对象模型( Document Object Model)的缩写。它是HTML文档的对象表示,同时也是外部内容(例如 JavaScript)与HTML元素之间的接口。解析树的根节点是“Document"对象。DOM( Document object model),使用DOM能够使程序和脚本能够动态访问和更新文档的内容、结构和样式。

它是基于DoM文档对象的一种漏洞,并且DOM型XSS是基于JS上的,并不需要与服务器进行交互。

其通过修改页面DOM节点数据信息而形成的ⅩSS跨站脚本攻击。不同于反射型XSS和存储型XSS,基于DOM的XSS跨站脚本攻击往往需要针对具体的 Javascript DOM代码进行分析,并根据实际情况进行XSS跨站脚本攻击的利用。

一种基于DOM的跨站,这是客户端脚本本身解析不正确导致的安全问题

用户请求一个经过专门设计的URL,它由攻击者提供,而且其中包含XSS代码。服务器的响应不会以任何形式包含攻击者的脚本,当用户的浏览器处理这个响应时,DOM对象就会处理XSS代码,导致存在XSS漏洞。

注入点
通过js脚本对对文档对象进行编辑,从而修改页面的元素。也就是说,客户端的脚本程序可以DOM动态修改页面的内容,从客户端获取DOM中的数据并在本地执行。由于DOM是在客户端修改节点的,所 
以基于DOM型的XSS漏洞不需要与服务器端交互,它只发生在客户端处理数据的阶段。
6.4、MXSS

不论是服务器端或客户端的ⅩSS过滤器,都认定过滤后的HTM源代码应该与浏览器所渲染后的HTML代码保持一致,至少不会出现很大的出入

然而,如果用户所提供的富文本内容通过 Javascript 代码进属性后,一些意外的变化会使得这个认定不再成立:一串看似没有任何危害的HTML代码,将逃过XSS过滤器的检测,最终进入某个DOM节点中,浏览器的渲染引擎会将本来没有任何危害的HTML代码渲染成具有潜在危险的XSS攻击代码。 随后,该段攻击代码,可能会被JS代码中的其它一些流程输出到DOM中或是其它方式被再次渲染,从而导致XSS的执行。这种由于HTML内容进后发生意外变化( mutation,突变,来自遗传学的一个单词,大家都知道的基因突变,gene mutation),而最终导致XS的攻击流程,被称为突变XSS(mXSs, Mutation based Cross-Site-Scripting

通常通过innerHTML函数进行html代码过滤

UXSS是一种利用浏览器或者浏览器扩展漏洞来制造产生XSS的条件并执行代码的一种攻击类型。

7、编码转义介绍

7.1、URL编码

考虑到安全传输问题,防止url字符丢失,所以选用了相对较小的、通用的安全字母表。希望url是完整的,有时候需要url中包含除去通用安全字母表之外的二进制数据和字符(比如中文)。所以url引入了一种转义机制,将不安全的字符编码为安全字符再进行传输。

百分号编码:url编码包含一个百分号(%),后面跟着两个表示字符ASCII码的十六进制数。例如:空格转为“%20”。

7.2、html编码

一些保留字符出现在文本节点和标签值里是不安全的。比如“<>”会导致浏览器误认为标签。如果想要正确的显示这些字符,需要使用html编码。

实体编码:一般以“&”开头,“;”结尾,可以不加“;”。如:“<”转为“<”

进制编码:以“&#”开头,加上字符的数值,“;”结尾,可以不加“;”。字符的数值可以是任意十进制ascii码或Unicode字符编码。十六进制的数值需要在编码数字前加“x”。如:“<”转为十进制的“<”或十六进制的“<”。

7.3、javascript编码

数字形式:\u后面加4位16进制数字(或\x后加2位16进制数字),按字符的uncode数值编码,不足位数以零填充。如:“<”转为“\u003c”或“\x3c”。其中“\u”开头的Unicode转义方式可以用在字符串之外的位置,其他的不可以。

jsfuck : http://www.jsfuck.com/

二、常见标签&事件

1、标签

利用方式1



imgSTYLE=“background-image:url(javascript:alert(‘XSS’))”

XSS利用方式2



XSS利用方式3


2、标签

标准格式

baidu

XSS利用方式1

aa
aa
aa

XSS利用方式2


利用方式3

aa

利用方式4

aa

3、input标签

标准格式


利用方式1


利用方式2


利用方式4


4、
标签

XSS利用方式1



XSS利用方式2




XSS利用方式3


alert('xss')">



5、


6、svg<>标签

SVG 意为可缩放矢量图形(Scalable Vector Graphics)。 SVG 使用 XML 格式定义图像。 SVG 文件可通过以下标签嵌入 HTML 文档:、 或者 。 也可以使用svg标签插入。



">%0a 

7、HTML 事件

在现代浏览器中都内置有大量的事件处理器。这些处理器会监视特定的条件或用户行为,例如鼠标单击或浏览器窗口中完成加载某个图像。通过使用客户端的 JavaScript,可以将某些特定的事件处理器作为属性添加给特定的标签,并可以在事件发生时执行一个或多个 JavaScript 命令或函数。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aZ7Eu6ul-1647919684179)(C:\Users\23850\AppData\Local\Temp\YinxiangBiji_2385016231esymv#app.yinxiang.com_2021-02-02.bmp)]

三、session与cookie

session

由于HTTP协议是无状态的协议,所以服务端需要记录用户的状态时,就需要用某种机制来识具体的用户,这个机制就是 Session

典型的场景比如购物车,当你点击下单按钮时,由于HTTP协议无状态,所以并不知道是哪个用户操作的,所以服务端要为特定的用户创建了特定的 Session,用用于标识这个用户,并且跟踪用户,这样才知道购物车里面有几本书。

这个 Session是保存在服务端的,有一个唯一标识。在服务端保存 Session的方法很多,内存、数据库、文件都有。集群的时候也要考虑 Session的转移,在大型的网站一般会有专门的 Session服务器集群,用来保存用户会话,这个时候 Session信息都是放在内存的,使用一些缓存服务比如 Memcached之类的来放 Session。

cookie

思考一下服务端如何识别特定的客户?这个时候 Cookie就登场了。

每次HTTP请求的时候,客户端都会发送相应的Cookie信息到服务端。实际上大多数的应用都是用 Cookie来实现 Session跟踪的,第一次创建 Session的时候,服务端会在HTTP协议中告诉客户端,需要在Cookie里面记录个SessionID,以后每次请求把这个会话ID发送到服务器,我就知道你是谁了。

设想你某次登陆过一个网站,只需要登录一次就可以在一定时间内浏览这个网站的所有内容,这是如何做到的?也是 Cookie

Cookie是指某些网站为了辨别用户身份而储存在客户端上的数据(通常经过加密)。也就是说,只要有了某个用户的 cookie,就能以他的身份登录

获取cookie:

浏览器(客户端):document.cookie

服务器端(php):$_COOKIE

四、攻击&绕过

1、XSS盗取cookie

存在反射型XSS漏洞的站点位置 可以利用以下链接来盗取Cookie

url?uname=

将连接发送到用户,用户点击即触发XSS漏洞。同时可以使用URL编码迷惑用户。

cookie.php代码:


http://127.0.0.1/dvwa/vulnerabilities/xss_r/?name=#

打开Cookie.txt文件,找到Cookie值,访问目标站点,修改Cookie为Cookie.txt文件中的内容。会话劫持。

2、XSS篡改网页链接

攻击JS代码介绍

window.onload 当窗口加载时,执行匿名函数。 使用for循环遍历所有获得的链接a标签。


将篡改代码注入到对应的XSS位置。篡改链接指向流量URL或恶意URL

3、XSS盗取用户信息

克隆网站登陆页面,利用存储XSS设置跳转代码,如果用户访问即跳转到克隆网站的登陆页面,用户输入登陆,账号和密码被存储。

setookit
1)Social-Engineering Attacks->2)Website Attack Vectors->3)->2)
使用kali IP地址
克隆站点的url
xss payload: 

4、没有过滤的XSS

探测XSS过程

1、构造一个独一无二且不会被识别为恶意代码的字符串用来提交到页面。 例如:123qweasdzxc

2、使用浏览器审查工具进行代码审查,寻找构造的字符串是否在页面中显示。

闭合标签利用XSS或在属性中的XSS闭合引入事件

5、限制输入长度的XSS

HTML 表单用于搜集不同类型的用户输入。表单元素指的是不同类型的 input 元素、复选框、单选按钮、提交按钮等等。text定义常规文本输入。

属性介绍:
value 属性规定输入字段的初始值
readonly 属性规定输入字段为只读(不能修改) 
disabled 属性规定输入字段是禁用的。被禁用的元素是不可用和不可点击的。被禁用的元素不会被提交。 size 属性规定输入字段的尺寸(以字符计) 
maxlength 属性规定输入字段允许的最大长度 
如设置 maxlength 属性,则输入控件不会接受超过所允许数的字符。 该属性不会提供任何反馈。如果需要提醒用户,则必须编写 JavaScript 代码

需要构造长度合适的Payload触发XSS漏洞

6、Javascript伪协议的XSS

javascript伪协议介绍

将javascript代码添加到客户端的方法是把它放置在伪协议说明符javascript:后的URL中。这个特殊的协议类型声明了URL的主体是任意的javascript代码,它由javascript的解释器运行。如果javascript:URL中的javascript代码含有多个语句,必须使用分号将这些语句分隔开。

javascript:var now = new Date(); "

The time is:

" + now;

javascript URL还可以含有只执行动作,但不返回值的javascript语句。javascript:alert(“hello world!”)

Payload: javascript:alert(document.domain)

7、绕过过滤domain为空的XSS

构造Payload: “> 

发现domain被过滤为空

思考绕过策略:

  • 双写绕过
  • 编码绕过
双写绕过
Payload: “> 
编码绕过
Payload: ">

8、绕过替换script和on事件的XSS

构造Payload: “> 

发现script被过滤为空

思考绕过策略:

  • 伪协议绕过
  • 空格绕过
伪协议绕过
Payload: “> xss  失败
空格绕过
Payload: ">xss">

9、利用IE特性绕过XSS过滤

IE特性讲解

IE中  两个反引号 `` 可以闭合一个左边双引号。
Payload: `` onmousemove=alert(document.domain)

10、利用CSS特性绕过XSS过滤

CSS特性讲解

background:url("javascript:alert(document.domain);");  设置背景颜色
设置background:url ,利用javascript伪协议执行js。   
目前IE浏览器支持,其他浏览器已经不再支持。
Payload: background-color:#f00;background:url("javascript:alert(document.domain);");

11、IE中利用CSS触发XSS

CSS中执行js

css expression(css表达式)又称Dynamic properties(动态属性)是早期微软DHTML的产物,以其可以在Css中定义表达式(公式)来达到建立元素间属性之间的联系等作用。

注释绕过关键字过滤

CSS中的注释 /**/
绕过对关键字expression的过滤。 ex/**/pression
Payload: xss:expres/**/sion(if(!window.x){alert(document.domain);window.x=1;})

12、16进制绕过过滤触发XSS

使用python将字符转换为16进制类型。

import binascii
print("\\x"+binascii.b2a_hex(s))
\x61    js可以识别的16进制
print("\\x"+binascii.b2a_hex("<"))

双斜杠+16进制绕过

Payload: \\x3cscript\\x3ealert(document.domain);\\x3c/script\\x3e

13、unicode绕过过滤触发XSS

使用python将字符转换为unicode类型

import binascii
print("\\u00"+binascii.b2a hex("<"))
\u003c

双斜杠+unicode绕过

Payload: \\u003cscript\\u003ealert(document.domain);\\u003c/script\\u003e

14、浏览器同源策略介绍

14.1、源的含义

源指源头,信息来源的位置。在计算机中源在RFC6454文档中规定,源是由协议、主机名、端口名组成

范例:  协议://主机名:端口号/
例如:http://www.example.com  与  https://www.example.com  不是同源。

14.2、同源策略

在计算机中,同源策略(Same-origin Policy , SOP)用于阻止一个非同源的页面恶意代码去访问另外一个非同源页面。

只有两个页面属于同一个源才能互相访问。不同源的客户端脚本在没有明确授权的情况下,不能读写对方资源。所以a.com下的js脚本采用ajax读取b.com里面的文件数据是会报错的。

例如:源A页面要访问源B页面认证Cookie,如果不加阻止读取Cookie,会造成Cookie欺骗绕过登陆验证。注意:同源一定要是 协议、主机名、端口号完全一致。

14.3、IE源的特殊处理

1、位于可信域(Trust Zones)的互信的域名间,不受同源策略限制。

2、IE在判断同源时不考虑端口。

可是通过document.domain 读取或修改源。但是有限制,修改之后的源不能通过其他脚本再次修改。

14.4、document.domain

该属性可以解决因同源安全策略带来的不同文档的属性共享问题。降域 document.domain同源策略认为域和子域属于不同的域,如:

child1.a.com 与 a.com,
child1.a.com 与 child2.a.com,
xxx.child1.a.com 与 child1.a.com

两两不同源,可以通过设置 document.damain=‘a.com’,浏览器就会认为它们都是同一个源。想要实现以上任意两个页面之间的通信,两个页面必须都设置documen.damain=‘a.com’。



The domain name for this document is:



14.5、跨域

浏览器中,< script>//< iframe>/等标签都是可以跨域来加载资源的而不受同源策略的影响。带″src′属性的标签每次加载时,实际上都是浏览器发起次”GET”请求。

    
                    
                    

你可能感兴趣的:(Web安全,web安全)