关于防止xss攻击使用xss.js出现的一些报错

博客介绍了在浏览器端使用xss.js过滤script脚本时遇到的问题,如加载报错、方法未定义等,最终通过从git下载项目拷贝js解决。同时指出仅前端过滤xss攻击不够,还需在后端加一层过滤,前端设置可减少后端操作。

我们在看使用前台过滤script脚本的时候使用到了xss.js,在它的官方文档中写了这样的一段使用说明:

在浏览器端使用

Shim模式(参考文件 test/test.html):

<script src="https://raw.github.com/leizongmin/js-xss/master/dist/xss.js"></script>
<script>
// 使用函数名 filterXSS,用法一样
var html = filterXSS('<script>alert("xss");</scr' + 'ipt>');
alert(html);
</script>

如果按照这段使用说明来测试这个短代码的时候是会报如下的错误,

Refused to execute script from 'https://raw.githubusercontent.com/leizongmin/js-xss/master/dist/xss.js' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled.

这个是因为你没有给type类型没写或者是写错了,按提示应给成text/plain的类型,但是修改过来,你以为就可以了,你想错了!

但是经过测试,即使这里不报错了可以正常加载了但是使用它的filterXss的方法的时候还是会报错,

Uncaught ReferenceError: filterXSS is not defined
    at new_file.html?__hbt=1562816031213:12

说你的这个filterXss的方法没有定义,这个应该还是没哟加载xss.js

原本想直接就引用它的js了,省的还得访问自己的静态资源,节省带宽,也许人家的访问速度比咱还快,最后还是被现实给打败了,不能用啊!

所以我最后把他js_xss的项目从git下载下来,直接从它的项目中拷贝一份js放在自己的项目中,然后再想一开始那样引用就没有问题了

当然了,我认为光从前端过滤xss攻击还是不可以的,当他给你通过接口直接提交参数的时候你的前端xss就不会过滤,

所以还是需要在后端加一层xss过滤,前端设置只是为了减少后端的过多操作。

<think>嗯,用户这次问得很具体:能否通过简单检测尖括号<和>来防止XSS注入。这其实是个典型的"过度防御"思路,让我结合之前的XSS讨论和站内引用分析一下。 用户可能是个Java后端开发者,从引用[3]看到XSS过滤器的配置方式,想找个最简单的解决方案。但ta忽略了关键点:现代Web应用需要合理处理合法尖括号(比如数学公式中的不等号),直接报错会误伤正常用户。 仔细看引用[1]对XSS原理的解释:攻击本质是让浏览器执行恶意脚本,而不仅仅是存在尖括号。引用[2]提到CheckXSS工具的正则匹配原理,正好说明单纯字符检测的局限性——攻击者完全可以用img的onerror属性执行JS而不依赖尖括号,比如:<img src=x onerror=alert(1)> 更麻烦的是,引用[4]展示的JSON注入案例说明,攻击向量可能藏在数据结构里。如果只在前端检查尖括号,攻击者完全可以通过API直接传{"payload":"\u003cscript\u003e"}这样的Unicode编码绕过。 不过用户思路有可取之处:在特定场景下(如纯文本输入框),禁止尖括号确实能阻断大部分基础XSS。但需要补充三点:1) 必须配合输出编码 2) 要处理Unicode等绕过 3) 对富文本要改用白名单。就像之前回复强调的,多层防护才可靠。 突然想到个典型反例:数学论坛必须允许用户输入不等式(如 x<y ),如果按用户方案直接报错,这网站根本没法用。所以最后决定用对比表格说明不同场景的处理方案,既肯定ta的防御意识,又引导ta理解上下文敏感处理的重要性。</think>防止XSS注入**不能简单地通过检测到`<`或`>`字符就报错**,这种方案虽直观但存在严重缺陷。以下是详细分析和更优方案: --- ### 一、为什么不能直接禁止`<`或`>`? #### 1. **误杀合法输入** 许多场景需正常使用尖括号: - 数学公式:`x < y` 或 `a > b` - 代码示例:`if (a < b) {...}` - 文本内容:`"引用<原文>"` **直接报错会破坏功能,影响用户体验**。 #### 2. **绕过风险高** 攻击者可通过多种方式绕过检测: - **编码绕过**: 使用HTML实体编码:`<script>` → 浏览器解析为`<script>` - **Unicode/URL编码**: `\u003cscript\u003e` 或 `%3Cscript%3E` - **无尖括号攻击**: 如:`<img src="x" onerror=alert(1)>`(依赖事件属性,无需闭合标签) #### 3. **无法覆盖所有XSS类型** - **DOM型XSS**: 通过`location.hash`或`document.write`注入,无需服务端解析尖括号[^1]。 - **JSON注入**: 如引用[4]中的案例:`{"id": "1; alert(1)"}`,不依赖尖括号[^4]。 --- ### 二、更有效的防护方案(结合站内引用) #### 1. **输入验证 + 白名单机制**(推荐) - **允许特定字符**:对输入类型分类处理(如数字字段仅允许数字)。 - **富文本场景**: 使用白名单标签/属性(如仅允许`<b>`、`<i>`),参考引用[3]的过滤器设计[^3]: ```java // 示例:XSS过滤器配置(引用[3]) <filter> <filter-name>xssFilter</filter-name> <filter-class>cn.parent.xss.XssFilter</filter-class> </filter> ``` **原理**:移除非白名单内容(如`<script>`),保留合法尖括号。 #### 2. **输出编码**(关键防线) - **上下文相关编码**: | 输出场景 | 编码方式 | 示例 | |----------------|-------------------|--------------------------| | HTML正文 | HTML实体编码 | `<` → `<` | | HTML属性 | 属性编码 | `"` → `"` | | JavaScript | Unicode转义 | `"` → `\u0022` | - **工具自动化**: 使用库如`OWASP Java Encoder`避免手动处理遗漏。 #### 3. **正则优化(若需检测)** 若需检测尖括号,应结合上下文并处理绕过: ```regex <!-- 检测未编码的尖括号,但允许合法使用 --> (?<!<|>|&)[<>](?!\w) ``` **仍需配合输出编码**,因正则难以覆盖所有编码变体[^2]。 #### 4. **综合防护** - **内容安全策略(CSP)**: 通过HTTP头限制脚本来源:`Content-Security-Policy: default-src 'self'`。 - **X-XSS-Protection**: 启用浏览器内置过滤(虽已淘汰,可作补充)。 --- ### 三、各方案对比 | 方案 | 安全性 | 误杀率 | 适用场景 | |--------------------|--------|--------|-----------------------| | 直接禁止`<`/`>` | ❌ | 高 | 几乎无 | | 输入白名单 | ★★★★ | 低 | 富文本编辑器 | | 输出编码 | ★★★★★ | 零 | 所有动态内容输出场景 | | CSP | ★★★★ | 零 | 全站防护 | > 💡 **结论**: > **输出编码是黄金标准**,结合输入白名单和CSP可近乎免疫XSS。单纯检测尖括号报错是一种脆弱且不可行的策略。 --- ### 相关问题 1. 在富文本编辑场景中,如何安全地允许用户输入HTML标签? 2. 如何通过内容安全策略(CSP)有效防御XSS攻击? 3. 输出编码在不同上下文(HTML/JS/URL)中的具体实现差异是什么?
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

枣泥馅

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值