XSS的攻击技巧:
书上都是一些例子!很是令人费解,不过我的理解是:XSS攻击利用字符编码是指在一定情况下本来某个代码的地方,没有漏洞,而恰恰是系统在做安全检查的时候把某些变量的某些周边字符给转义导致存在了漏洞;此类漏洞是编程人员的不严谨造成的!
在XSS攻击的变量会有长度限制,但是攻击者会绕过这种长度限制!例如利用事件(Event)来缩短字节长度限制从而达到攻击的目的;不过利用事件能都缩短的字节数是很少的,最好的方法是把XSSpayload写到别处,再通过简短的代码加载这段XSSpayload。
最常用做藏代码的地方就是“location.hash”。而且根据http协议,location.hash的内容不会再http包中发送,所以服务器端web日志中不会记录下location.hash的内容,从而更好地隐藏了黑客的真是意图。
<base>标签并不常用,它的作用是定义页面上的所有使用“相对路径”标签的hosting地址;
需要特别注意的是,在有的技术文档中,提到<base>标签只能用于<head>标签之内,其实这是不对的。<base>标签可以出现在页面的任何地方,并作用于位于该标签之后的所有标签。所以在设计XSS安全方案时,一定要过滤掉这个非常危险的标签!
学到的都是基于html的XSS攻击,在Flash中同样可以构造XSS攻击。在FLASH中嵌入actionscript脚本,一个常见的FlashXSS可以这样写:
GetURL(“javascript:alert(document.cookie)”)
6:在web前端的开发中,JavaScript开发框架是特别受欢迎的,但是 JavaScript开发框架也存在一些XSS漏洞,为了治标治本我们得重视这些问题!力求做到相对安全!
Dojo一个流行的JavaScript开发框架;
jQuery可能是目前最为流行的JavaScript框架,它本身出现的漏洞很少。但JavaScript框架只是对JavaScript语言本身的封装,并不能解决代码逻辑上产生的问题。
下面这张图应该可以概括我这几天学到的XSS了吧!(完全很通俗的解释了跨站脚本攻击的过程了)
1:XSS的防御是复杂的,流行的浏览器Firefox的csp、noscript扩展,IE 8内置的XSS filter等都是一些安全防御措施;
由微软提出,在IE 6 中实现,至今成为一个标准,作用:;浏览器讲禁止页面的JavaScript访问带有httponly属性的cookie。
支持httponly的浏览器有:
IE 6 SP1+
Firefox 2.0.0.5+
Firefox 3.0.0.6+
Google chrome
Apple Safari 4.0+
Opera 9.5+
严格来讲,httponly并非为了对抗XSS,httponly解决的是XSS后的cookie劫持攻击;设置httponly的作用说白了就是保护用户浏览器的核心认证信息及密码等等!它只是暂时守住了cookie不被劫持而已!但并不能保证黑客可以绕过httponly标记从而获得cookie。就目前的黑客技术来讲,httponly还是一个保护cookie的标准被大家共同使用着···
下面我们来看看到底什么是httponly?它为何如此风骚守住一片天地呢?
(1)首先让我们来看看cookie的工作机制:
Step1:浏览器向服务器发起请求,这时候没有cookie;
Step2:服务器返回时发送set-cookie头,向客户端浏览器写入cookie;
Step3:在该cookie到期前,浏览器访问该域下的所有界面,都得发送该cookie。
注:httponly是在set-cookie时标记的!
需要注意的是:服务器可能会设置多个cookie,而httponly可以有选择性地加在任何一个cookie值上。
在某些时候,应用可能需要JavaScript访问某几项cookie,这种cookie可以不设置httponly标记;而把httponly标记给用于认证的关键cookie上!
(2)httponly的使用非常灵活:在不同语言中给cookie添加httponly的代码如下(网上借来的,不过可以理解的!)
HttpOnly的设置样例
javaEE
1 2 |
response.setHeader("Set-Cookie", "cookiename=value; Path=/;Domain=domainvalue;Max-Age=seconds;HTTPOnly"); |
|
具体参数的含义再次不做阐述,设置完毕后通过js脚本是读不到该cookie的,但使用如下方式可以读取
1 |
Cookie cookies[]=request.getCookies(); |
C#
1 2 3 |
HttpCookie myCookie = new HttpCookie("myCookie"); myCookie.HttpOnly = true; Response.AppendCookie(myCookie); |
VB.NET
1 2 3 |
Dim myCookie As HttpCookie = new HttpCookie("myCookie") myCookie.HttpOnly = True Response.AppendCookie(myCookie) |
但是在 .NET 1.1 ,中您需要手动添加
1 |
Response.Cookies[cookie].Path += ";HTTPOnly"; |
PHP4
1 |
header("Set-Cookie: hidden=value; httpOnly"); |
PHP5
1 |
setcookie("abc", "test", NULL, NULL, NULL, NULL, TRUE); |
最后一个参数为HttpOnly
使用httponly有助于缓解XSS攻击,但仍需要其他能够解决XSS漏洞的方案!
常见的web漏洞都要求攻击者构造一些特殊字符,这些字符通常用户是无法看到的!所以输入检查就很有必要存在了!(相信大家在注册某些账户时就明白了,为什么会百般刁难你用数字,下划线和字母的组合!这一点就安全排除了一些特殊字符的出现,从而大大保证了用户的安全)
这种格式检查类似于“白名单”,可以让一些基于特殊字符的攻击失效!
输入检查的逻辑,必须放在服务器端代码中实现。如果只是在客户端使用JavaScript进行输入检查,是很容易被攻击者绕过的。目前web开发的普遍做法,是同时在客户端JavaScript中和服务器代码中实现相同的输入检查。客户端JavaScript的输入检查,可以阻挡大部分误操作的正常用户,从而节约服务器资源。
在XSS的防御上,发现输入的特殊字符会惊醒字符过滤或者编码!但存在一个问题:如果XSS filter不够智能的话,会粗暴的过滤或编码!这就导致了改变用户原来的本意!
一般来讲,除了富文本的输出外,在变量输出到html页面时,可以使用编码或转义的方式来防御XSS攻击。
(1)安全的编码函数:针对HTML代码的编码方式是HtmlEncode。
XSS的本质还是一种“HTML注入”,用户的数据被当成了HTML代码的一部分来执行,从而混淆了原本的语义,产生了新的语义,导致直接产生XSS!
治标治本,所以还得具体问题具体分析,找到发生XSS的场景来解决问题,才能真正的做到XSS的防御!这里我就不举例了,因为我也没实践过!不过这节课日后一定补上!