【Web安全】一文说清XSS

嘻嘻，标题党了。。

目录

一、XSS的定义与分类

二、XSS与同源策略

---

一、XSS的定义与分类

XSS(Cross Site Scripting)，跨站脚本。该漏洞发生在用户端，成因是由于动态网页的Web应用对用户提交请求参数未做充分的检查过滤，允许用户在提交的数据中掺入HTML代码，然后未加编码地输出到第三方用户的浏览器，这些攻击者恶意提交代码会被受害用户的浏览器解释执行。

XSS的攻击目标是为了盗取客户端的cookie或者其他网站用于识别客户端身份的敏感信息。获取到合法用户的信息后，攻击者甚至可以假冒最终用户与网站进行交互。

二、XSS与同源策略（讲述XSS的产生）

同源策略首当其冲的作用是防止用户在A网站中 使用在B网站已登录的身份 对B网站的数据进行操作。但过于严苛的同源策略会影响数据互联，比如拥有多个子域的大型网站，因此是控制不同源之间的交互是非常重要的事情。

一般来说，交互存在三种：通常允许跨域写操作（链接、重定向、表单提交）、通常允许跨域资源嵌入、通常不允许跨域读操作。可能嵌入跨源的资源的一些示例有：

• <script src="..."></script> 标签嵌入跨域脚本。语法错误信息只能在同源脚本中捕捉到。
• <link rel="stylesheet" href="..."> 标签嵌入CSS。由于CSS的松散的语法规则，CSS的跨域需要一个设置正确的Content-Type 消息头。
• <img> / <video> / <audio> 嵌入多媒体资源。
• <object> <embed> 和 <applet> 的插件。
• @font-face 引入的字体。一些浏览器允许跨域字体（ cross-origin fonts），一些需要同源字体（same-origin fonts）。
• <frame> 和 <iframe> 载入的任何资源。站点可以使用X-Frame-Options消息头来阻止这种形式的跨域交互。

下面介绍利用上述所说进行跨域的技术：

1.JSONP跨域：利用 <script> 标签的跨域能力实现跨域数据的访问，请求动态生成的JavaScript脚本同时带一个callback函数名作为参数。服务端收到请求后，动态生成脚本产生数据，并在代码中以产生的数据为参数调用callback函数。

⚠️危险：当对传入/传回参数没有做校验就直接执行返回的时候，会造成XSS问题。没有做Referer或Token校验就给出数据的时候，可能会造成数据泄露。

2.跨源脚本API访问：主力军是window.name,利用了浏览器的特性来做到不同域之间的数据传递，不需要前端和后端的特殊配制。如：

window 允许跨源访问的方法有

• window.blur
• window.close
• window.focus
• window.postMessage

window 允许跨源访问的属性有

• window.closed
• window.frames
• window.length
• window.location
• window.opener
• window.parent
• window.self
• window.top
• window.window

⚠️危险：当前页面所有window都可以修改，很不安全

3.postMessage：不需要后端介入就可以做到跨域，一个函数外加两个参数（请求url，发送数据）就可以搞定。

4.CORS：全称是"跨域资源共享"（Cross-origin resource sharing）。通过这个标准，可以允许浏览器读取跨域的资源。

常见返回头

• Access-Control-Allow-Origin：声明允许的源

  • Access-Control-Allow-Origin: <origin> | *

• Access-Control-Expose-Headers：声明允许暴露的头

  • e.g. Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header

• Access-Control-Max-Age：声明Cache时间

  • Access-Control-Max-Age: <delta-seconds>

• Access-Control-Allow-Credentials：声明是否允许在请求中带入

  • Access-Control-Allow-Credentials: true

• Access-Control-Allow-Methods：声明允许的访问方式

  • Access-Control-Allow-Methods: <method>[, <method>]*

• Access-Control-Allow-Headers：声明允许的头

  • Access-Control-Allow-Headers: <field-name>[, <field-name>]*

常见请求头：

• Origin：指定请求的源

  • Origin: <origin>

• Access-Control-Request-Method：声明请求使用的方法

  • Access-Control-Request-Method: <method>

• Access-Control-Request-Headers：声明请求使用的header

  • Access-Control-Request-Headers: <field-name>[, <field-name>]*

⚠️危险：使用不当，相当致命

三、利用XSS获取有价值资源

资源目录：

URL：

• location
• location.href
• location.pathname
• location.search
• location.hash
• document.URL
• document.documentURI
• document.baseURI

Navigation：

• window.name
• document.referrer

Communication

• Ajax
• Fetch
• WebSocket
• PostMessage

Storage

• Cookie
• LocalStorage
• SessionStorage

xss手段：

执行JavaScript

    eval(payload)
    setTimeout(payload, 100)
    setInterval(payload, 100)
    Function(payload)()
    <script>payload</script>
    <img src=x onerror=payload>

加载URL

    location=javascript:alert(/xss/)
    location.href=javascript:alert(/xss/)
    location.assign(javascript:alert(/xss/))
    location.replace(javascript:alert(/xss/))

执行HTML

    xx.innerHTML=payload
    xx.outerHTML=payload
    document.write(payload)
    document.writeln(payload)

 payload：https://blog.csdn.net/qq_37865996/article/details/102293788

关于payload的技巧说明：https://websec.readthedocs.io/zh/latest/vuln/xss/wafbypass.html

四、XSS与CSP（讲述消减XSS的措施）

Content Security Policy（CSP），用于控制资源的加载，以有效减少XSS。市面上一般有3类CSP，这主要是因为浏览器的不同：

• Content-Security-Policy (Google Chrome)
• X-Content-Security-Policy (Firefox)
• X-WebKit-CSP (WebKit-based browsers, e.g. Safari)

在响应报文的头部中和Meta中，可以有效使用CSP，示例如下：

HTTP header :
"Content-Security-Policy:" 策略
"Content-Security-Policy-Report-Only:" 策略

<meta http-equiv="content-security-policy" content="策略">
<meta http-equiv="content-security-policy-report-only" content="策略">

在使用细节中，以下字段是策略中对具体资源的控制指令：

• default-src
• connect-src
• font-src
• frame-src
• img-src
• media-src
• object-src
• script-src
• style-src
• base-url
• sandbox
• report-url

关于具体的值的解释，这里不必赘述，值得注意的是“-”表示允许从任意url加载，除了 data: blob: filesystem: scheme。unsafe-eval允许一些不安全的代码执行方式，例如js的eval()。unsafe-inline允许内部资源执行代码例如style、onclick、sicript标签。

这样，最终完整的示例：

Content-Security-Policy: default-src '-'; script-src '-' 'unsafe-inline';

所谓，魔高一尺，道高一丈，二者互相超越，那么如何绕过CSP呢？

• 预加载。预加载在允许unsafe-inline条件下，将可以加载外部资源，但很多情况下不能执行预加载。
• MIME Sniff，csp允许跨站读图片资源，传一个含有脚本的img，再``<script href='http://xxx.com/xx.jpg'>``，有绕过的可能。
• 使用302跳转，但跳板必须在允许的域内，并且要加载的文件的host部分必须跟允许的域的host部分一致。

• iframe。当可以执行代码时，可以创建一个源为 css js 等静态文件的frame，在配置不当时，该frame并不存在csp，则在该frame下再次创建frame，达到bypass的目的。同理，使用 ../../../ /%2e%2e%2f 等可能触发服务器报错的链接也可以到达相应的目的。

五、更加完善的防御XSS措施

• HTML过滤：如白名单、黑名单

• X-Frame：当值为DENY、SAMEORIGIN时，可起到防御使用iframe进行攻击的作用

• XSS保护头：基于 Webkit 内核的浏览器的防护机制

六、好玩的jsfuck cheat sheet

Basic values

• undefined > [][[]]
• false > ![]
• true > !![]
• NaN > +[![]]
• 0 > +[]
• 1 > +!+[]
• 2 > !+[]+!+[]

Basic strings

• '' > []+[]
• 'undefined' > []+[][[]]
• 'false' > []+![]
• 'true' > []+!![]
• 'NaN' > []+(+[![]])
• '0' > []+(+[])
• '1' > []+(+!+[])
• '2' > []+(!+[]+!+[])
• '10' > [+!+[]]+[+[]]
• '11' > [+!+[]]+[+!+[]]
• '100' > [+!+[]]+[+[]]+(+[])

Higher numbers

• 10 > +([+!+[]]+[+[]])
• 11 > +([+!+[]]+[+!+[]])
• 100 > +([+!+[]]+[+[]]+(+[]))

String alphabet

• 'a' > ([]+![])[+!+[]]
• 'd' > ([]+[][[]])[+!+[]+!+[]]
• 'e' > ([]+!+[])[+!+[]+!+[]+!+[]]
• 'f' > ([]+![])[+[]]
• 'i' > ([]+[][[]])[+!+[]+!+[]+!+[]+!+[]+!+[]]
• 'l' > ([]+![])[+!+[]+!+[]]
• 'n' > ([]+[][[]])[+!+[]]
• 'r' > ([]+!+[])[+!+[]]
• 's' > ([]+![])[+!+[]+!+[]+!+[]]
• 't' > ([]+!+[])[+[]]
• 'u' > ([]+!+[])[+!+[]+!+[]]