XSS漏洞总结

最新推荐文章于 2024-07-26 17:39:18 发布

R0ck3t

最新推荐文章于 2024-07-26 17:39:18 发布

阅读量667

点赞数

CC 4.0 BY-SA版权

文章标签：大数据

本文链接：https://blog.csdn.net/m0_62805300/article/details/125748958

简介

跨站脚本攻击是指恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。

反射型XSS

以piakchu为例

直接写入XSS语句

注入成功

像这种反射性XSS没有写入到服务端,要想利用其进行攻击只能构造恶意连接。

http://127.0.0.1/pikachu/vul/xss/xss_reflected_get.php?message=%3Cscript%3Ealert(%221%22)%3C%2fscript%3E&submit=submit

类似上面这种

一般来说反射性XSS危害较低

存储型XSS

相比与反射性存储型XSS危害就大得多

只要访问到该页面就会收到XSS的攻击

DOM型XSS

注入点
通过js脚本对对文档对象进行编辑，从而修改页面的元素。也就是说，客户端的脚本程序可以DOM动态修改页面的内容，从客户端获取DOM中的数据并在本地执行。由于DOM是在客户端修改节点的，所 
以基于DOM型的XSS漏洞不需要与服务器端交互，它只发生在客户端处理数据的阶段。

它的流程是这样的：
1.攻击者寻找具有漏洞的网站
2.攻击者给用户发了一个带有恶意字符串的链接
3.用户点击了该链接
4.服务器返回HTML文档，但是该文档此时不包含那个恶意字符串
5.客户端执行了该HTML文档里的脚本，然后把恶意脚本植入了页面
6.客服端执行了植入的恶意脚本，XSS攻击就发生了

绕过

1. 编码绕过:

url编码绕过

unicode编码绕过

html实体编码绕过:实体编码绕过需要结合<svg></svg>标签使用,否则利用的失败率比较高

2. 换行绕过

使用%0A进行关键字绕过

3. 利用全局变量绕过

Self,window等等

c=0;for(i in self){if(/^a[rel]+t$/.test(i)){self[Object.keys(self)[c]](1)}c++;};

4. 关键字绕过

Alert被过滤了可以使用下面的进行弹窗

具体还可以参考XSS利用宝典

以下内容参考 xss漏洞学习小结 - FreeBuf网络安全行业门户

域、同源、CORS、 JSONP

同源

1995年，同源政策由 Netscape公司引入浏览器。目前，所有浏览器都实行这个政策。最初，它的含义是指，A网页设置的 Cookis，B网页不能打开，除非这两个网页"同源"

所谓“同源”指的是“三个相同”：

协议相同

域名相同

端口相同

看看示例来小试牛刀

同源政策的目的，是为了保证用户信息的安全，防止恶意的网站窃取数据。

设想这样一种情况：A网站是一家银行，用户登录以后，又去浏览其他网站。如果其他网站可以读取A网站的 Cookie，会发生什么？

很显然，如果 Cookie包含隐私（比如存款总额），这些信息就会泄漏。更可怕的是Cookie往往用来保存用户的登录状态，如果用户没有退出登录，其他网站就可以冒充用户，为所欲为。因为浏览器同时还规定，提交表单不受同源政策的限制。

由此可见，"同源政策"是必需的，否则 Cookie可以共享，互联网就毫无安全可言了。

随着互联网的发展，"同源政策" 越来越严格。目前，如果非同源，共有三种行为受到限制。

（1）Cookie、 LocalStorage 和 IndexDB 无法读取。（2）DOM无法获得。（3）AJAX请求不能发送。

当然，这些条件都是相对的，在某些特殊的情况下，我们也可以通过同源策略所允许的共享机制，完成非同源页面之间数据的传送。

跨域

所谓跨域，或者异源，是指主机名（域名）、协议、端口号只要有其一不同，就为不同的域（或源）。浏览器中有一个基本的策略，叫同源策略，即限制"源"自A的脚本只能操作“同源”页面的DOM。浏览器中，< script>/<img>/< iframe>/<link>等标签都是可以跨域来加载资源的而不受同源策略的影响。带″src′属性的标签每次加载时，实际上都是浏览器发起次”GET”请求。

对于 XMLHttpRequest来说，它可以访问来自同源对象的内容。但是不能够跨域访问资源。他需要通过目标域返回的HTTP头授权是否允许跨域访问，因为HTTP头对于 javascript来说一般是无法控制的，所以认为这个方案是可行的。

对于浏览器来说：除了DOM、Cookie、XMLTttpRequest会受到同源策略的限制外，浏览器加载的第三方插件也有各自的同源策略。例如：flash,java applet, silverlight, coogle gears等。

跨域的方法

JSONP

JSONP跨城

JSONP劫持

(1）用户在网站B注册并登录，网站B包含了用户的d,name,emai等信息

(2）用户通过浏览器向网站A发出URL请求

(3）网站A向用户返回响应页面，响应页面中注册了 JavaScript的回调函数和向网站B请求的 script标签，示例代码如下`

(4）用户收到响应，解析JS代码，将回调函数作为参数向网站B发岀请求； (5）网站B接收到请求后，解析请求的URL，以SON格式生成请求需要的数据，将封装的包含用户信息的JSON数据作为回调函数的参数返回给浏览器，网站B返回的数据实例如下：Callback(){id"：l，"name"：test"，"email"：testatest com"})(6）网站B数据返回后，浏览器则自动执行 Callback函数对步骤4返回的JSON格式数据进行处理，通过alert 弹窗展示了用户在网站B的注册信息。另外也可将JSON数据回传到网站A的服务器，这样网站A利用网站B的JSONP漏洞便获取到了用户在网站B注册的信息。

CORS

CORS是一个W3C标准，全称是"跨域资源共享"”（ Cross-origin resource sharing）

它允许浏览器向跨源服务器，发出 XMLHttpRequest请求，从而克服了AJAX只能同源使用的限制。 CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。

浏览器端：

目前，所有浏览器都支持该功能（IE10以下不行）。整个CORS通信过程，都是浏览器自动完成，不需要用户参与。

服务端:

CORS通信与AJAX没有任何差别，因此你不需要改变以前的业务逻辑。只不过，浏览器会在请求中携带一些头信息，我们需要以此判断是否运行其跨域，然后在响应头中加入一些信息即可。这一般通过过滤器完成即可。

不符合简单请求的条件，会被浏览器判定为特殊请求，例如请求方式为PUT

特殊请求会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（ preflight）。

浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。

与简单请求相比，除了 Origin以外，多了两个头

Access-Control-Request-Method：接下来会用到的请求方式，比如PUT

Access- Control- Request-Headers：会额外用到的头信息

服务的收到预检请求，如果许可跨域，会发出响应

除了 Access-Contro-Allow-Origin和Aces-Contro-Allow-Credentials以外，这里又额外多出3个头：

Access-Contro|-Allow-Methods：允许访问的方式

Access-Control- Allow- Headers：允许携带的头

Access-Control-Max-Age：本次许可的有效时长，单位是秒，过期之前的ajax请求就无需再次进行预检了

如果浏览器得到上述响应，则认定为可以跨域，后续就跟简单请求的处理是一样的

PostMessage跨城

SameSite

Chrome51开始，浏览器的 Cookie新增加了—个 SameSite属性，用来防止CSRF攻击和用户追踪。

Cookie的 Samesite属性用来限制第三方 Cookie，从而减少安全风险。它可以设置个值 Strict 、 Lax、 None

Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送Cookie。换言之，只有当前网页的URL与请求目标—致，才会带上 Cookie。

Set-Cookie:CookieName=CookieValue:SameSite=Strict;

这个规则过于严格，可能造成非常不好的用户体验。比如，当前网页有一个 GitHub链接，用户点击跳转就不会带有 GitHub的 Cookie，跳转过去总是未登陆状态。

Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的Get请求除外。

Set-Cookie:CookieName=CookieValue;SameSite=Lax

导航到目标网址的GET请求，只包括三种情况：链接，预加载请求，GET表单。详见下表。

Chrome计划将Lax变为默认设置。这时，网站可以选择显式关闭 SameSite属性将其设为None。不过，前提是必须同时设置 Secure属性（ Cookie只能通过 Https协议发送），否则无效。

下面的设置无效:

Set-Cookie:widget_session=abc123;SameSite=None

下面的设置有效:

Set-Cookie:widget_session=abc123;SameSite=None;Secure

CSP

CSP全称为 Content Security Policy，即内容安全策略。主要以白名单的形式配置可信任的内容来源，在网页中，能够使白名单中的内容正常执行（包含JS，CSS，Image等等），而非白名单的内容无法正常执行，从而减少跨站脚本攻击（XSS），当然，也能够减少运营商劫持的内容注入攻击。

为使CSP可用，你需要配置你的网络服务器返回Content-Security-Policy HTTP头部（有时你会看到一些关于X-Content-Security-Policy头部的提法，那是旧版本，你无须再如此指定它）

除此之外，<meta>元素也可以被用来配置该策略，例如

CSP旨在减少（注意这里是减少而不是消灭）跨站脚本攻击。CSP是一种由开发者定义的安全性政策性申明，通过CSP所约束的的规责指定可信的内容来源（这里的内容可以指脚本、图片、 iframe、font、 style等等可能的远程的资源）。通过CSP协定，让WEB处于—个相对安全的运行环境中。

无论是反射型/存储型XSS都因为其 payload富于变化而难以被彻底根除。

而目前通过对输入输出的检测浏览器自身的 filter 对反射型XSS有了一定的检测能力，但是对于存储型XSS仍然缺乏一个有效通用解决方案。

内容安全策略（csp）将在未来的XSS防御中扮演着日渐重要的角色。但是由于浏览器的支持，XSS的环境复杂多变等问题，仍然会存在很多Bypass的方法。

XS-Leaks

跨站脚本泄漏（ Cross-Stie Leaks，又称XS- Leaks/ XSLeaks），是一类利用Web平台内置的侧信道衍生出来的漏洞。其原理是利用网络上的这种侧信道来揭示用户的敏感信息，如用户在其他网络应用中的数据、用户本地环境信息，或者是用户所连接的内部网络信息等。

浏览器提供了各种各样的功能来支持不同Web应用程序之间的互动；例如，浏览器允许一个网站加载子资源、导航或向另一个应用程序发送消息。虽然这些行为通常受到网络平台的安全机制的限制（例如同源政策），但XS- Leaks利用了网站之间互动过程中的各种行为来泄露用户信息。

既然是侧信道，那么这个信道从何而来呢？通常来说，这个信道需要结合题目设置的各种功能或者浏览器的某些特性，而往往这些功能或者特性对用户的返回只有两种回答，也就是类似SQL注入中布尔盲注攻击一样，只不过他放到了浏览器以及Web应用当中。举个简单例子，有这么一个搜索功能，对于用户搜索的内容如果存在，则返回200码，否则返回其他非200状态码响应，我们就可以从头挨个通过Web服务返回的状态码来判断自己传递的是否正确进而泄露Web服务当中的内容，于是我们还可以使用 onload等事件进一步进行自动化泄露。再举个小例子，在没有正确设置 SameSite的情况下，如果存在一些Web应用对于用户没有登录返回403，登录状态返回200，则可以一些跨域标签，比如 script可以依照这两种状态来判断用户是否登录。

XS-Leaks并不是说可以直接造成什么危害巨大的漏洞，它更侧重于Leak，侧重于信息泄露方面。并且造成大多数XS-Leaks的根本原因是网络设计上的问题，很多时候，web服务在没有漏洞的情况下就容易受到些信息泄露的影响。但是在浏览器层面修复XS-Leaks也是及其困难的，因为在许多情况下，会影响到很多现有的Web服务，会对原有的Web服务造成巨大的冲击。所以，要防御该类型的漏洞，通常是要使用各种严格的同源限制，才能达到预期效果。