【JAVA代码审计】————4、XSS

本文深入解析跨站脚本(XSS)攻击的原理及三种类型:反射型、存储型和DOM型XSS,探讨其执行条件与表现形式,并提供有效的输入与输出验证修复策略。

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

前言

最近几天比较忙,没有连载文章,今天正好有时间就写写吧,连载的都是基础的漏洞,大神路过留个脚印就可以撤了,哈哈,俗话说不喜勿喷,那咱们就开干!

跨站脚本(XSS)原理

先看下百度百科对XSS的介绍:

跨站脚本攻击(Cross Site Scripting),为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆,故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意Script代码,当用户浏览该页之时,嵌入其中Web里面的Script代码会被执行,从而达到恶意攻击用户的目的。

事实上XSS可以分为以下三种类型:

1.反射型XSS

反射型XSS也被称为非持久性XSS,一般反射型XSS是用户直接在URL中提交一段可执行代码,最后直接在页面中输出,页面将提交的代码执行,形成XSS攻击,一般单纯的反射型XSS危害并不大,但是当XSS遇上跨站请求伪造(CSRF)就会形成可怕的蠕虫。

2.存储型XSS

存储型XSS又被称为持久性XSS,存储型XSS是恶意用户输入的可执行代码直接保存在数据库中,最后在某个页面被调用显示出来,最后执行。存储型XSS相对来说危害就非常大,一般恶意用户可通过存储型XSS去盗窃管理员的Cookie,从而获取管理员权限。

3.DOM型XSS

DOM,即文档对象模型(Document Object Model,简称DOM),是W3C组织推荐的处理可扩展标志语言的标准编程接口。DOM型XSS其实是一种特殊的反射型XSS,可能触发的DOM型XSS属性包括但不限于:document.location、document.URL、document.referrer、window.location......

下面详细介绍此三种XSS:

反射型XSS

反射型XSS的执行条件有以下几点:

1.传递参数为用户可控,简单页面如下:

其中搜索框种的值即为可控参数,在URL中表现形式如下:http://localhost:8080/javatest/searchword?word=

2.参数未经过任何过滤或者过滤不完全,最终直接显示在前端页面,形式如下:

此处参数在前端为EL表达式获取,并且为添加任何过滤,最后直接显示在页面。

反射型XSS的表现形式

当输入框输入的参数为:<script>alert(1)</script>  时,就会直接被浏览器当作脚本执行:

URL表现形式:http://localhost:8080/javatest/searchword?word=%3Cscript%3Ealert%281%29%3C%2Fscript%3E

最后弹框:

存储型XSS

存储型XSS的执行条件有以下几点:

1.传递参数为用户可控,简单页面如下,这是一个简单的增加用户界面,文本框中的参数都为用户可控:

2.参数在传递过程中未经过任何有效过滤(或者存在过滤不全,会被绕过),并且能够存储在数据库中,代码如下:

3.在前端页面会显示用户存储的数据,并且未做任何输出过滤(或者过滤不全),页面和代码如下:

存储型XSS的表现形式

在添加用户处输入:<script>alert(1)</script>

数据库中存储的形式如下:

当数据显示在页面,就会执行脚本:

DOM型XSS

DOM型XSS的原理其实和反射型XSS差别并不大,只是可控参数拼接在DOM标签输出,页面如下:

此处a’为可控参数,当‘a’为123456789 时:

a’为<img src=1 onerror=alert(1)>时:

XSS的修复

XSS的修复大概分为两种形式,一种为输入验证,一种为输出验证:

1.输入验证,添加全局过滤器,对特殊字符进行过滤,包括(但不限于):

   |(竖线符号)

Ø & (& 符号)

Ø ;(分号)

Ø $(美元符号)

Ø %(百分比符号)

Ø @(at 符号)

Ø '(单引号)

Ø "(引号)

Ø \'(反斜杠转义单引号)

Ø \"(反斜杠转义引号)

Ø <>(尖括号)

Ø ()(括号)

Ø +(加号)

Ø CR(回车符,ASCII 0x0d)

Ø LF(换行,ASCII 0x0a)

Ø ,(逗号)

Ø \(反斜杠)

Ø eval方法

Ø document

Ø cookie

Ø javascript

Ø script

Ø onerror

过滤形式如下(注意大小写):

代码中,获取过滤后的参数,再执行数据库操作:

2.输出验证,对输出的参数做编码过滤,此处不写了,方法大同小异。

过滤后输出截图:

结论

累死了,今天就写这么多吧,写的不好或者有错误之处,多多指教,谢谢!

转自:i春秋

### 如何修复反射型 XSS 漏洞的最佳实践 为了有效防止反射型 XSS 攻击,开发者应遵循一系列严格的安全编码原则和技术手段。以下是针对反射型 XSS 的具体修复方法: #### 输入验证与过滤 输入数据的验证和过滤是抵御反射型 XSS 的基础措施之一。任何来自用户的输入都可能被攻击者利用来注入恶意脚本。因此,在接收用户输入时,应对特殊字符进行转义处理[^2]。 例如,可以采用 HTML 实体编码的方式对特定字符(如 `<`, `>`, `"`, `'` 和 `&`)进行转换: ```java String safeInput = input.replaceAll("&", "&") .replaceAll("<", "<") .replaceAll(">", ">") .replaceAll("\"", """) .replaceAll("'", "'"); ``` 这种做法能够确保潜在危险的 HTML 标记不会被执行而是作为普通的文本显示[^4]。 #### 输出编码 除了在服务器端做好输入过滤外,还需要关注输出阶段的数据安全性。当动态生成网页内容时,应该依据上下文环境应用合适的编码机制。比如对于 JavaScript 上下文中嵌入变量的情况,则需额外注意字符串拼接方式可能导致的风险[^1]。 一种推荐的做法是在模板引擎或者视图层实现自动化的输出转码功能。以 JSP 页面为例: ```jsp <%= org.apache.commons.lang.StringEscapeUtils.escapeHtml4(userProvidedData) %> ``` 这里调用了 Apache Commons Lang 提供的一个工具类来进行标准 HTML 转义操作[^3]。 #### 使用 Content Security Policy (CSP) Content Security Policy 是现代浏览器支持的一种防护技术,通过指定 HTTP 响应头部中的策略指令集,限制哪些资源可以从外部加载以及执行何种类型的脚本代码。启用 CSP 后即使存在某些未修补好的漏洞点也能极大程度上减少危害范围。 配置样例如下所示: ```http Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; ``` 此设置表明只允许从当前域名本身或信任的内容分发网络获取并运行脚本文件。 #### 利用现有库加强保护 考虑到手动编写正则表达式可能存在遗漏之处,建议引入成熟的第三方开源项目辅助完成防 Xss 工作流程。像 OWASP ESAPI 或 HtmlPurifier 这样的解决方案提供了经过广泛测试的功能模块可以直接集成到应用程序当中去增强整体健壮性。 综上所述,综合运用上述几种方法即可构建起较为完善的防线对抗反射型 XSS 威胁。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值