嘻嘻,标题党了。。
目录
一、XSS的定义与分类
二、XSS与同源策略
XSS(Cross Site Scripting),跨站脚本。该漏洞发生在用户端,成因是由于动态网页的Web应用对用户提交请求参数未做充分的检查过滤,允许用户在提交的数据中掺入HTML代码,然后未加编码地输出到第三方用户的浏览器,这些攻击者恶意提交代码会被受害用户的浏览器解释执行。
XSS的攻击目标是为了盗取客户端的cookie或者其他网站用于识别客户端身份的敏感信息。获取到合法用户的信息后,攻击者甚至可以假冒最终用户与网站进行交互。
同源策略首当其冲的作用是防止用户在A网站中 使用在B网站已登录的身份 对B网站的数据进行操作。但过于严苛的同源策略会影响数据互联,比如拥有多个子域的大型网站,因此是控制不同源之间的交互是非常重要的事情。
一般来说,交互存在三种:通常允许跨域写操作(链接、重定向、表单提交)、通常允许跨域资源嵌入、通常不允许跨域读操作。可能嵌入跨源的资源的一些示例有:
标签嵌入跨域脚本。语法错误信息只能在同源脚本中捕捉到。
标签嵌入CSS。由于CSS的松散的语法规则,CSS的跨域需要一个设置正确的Content-Type 消息头。![]()
/
/
嵌入多媒体资源。
和
的插件。@font-face
引入的字体。一些浏览器允许跨域字体( cross-origin fonts),一些需要同源字体(same-origin fonts)。
和
载入的任何资源。站点可以使用X-Frame-Options消息头来阻止这种形式的跨域交互。下面介绍利用上述所说进行跨域的技术:
1.JSONP跨域:利用 标签的跨域能力实现跨域数据的访问,请求动态生成的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:
| * 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:
Access-Control-Allow-Credentials:声明是否允许在请求中带入
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods:声明允许的访问方式
Access-Control-Allow-Methods:
[, ]* Access-Control-Allow-Headers:声明允许的头
Access-Control-Allow-Headers:
[, ]*
常见请求头:
Origin:指定请求的源
Origin:
Access-Control-Request-Method:声明请求使用的方法
Access-Control-Request-Method:
Access-Control-Request-Headers:声明请求使用的header
Access-Control-Request-Headers:
[, ]*
⚠️危险:使用不当,相当致命
资源目录:
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)()
加载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
Content Security Policy(CSP),用于控制资源的加载,以有效减少XSS。市面上一般有3类CSP,这主要是因为浏览器的不同:
在响应报文的头部中和Meta中,可以有效使用CSP,示例如下:
HTTP header :
"Content-Security-Policy:" 策略
"Content-Security-Policy-Report-Only:" 策略
在使用细节中,以下字段是策略中对具体资源的控制指令:
关于具体的值的解释,这里不必赘述,值得注意的是“-”表示
允许从任意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条件下,将可以加载外部资源,但很多情况下不能执行预加载。