【干货】XSS知识总结

本文深入探讨了XSS(跨站脚本)攻击的原理、分类、利用方式和常见防御手段,包括反射型、存储型和DOM型XSS。通过Fuzzing技术和代码审计来检测XSS漏洞,并介绍了XSS平台和工具,如BeEF和XSStrike。此外,还讨论了CSP、X-XSS-Protection等安全策略的绕过技巧,以及NoScript的Bypass方法,揭示了XSS攻击的复杂性和持续演变的态势。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

公众号:白帽子左一

XSS基础

跨站脚本(英语:Cross-site scripting,通常简称为:XSS)是一种网站应用程序的安全漏洞攻击,是代码注入的一种。它允许恶意用户将代码注入到网页上,其他用户在观看网页时就会受到影响。这类攻击通常包含了HTML以及用户端脚本语言。

XSS攻击通常指的是通过利用网页开发时留下的漏洞,通过巧妙的方法注入恶意指令代码到网页,使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript,但实际上也可以包括Java,VBScript,ActiveX,Flash或者甚至是普通的HTML。攻击成功后,攻击者可能得到更高的权限(如执行一些操作)、私密网页内容、会话和cookie等各种内容。

同源策略
同源策略是指在Web浏览器中,允许某个网页脚本访问另一个网页的数据,但前提是这两个网页必须有相同的URI、主机名和端口号,一旦两个网站满足上述条件,这两个网站就被认定为具有相同来源。此策略可防止某个网页上的恶意脚本通过该页面的文档对象模型访问另一网页上的敏感数据。

同源策略对Web应用程序具有特殊意义,因为Web应用程序广泛依赖于HTTP cookie来维持用户会话,所以必须将不相关网站严格分隔,以防止丢失数据泄露。

值得注意的是同源策略仅适用于脚本,这意味着某网站可以通过相应的HTML标签访问不同来源网站上的图像、CSS和动态加载脚本等资源。而跨站请求伪造就是利用同源策略不适用于HTML标签的缺陷。

举例:

在这里插入图片描述

跨域方法总结
HTML标签

<’script> 等带src属性的标签都可以跨域加载资源,而不受同源策略的限制。每次加载时都会由浏览器发送一次GET请求,通过src属性加载的资源,浏览器会限制JavaScript的权限,使其不能读写返回的内容。

常见标签:

<script src="..."></script>
<img src="...">
<video src="..."></video>
<audio src="..."></audio>
<embed src="...">
<frame src="...">
<iframe src="..."></iframe>
<link rel="stylesheet" href="...">
<applet code="..."></applet>
<object data="..." ></object>
document.domain

原理:相同主域名不同子域名下的页面,可以设置document.domain让它们同域
我们只需要在跨域的两个页面中设置document.domain就可以了。修改document.domain的方法只适用于不同子域的框架间的交互,要载入iframe页面。
例如:

在页面 http://a.example.com/a.html 设置document.domain

<iframe id = "iframe" src="http://b.example.com/b.html" onload = "test()"></iframe>
<script type="text/javascript">
    document.domain = 'example.com';//设置成主域
    function test(){
        alert(document.getElementById('iframe').contentWindow);//contentWindow 可取得子窗口的 window 对象
    }
</script>

2、在页面http:// b.example.com/b.html 中设置document.domain

<script type="text/javascript">
    document.domain = 'example.com';//在iframe载入这个页面也设置document.domain,使之与主页面的document.domain相同
</script>

Window.name

在javascript中,Window 对象表示浏览器中打开的窗口,而name属性可设置或返回存放窗口的名称的一个字符串。

window.name有一个奇妙的性质,页面如果设置了window.name,那么在不关闭页面的情况下,即使进行了页面跳转location.href=…,这个window.name还是会保留。

利用window.name的性质,我们可以在iframe中加载一个跨域页面。

这个页面载入之后,让它设置自己的window.name,然后再让它进行当前页面的跳转,跳转到与iframe外的页面同域的页面,此时window.name是不会改变的。

这样,iframe内外就属于同一个域了,且window.name还是跨域的页面所设置的值。

假设我们有3个页面,

a.com/index.html
a.com/empty.html
b.com/index.html

(1)在a.com/index.html 页面中嵌入一个iframe,设置src为b.com/index.html
(2)b.com/index.html 载入后,设置window.name,然后再使用location.href='a.com/empty.html’跳转到与iframe外页面同域的页面中。
(3)在a.com/index.html 页面中,就可以通过$(‘iframe’).contentWindow.name来获取iframe内页面a.com/empty.html 的window.name值了,而这个值正是b.com/index.html 设置的。

window.postMessage

window.postMessage(message, targetOrgin)方法是html5新引进的特性。
调用postMessage方法的window对象是指要接受消息的哪一个window对象,该方法的第一个参数message为要发送的消息,类型只能为字符串;第二个参数targetOrgin用来限定接收消息的那个window对象所在的域,如果不想限定域,可以使用通配符*。

需要接收消息的window对象,可是通过监听自身的message时间来获取传过来的消息,消息内容存储在该事件对象的data属性中。

location.hash

location.hash 方式跨域,是子框架具有修改父框架 src 的 hash 值,通过这个属性进行传递数据,且更改 hash 值,页面不会刷新。但是传递的数据的字节数是有限的。

详细参考:https://xz.aliyun.com/t/224#toc-3
a.html欲与b.html跨域相互通信,通过中间页c.html来实现。 三个页面,不同域之间利用iframe的location.hash传值,相同域之间直接js访问来通信。
具体实现步骤:一开始a.html给b.html传一个hash值,然后b.html收到hash值后,再把hash值传递给c.html,最后c.html将结果放到a.html的hash值中。

在这里插入图片描述

JSONP跨域

原理:

<script type="text/javascript">
    function dosomething(jsondata){
        //处理获得的json数据
    }
</script>
<script src="http://haorooms.com/data.php?callback=dosomething"></script>

后台代码:

<?php
$callback = $_GET['callback'];//得到回调函数名
$data = array('a','b','c');//要返回的数据
echo $callback.'('.json_encode($data).')';//输出
?>

跨域资源共享(CORS)

原理:服务器设置Access-Control-Allow-Origin HTTP响应头之后,浏览器将会允许跨域请求
CORS是HTML5标准提出的跨域资源共享(Cross Origin Resource Share),支持GET、POST等所有HTTP请求。CORS需要服务器端设置Access-Control-Allow-Origin头,否则浏览器会因为安全策略拦截返回的信息。

Access-Control-Allow-Origin: * # 允许所有域名访问,或者
Access-Control-Allow-Origin: http://a.com # 只允许所有域名访问

CORS又分为简单跨域和非简单跨域请求,有关CORS的详细介绍请看阮一峰的跨域资源共享 CORS 详解,里面讲解的非常详细。

CSP-内容安全策略
CSP(Content Security Policy)即内容安全策略,为了缓解很大一部分潜在的跨站脚本问题,浏览器的扩展程序系统引入了内容安全策略(CSP)的一般概念。这将引入一些相当严格的策略,会使扩展程序在默认情况下更加安全,开发者可以创建并强制

<think>好的,我现在需要向用户介绍XSS(跨站脚本攻击)。首先,我要确保自己准确理解XSS的概念、类型、危害以及防御方法,这样才能清晰地传达给用户。 首先,XSS的定义。XSS是一种安全漏洞,攻击者通过在网页中注入恶意脚本,当其他用户浏览该页面时,脚本会在他们的浏览器中执行。这可能导致数据窃取或会话劫持等。我需要用简单的语言解释清楚,避免使用太多技术术语,让用户容易理解。 接下来是XSS的类型。常见的类型有三种:反射型、存储型和DOM型。反射型XSS的恶意脚本来自当前HTTP请求,比如URL参数,然后服务器返回的页面中包含这些脚本。存储型XSS则是将恶意脚本存储在服务器上,比如数据库,当其他用户访问时触发。DOM型比较特殊,它不经过服务器,完全在客户端处理,通过修改DOM来执行恶意代码。这里需要举例说明每种类型,帮助用户区分。 然后是XSS危害。我需要列出几个主要危害,比如窃取用户Cookie、会话劫持、篡改页面内容、重定向到恶意网站、键盘记录等。每个危害都要简明扼要,让用户意识到问题的严重性。 防御措施部分,必须详细且实用。输入验证和过滤是关键,比如对用户输入的数据进行严格检查,过滤或转义特殊字符。输出编码同样重要,确保数据在输出到页面时不会被当作脚本执行。使用HTTP安全头,如Content-Security-Policy(CSP),可以限制脚本的来源。设置Cookie的HttpOnly和Secure属性,避免被JavaScript访问。使用安全的框架和库,比如前端框架自带的安全机制,避免手动操作DOM。定期安全测试,比如渗透测试和代码审计,也是必要的步骤。 在组织内容时,要遵循用户的要求,结构清晰,分点说明。同时,检查是否遵循了系统级指令,比如数学公式是否正确使用$...$,独立公式用$$...$$,但这里可能涉及较少数学内容,不过需要注意如果有变量或代码部分也要正确使用格式。使用中文,确保语法正确。 可能需要考虑用户的知识水平,避免过于技术化,但又要足够详细,让用户理解XSS的原理和防御方法。是否需要补充示例?比如反射型XSS的例子,比如一个带有恶意脚本参数的URL,用户点击后触发。存储型的例子如在评论区插入脚本,其他用户查看评论时执行。DOM型如通过修改URL的hash部分触发脚本。 还需要检查是否有遗漏的重要信息,比如XSS与其他攻击的区别,比如CSRF,但用户只问了XSS,所以可能不需要展开。此外,是否需要提到现代浏览器内置的XSS防护机制,比如X-XSS-Protection,但该头已被CSP取代,所以可能提到CSP更有效。 最后,确保回答真实可靠,引用权威的安全建议,如OWASP的推荐措施。避免错误,比如转义字符的具体方法,比如将<转义为<,>转义为>等。 总结结构应该分为定义、类型、危害、防御措施四个部分,每个部分分点说明,使用中文,结构清晰。同时注意格式要求,比如行内代码或变量用$...$,但XSS本身不是数学公式,可能不需要,但如果有变量如<script>可能需要用代码块或引号,但系统指令主要针对数学表达式,所以可能不需要特别处理。不过还是需要确认是否有需要LaTeX的地方,比如变量名如CSP,可能不需要,所以主要使用普通文本即可。 现在组织内容: 1. 定义:解释XSS是什么,攻击方式。 2. 类型:反射型、存储型、DOM型,各举例子。 3. 危害:窃取信息、会话劫持等。 4. 防御:输入验证、输出编码、CSP、安全Cookie、框架、测试。 检查是否有错误,比如DOM型是否真的不需要服务器参与,是否正确。是的,DOM型完全在客户端处理,比如基于URL中的片段或本地存储的数据修改DOM,触发脚本执行。 最后确保语言口语化,但结构清晰,符合用户要求的中文回答。</think>### XSS(跨站脚本攻击)介绍 #### 1. **定义** XSS(Cross-Site Scripting,跨站脚本攻击)是一种网络安全漏洞,攻击者通过向网页注入恶意脚本(如 JavaScript),当其他用户浏览该页面时,脚本会在其浏览器中执行。XSS 的核心目标是绕过“同源策略”,窃取用户敏感信息或劫持会话。 --- #### 2. **攻击类型** XSS 分为三种主要类型: - **反射型 XSS** - **原理**:恶意脚本来自用户的 HTTP 请求(如 URL 参数),服务器直接将其返回页面中执行。 - **示例**: ```url http://example.com/search?q=<script>alert('XSS')</script> ``` 若服务器未过滤参数 `q`,用户点击此链接时会弹出警告框。 - **存储型 XSS** - **原理**:恶意脚本被永久存储在服务器(如数据库、评论区),当其他用户访问页面时触发。 - **示例**:在论坛评论中提交 `<script>stealCookie()</script>`,所有查看该评论的用户都会执行此脚本。 - **DOM 型 XSS** - **原理**:完全在客户端触发,通过修改 DOM 环境(如 URL 片段、本地存储)执行恶意脚本,无需服务器参与。 - **示例**: ```javascript // 假设页面通过以下代码显示 URL 中的内容 document.write(location.hash.substring(1)); ``` 攻击者可构造 URL:`http://example.com#<script>maliciousCode()</script>`。 --- #### 3. **危害** XSS 可导致以下风险: - **窃取 Cookie**:获取用户登录凭证。 - **会话劫持**:冒充用户执行操作(如转账)。 - **页面篡改**:插入虚假内容或钓鱼表单。 - **重定向攻击**:跳转到恶意网站。 - **键盘记录**:监控用户输入。 --- #### 4. **防御措施** - **输入验证与过滤** - 对用户输入的数据进行严格检查(如长度、格式),过滤 `<script>`、`onerror` 等危险标签或属性。 - **输出编码** - 将用户输入的内容转义后再输出到页面。例如: - `<` 转义为 `<` - `>` 转义为 `>` - **使用 Content-Security-Policy (CSP)** - 通过 HTTP 头限制脚本来源,禁止内联脚本: ```http Content-Security-Policy: default-src 'self' ``` - **设置安全 Cookie** - 添加 `HttpOnly` 和 `Secure` 属性,防止通过 JavaScript 窃取: ```http Set-Cookie: sessionId=abc123; HttpOnly; Secure ``` - **避免直接操作 DOM** - 使用安全的框架(如 React、Vue)自动处理编码,避免 `innerHTML` 或 `document.write()`。 - **定期安全测试** - 通过工具(如 OWASP ZAP、Burp Suite)扫描漏洞,进行代码审计。 --- #### 5. **总结** XSSWeb 安全中最常见的漏洞之一,防御需结合输入过滤、输出编码、CSP 等多层措施。开发者应遵循“不信任用户输入”原则,并持续更新防护策略以应对新型攻击手法。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值