Posts - 2963,
Articles - 0,
Comments - 54
21:05 by 沧海一滴, ... 阅读,
XSS（Cross Site Scripting），又称跨站脚本，XSS的重点不在于跨站点，而是在于脚本的执行。在WEB前端应用日益发展的今天，XSS漏洞尤其容易被开发人员忽视，最终可能造成对个人信息的泄漏。如今，仍然没有统一的方式来检测XSS漏洞，但是对于前端开发人员而言，仍是可以在某些细微处避免的，因此本文会结合笔者的学习和经验总结解决和避免的一些方案，并简要从webkit内核分析浏览器内核对于XSS避免所做的努力，了解底层基础设施对预防XSS所做的贡献。
XSS的种类和特点
此处不详细讲解XSS的一些细节
XSS的目标是让其他站点的js文件运行在目标站点的上，这主要发生在页面渲染阶段。在该阶段发生了某些非预期的脚本行为，该脚本可能来自用户的输入，也可能来自域外的其他js文件，不一而足。XSS的发生起源来自于用户输入，因此XSS根据用户输入数据以何种形式、何时触发XSS、是否有后端服务器的参与划分为三种类型，分别是反射型XSS、持久型XSS和DOM XSS。
反射型XSS，顾名思义在于&反射&这个一来一回的过程。反射型XSS的触发有后端的参与，而之所以触发XSS是因为后端解析用户在前端输入的带有XSS性质的脚本或者脚本的data URI编码，后端解析用户输入处理后返回给前端，由浏览器解析这段XSS脚本，触发XSS漏洞。因此如果要避免反射性XSS，则必须需要后端的协调，在后端解析前端的数据时首先做相关的字串检测和转义处理；同时前端同样也许针对用户的数据做excape转义，保证数据源的可靠性。
e.x.localhost/test.php
&?php echo $_GET['name'] ?&
如果通过 localhost/test.php?name=alert(document.cookie) 访问页面，那么经过后端服务器的处理，就会造成反射性XSS的发生。
同理，通过传入data uri编码的字符串也会导致XSS，如 localhost/test.php?name=&会导致同样的问题。该段编码的字串解码后是&alert(document.cookie)&。
持久型XSS仍然需要服务端的参与，它与反射型XSS的区别在于XSS代码是否持久化（硬盘，数据库）。反射型XSS过程中后端服务器仅仅将XSS代码保存在内存中，并为持久化，因此每次触发反射性XSS都需要由用户输入相关的XSS代码；而持久型XSS则仅仅首次输入相关的XSS代码，保存在数据库中，当下次从数据库中获取该数据时在前端未加字串检测和excape转码时，会造成XSS，而且由于该漏洞的隐蔽性和持久型的特点，在多人开发的大型应用和跨应用间的数据获取时造成的大范围的XSS漏洞，危害尤其大。这就需要开发人员培养良好的WEB前端安全意识，不仅仅不能相信用户的输入，也不能完全相信保存在数据库中的数据（即后端开发人员忽视的数据安全检测）。针对持久型XSS没有好的解决方式，只能由开发人员保证。当然规则是由开发者制定，如果忽略用户体验的话，可以制定一套严谨的输入规则，对相关关键词和输入类型（如data URI检测，禁止输入）的检测和禁止，尽可能规避用户发现XSS漏洞的可能性，从源头处理。
DOM XSS完全在前端浏览器触发，无需服务端的参与，因此这是前端开发工程师的&地盘&，理应获得我们的关注。
e.x.localhost/test.html
如果访问localhost/test.html#document.cookie ，那么就会触发最简单的危害非常大的DOM XSS。它完全没有服务端的参与，仅仅由用户的输入和不安全的脚本执行造成，当然在本例中仅仅是最简单的情况，如果用户输入字符串&&或者text/html格式的data URI，则更难检测，也危害更大，黑客操作起来更为容易。
因此预防DOM XSS，需要前端开发人员警惕用户所有的输入数据，做到数据的excape转义，同时尽可能少的直接输出HTML的内容；不用eval、new Function、setTimeout等较为hack的方式解析外站数据和执行js脚本；禁止内联事件处理函数；如果在考虑安全性的前提下需要获取外站脚本的执行结果，可以采用前端沙盒（建立空的iframe执行脚本，该iframe无法操作当前文档对象模型）、worker线程的方式完成，保证DOM的安全。
XSS漏洞难以检测，但是为了WEB安全仍需要尽力避免，在本节将会针对三种类型XSS漏洞提出对应解决方法，并从其他角度提供更具启发性的意见。
针对反射型XSS，在对应的小节中也提到过，需要服务端和前端共同预防，针对用户输入的数据做解析和转义，对于前端开发而言，则是善于使用escape，针对data URI内容做正则判断，禁止用户输入非显示信息，如MIME类型为&text/html，text/plain&类型的内容。对于存储型XSS，处理方式仍然类同于反射性XSS。对于DOM XSS，则需要慎之又慎。由于造成XSS的原因在于用户的输入，因此在前端，需要特别注意以下的用户输入源：
&document.URL,location.hash,location.research,document.referrer(此处应尤为注意，referrer属性虽然可用于避免CSRF，但可触发XSS攻击),XHR返回值（跨域返回值）,form表单及各种input框&
针对以上输入源，需要做相对于的检测和转义。在以上输入源中获取数据后，可能会有各种DOM操作或纯粹的js计算，这些操作则是真正触发XSS的罪魁祸首：
&1,直接输出HTML内容document.body.innerHTML = ...document.body.outterHTML = ...document.write()2,HTML标签内联脚本&img src='abc' onerror=alert('error')&3,直接执行脚本evalnew Function(){}setTimeout()window.execScript()4,打开新页面触发XSS（包括反射型XSS和持久型XSS）window.open()location.href = ...location.hash = ...&
在操作DOM时，需要尤其注意上述操作，针对可能造成的XSS需要进行字串转义。当然，有些操作是完全可以避免的：对于innerHTML的拼接操作，需要摒弃jQuery式的链式操作而使用前端模版如artTemplate，也可选择使用由后端渲染好的可靠的数据，这样既保证性能也确保安全；对于HTML标签内嵌js，则需要完全避免，这是一种容错率很低的实现；直接执行脚本和解析数据，则需避免eval和new Funciton等操作，改为JSON.parse、iframe沙盒和webWorker执行；而针对打开新页面触发的XSS则需要开发人员自行把控。
另外的尝试
上文提到的仅仅是对应的XSS避免方案，但是如果将目光放置在全局，站在浏览器的角度上，则会变的更为柳暗花明。现阶段，大多数浏览器都支持多种安全策略，如沙盒机制，跨域机制，跨文档消息和CSP。在这里，我们关注CSP（Content Security Policy），又称内容安全协议，CSP通过服务端响应的HTTP头部来制定网页相关资源的加载域，这些资源限定于js文件、css文件、image、iframe、字体和其他对象（如object、applet）。
CSP通过HTTP头部由服务端制定，头部类型由于历史原因总共由三种，这三种仅仅是兼容性的差别，针对chrome浏览器，我们仅需关注Content-Security-Policy头部。CSP头部的定义规则如下：Content-Security-Policy: 名 值; 名 值; 名 值;
具体的指令名如下图：指令值的规范如下图：
因此，如果我们要避免XSS攻击，可以限定脚本的来源域，如：Content-Security-Policy: default-src 'self' ;这样，非本域和域下的其他脚本不会被加载，避免了XSS。
在这里需要强调一点的是，默认CSP会禁止script代码块的执行；禁止内联事件处理函数；禁止内联样式；禁止eval和new Function。对于内联script代码块和内联样式，可通过CSP的header设置，如Content-Security-Policy: default-src 'self'; script-src 'unsafe-inline';。
CSP有一个指令需要注意，即report-uri，它会将错误信息主动发送至改cgi（sevlet），用于管理员的统一管控。report-uri属性将会在下文中涉及到。
webkit中的XSS组件
XSS攻击主要发生在页面的渲染时，当浏览器的渲染引擎获取到该页面并开始解析时，是可以在该阶段进行安全校验的，具体的时间节点则是在词法分析后针对每个token做过滤。
在webkit中，由HTMLDocumentParser解析得到token后，使用XSSAuditor进行过滤，具体则是在filterToken中执行，不仅仅是针对token的名称，其属性也是监测重点。在webkit中采用黑名单机制，针对&,,,&做重点排查，当发现相关隐患时，生成相关信息XSSInfo，由XSSAuditorDelegate类发送给对应的cgi，该cgi的地址正是CSP中的指令值report-uri,当然也可以手动制定该值。
默认，XSSAuditor是启用的，但是XSSAuditor在发现XSS行为时却有多种，这些行为可以配置，这就涉及到HTTP头部X-XSS-Protection。该头部并不是W3C和IETF的规范，而是非标准实现，通过对该头部的赋值来定制XSSAuditor的相关行为。
默认情况，XSSAuditor处于重写模式(js代码处在非执行状态)，即X-XSS-Protection：1；如果要禁用XSSAuditor，可以X-XSS-Protection：0；当设置为X-XSS-Protection：1;mode=block，则会在XSSAuditor作用时禁止网页显示，呈现给用户的则是空白页；若设置为X-XSS-Protection：1;report=... ，则会将相关统计信息发送给CSP中定义的report-uri。XSSAuditor无法完全避免XSS，但毕竟在浏览器层面提供了一层检查机制，从HTML tag上保证其可靠性。
XSS漏洞难以发现，但是作为开发人员需要于细节处避免制造XSS漏洞，而对于CSP规范和webkit的XSSAuditor机制的使用，我们不应抱着依靠它们的想法来解决XSS，毕竟不是所有的页面都可以容忍CSP的严格，XSSAuditor机制也仅仅针对chrome而言，并且存在多种bypass绕过检查，如通过各种HTML实体编码、url编码和js编码。因此，我们仍需以人为本，规范开发习惯，提高WEB前端安全意识。
参考文章：1&2&3 webkit技术内幕
/accordion/p/5446174.html每天三分钟，知晓天下事，视频、语音、文字综合版任您挑！微信搜索fgzadmin关注或点击标题下方可以快速关注。
原创不易，认可价值，动手指点并转发，就是最好的支持与肯定。淘宝特约店址：http://goldengame.
深夜十点，陪你读书。
慢工出细活
由于中、美、俄三国自2008年后基本上长期上演“三国杀”（昨天文章《原创丨中美俄世纪三国杀，谁是百年长跑冠军
其实这是个有奖活动贴。n其实这是个有奖活动贴。n其实这是个有奖活动贴。
思考者正在阅读原创丨三次世界大战亚洲开打，美国推演靠谱吗？原创丨央行连出两大招，有何深意？微历史丨张学良为啥
美国总统奥巴马日在接受媒体采访时表示，2011年对利比亚局势的干涉，是其总统生涯中做出的最
我们都知道，美国软实力很厉害，在过去很多年都一直掌控者国际话语权，他们可以提着民主、自由、人权的大棒满世界乱
思考者正在阅读原创丨重大变革，我们的世界都将逃不过被TA重塑！原创丨中美黄岩岛较量，谁是最后赢家？原创丨你射XSS攻击介绍
XSS（Cross Site Script，又称CSS）跨站脚本攻击，是指攻击者利用站点的安全漏洞往Web页面里插入恶意html代码或JS脚本，当用户浏览该页时，嵌入Web里面的攻击脚本会被执行，达到攻击目的。
因为这种攻击是通过别人的网站脚本漏洞达到攻击的效果，就是说可以隐藏攻击者的身份，因此叫做跨站攻击。
（1）非持久性XSS
最直观的就是构造URL欺骗用户点击，URL中构造的参数值，没有进行任何过滤和转义处理就立即显示在页面上，另外一种情况就是在检索框中注入XSS脚本。
没有进行转义处理可能存在两种情况：
1、服务器对特定参数没有进行相应的转义处理；
2、客户端脚本直接获取URL中特定参数，没有进行转义处理直接打印在页面上。
非持久性XSS的特性：
1、非存储性：构造的恶意脚本不会保存在后端服务器
2、一次性特征：点击了构造的特定URL才会触发XSS。
例如可以将构造有XSS漏洞的URL在贴吧中发帖传播，从而可以达到攻击效果。
（2）持久性XSS
它是将攻击代码提交到了服务器端的数据库或文件系统中，不用构造URL，而是保存在文章或论坛帖子中，从而使得访问该页面的用户都有可能受到攻击。
一般需要网站有用户自输入内容的特征。所以在BBS、贴吧等发帖形式的网站中最容易出现。
持久性XSS漏洞的特征：
1、存储性：注入的恶意脚本是保存在后端数据库或者文件系统中。
2、持久性：只要用户打开注入脚本的页面，就会受到攻击，所以这种XSS的危害性更大。
（3）基于DOM操作的XSS
前两种xss攻击，都是由于服务器端程序没有对特殊字符进行转义导致的。Dom-based XSS攻击是基于JS脚本程序在操作document对象以及URL地址时不当而导致的。
一段获取浏览器参数并使用它去更新Web页面的JS代码就很容易被利用。
通常情况下：document.location、document.URL、document.referrer这几个对象最容易被利用。
&title&Welcome!&/title&
pos=document.URL.indexOf("name=")+5;&&&&&&&
document.write(document.URL.substring(pos));
&br/& Welcome to our
&如果浏览器传入正常的参数，则可以正确显示，但是如果有类似下面的请求时：http://www.vulnerable.site/welcome.html?name=&script&alert(document.cookie)&/script&
这样的请求时，这段恶意代码就会被执行
1.模板中UI变量未进行合理字符转义
例如某个UI变量的使用应该选择转义，但是模板开发人员却忘记了转义。或者某个转义方案遗漏某些字符的转义，例如转义方案中，只对&和&进行了转义，但是却遗忘了单引号和双引号的转义。这些错误都会导致XSS的产生。
&input type="text" name="title"
value="$title$"/&
其中$title$即表示标题的UI变量。模板开发人员没有正确选择的转义。这样，攻击者可以发一个title标题为如下：
标题中的双引号以及尖括号都没有进行相应的转义就直接替换到模板中的UI变量$title$，直接替换的源代码如下：
&input type="text" name="title"
value=""/&&script&alert("xss");&/script&"/&
成功地在页面中注入了JS脚本代码。
2.通过输入半个汉字来构造
可以通过输入单字节（半个汉字）来构造XSS漏洞，是由于后端程序没有对输入的数据进行字符扫描，去除半个汉字或超过GBK编码范围的字符.
由于$title$变量进行js转义(对标题中的双引号“进行转义成”)，所以标题转义成：半个汉字出现在中间呢?\“;alert(1);”
又由于半个汉字“呢?”会把紧跟其后的反斜杠吃掉，所以替换到模板中的代码如下：
&script&var&
v = "半个汉字出现在中间呢";alert(1);"";&/script&
于是，户可以写入自定义的js代码就被执行了。
3.整个标签导致的XSS漏洞
var _title = "$title:j$";
&/script &
如果输入的帖子标题为：
//--&&/script&&script&alert(document.cookie);//
由于没有整体对&/script&标签进行过滤处理，&/script&与前面的&script&进行了匹配
var _title =
"//--&&/script&&script&alert(document.cookie);//";
&/script &
4.JS中注释导致的XSS漏洞
JS注释中存在JS代码，并且还存在模板解析的变量
如果title变量为：*/alert("XSS");alert("XSS");
&/ script &
5.通过字符集编码来构造
如果产品线对外可以开放CSS，那么攻击者可以通过上传如下代码的CSS文件，从而达到XSS攻击的效果
@charset "utf-7";
a{80sec:expre/+ACoAKg-/ssion(if(!window.x){alert(/xxx/);window.x=1})}
漏洞原因：
@charset “utf-7”;
表明了css代码的编码格式为
utf-7，而根据utf-7的编码规则，是由
“-”结束的一堆代码（-
结尾非必要）。
那么 +ACoAKg-
即utf-7编码格式，经由浏览器转换成gbk之后，就变成了
**，即原来的
/+ACoAKg-/
也就是普通的css注释了，xss自然就发生了
6.富编辑导致的漏洞
一般富编辑中需要进行如下处理：
标签的转义：&script&、&style&等等
关键词的过滤：javascript、exepression
如果下面的语句不处理会导致XSS产生：
style="top:expression_r(alert('XSS'));"只对IE有效style="background:url(javascript:alert('XSS'));“
标签属性的过滤：
onload=“alert(‘cookie’);” src=“”/&
有关富编辑器的过滤处理请参考：/doc/websafe/editor_xss.html
www服务依赖于Htpp协议实现，Http是无状态的协议，所以为了在各个会话之间传递信息，就不可避免地用到Cookie或者Session等
技术来标记访问者的状态，而无论是Cookie还是Session，一般都是
利用Cookie来实现的（Session其实是在浏览器的Cookie里带了一个Token来标记，服务器取得了这个Token并且检查合法性之后就把
服务器上存储的对应的状态和浏览器绑定），这样就不可避免地安全聚焦到了Cookie上面，只要获得这个Cookie，就可以取得别人的身份，这对于入侵
者是一件很美妙的事情，特别当获得的Cookie属于管理员等高权限身份者时，危害就更大了。在各种web安全问题里，其中XSS漏洞就因此显得格外危
熟悉导致XSS漏洞的起因和常见XSS攻击方式，排查代码。使用标准的机制去验证用户输入内容的长度、类型、语法和商业规则，然后才将它们显示或保存到数
据库中。不能仅仅依赖于客户端验证数据的合法性。因为攻击者会绕过客户端验证，直接构造恶意URL或数据包，所以要在服务器端对数据进
行严格验证，在页面上输出要客户提交的内容时，进行正确编码。
虽然有很多工具可以帮助我们进行漏洞检测，但是工具是死的，攻击者是活的，攻击方法也曾出不穷。所以我们不能完全依赖工具，应该采用手工测试和自动检测相结合的手段。
必须在Code
Review工作中关注代码的安全性，排查并优化代码，从源头上控制漏洞的产生，防患于未然。
如果应用必须支持用户提供的HTML，需要确认接收的HTML内容被妥善地格式化，仅包含最小化的、安全的tag，绝对不允许JavaScript代码出现，去掉任何对远程内容的引用（尤其是样式表和JavaScript）。
RatProxy Google的开源XSS检测工具。下载地址：
Paros proxy
一个基于Java的网页程序漏洞评估代理，它包含有网页通讯记录器、Web spider和一个常用网页程序攻击扫描器，可以检测SQL注入和跨网站脚本等。
一款非常优秀的可以截取并修改客户端 Post和Get请求的软件，通过它可以在浏览器发出请求前允许修改数据，从而绕过客户端的脚本验证。通过它，借助已有的XSS测试语句，就可以构造恶意
URL来测试Web页面的XSS漏洞。
SQL & XSS Finder
一个网站检测工具，可以构造SQL和XSS注入语句，提供了常见的语句，并将语句最终的执行效果展现在浏览器中，通过它能发现Web页面是否具有常见的XSS漏洞，是一款简单的XSS漏洞检测辅助工具。
WebInspect，Acunetix Web Security
Scanner，AppScan等等。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。}