WEB安全实战（五）XSS 攻击的另外一种解决方案（推荐）

本文链接：https://blog.csdn.net/happylee6688/article/details/41314351

本文探讨了XSS攻击的传统防护措施存在的局限，并详细介绍了全新的解决方案，旨在增强WEB应用的安全性，降低XSS漏洞风险。

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

序

说到 XSS 攻击，前边已经有两篇文章在讲这个事了，这次又拿出来说，主要是针对最近工作中的一些新的问题。那么之前是怎么解决这个问题的呢？为什么又要换解决方案？下面就详细的跟大家分享一下。

旧方案

公司的测试团队发现这个问题之后，就要求尽快的解决，在网上查了很多相关的资料，也翻阅了基本安全方面的书，基于 XSS 的攻击原理，自己写了一个 Filter，并在该 Filter 中加入了对各种请求的处理代码。首先是拦截浏览器发出的请求，然后对拦截到的请求进行过滤，获取参数列表，参数值列表（包括表单提交），然后对这些参数值进行危险字符的过滤处理，处理的过程中分为两种情况。

其中一种是把危险字符进行转换，保留原来的语意，在适当的时候进行还原，当然，这种情况下危险字符还是存在的，只不过是换了一种相对安全的形式。这种情况的好处是，保证了请求的原始性，但是对数据库或文件系统产生一些不必要的垃圾信息。为什么这么说呢，因为普通的用户在正常的操作下是不会包含这些非法字符的，只有在非法入侵的情况下才会出现这种情况，而对于危险字符的转换就是一种间接的保护措施。

对于第二种情况，不是对危险字符进行转换，而是把请求中的危险字符进行过滤，使得请求纯净化，把非法的字符过滤掉，这样以来，进入数据库或文件系统的就仅仅是合法的语句。这种情况也会有他的利弊。比如，在过滤的过程中，可能把用户的某些正常请求参数值也给清理掉，这样就不能保证请求的原始性。但系统的安全性方面却大大的提高了。为了避免用户的请求失真，我们能做的就是尽量的避开用户可以输入的特殊字符，在注册、登录、或者其他的请求中，规定用户可以使用的特殊字符，对那些不提倡使用的字符进行过滤和处理。