我有以下情况：
让我们有一个REST API和一个POST端点，例如：POST /users。然后我将以下请求主体发送到此端点：
{
"data": {
"firstname": "<script>alert('John')</script>",
"lastname": "<script>alert('Doe')</script>"
}
}然后，这些数据被保存到usersSQL表的firstname和lastname列中。
现在我有了一个简单的PHP Web应用程序（一个经典的、非单页的、服务器端呈现的PHP Web应用程序），它也可以访问这个users表。现在，当他拉出上面插入的firstname和lastname，然后将它们呈现到HTML视图时，<script>标记也会呈现，<script>标记之间的代码将在浏览器中运行，因此将显示警报。显然，我不希望这样，因为这是一个XSS漏洞。问题是，避免这种漏洞的正确方法是什么：
1.在后端对POST请求进行清理-因此在将数据保存到DB之前，从数据中转义<script>标记
或
1.不要在后端对POST请求进行清理--因此将带有<script>标记的数据按原样保存保存到DB中。然后，当PHP webapp从DB加载数据时，他应该在将数据呈现给HTML视图之前转义<script>标记。
在我看来，第二种方法是正确的方法，因为XSS只是前端的问题，然而，REST API端点也可以从非前端应用程序调用，在非前端应用程序中，通过转义<script>标记来避免XSS漏洞是无关紧要的。也许，有些服务需要从后端获取完整的HTML代码，而不仅仅是它的转义版本。但你觉得呢？
太感谢你了！
2条答案
按热度按时间iqih9akk1#
你是对的，通常你会想：
1.在存储之前检查传入的数据（例如，这是否是真实的电子邮件地址？）
1.在输出前转义
转义应该总是在
INSERT之前发生，因为在INSERT语句中你不知道它应该如何转义。也许您的数据只显示在HTML中，但也许以后您也希望相同的数据显示在.csv导出中。JSON文件、HTTP头、URL。每种格式都有自己的转义规则。dly7yett2#
您应该在后端（当数据存储到数据库或其他存储层时）和前端上进行两者清理。
将XSS代码存储在后端并不是一种常见的做法，即使是OWASP XSS Cheatsheet says：“框架可以很容易地确保变量被正确验证和转义或清理。
然而，框架并不完美，在React和Angular等流行框架中仍然存在安全漏洞。输出编码和HTML清理有助于解决这些差距。”
React XSS Protection Guide说道：“检查从服务器或第三方API流入应用程序的所有数据。这可以缓冲您的应用程序免受XSS攻击，有时，您也可以防止它。
有很多不同的原因。
1.你可以开始使用另一个没有很好地实现XSS检查的UI（然后在后台进行清理肯定会有帮助）
1.在你的UI框架的未来版本中会有一个漏洞或后门（几率有多大？有人听说过log4shell吗？）.
1.其他一些应用程序可能会开始连接到您的数据库，或者您可能会将数据导出到它们（如果这些数据包含恶意代码，没有人会感激）
1.您正在使用其他一些用于builds或应用格式的日志演示的Web应用程序，它将受到这些攻击的尊敬。
1.可能存在潜在的法律问题，因为在某些司法管辖区，存储或传输恶意代码可能违反法律。
1.在数据库中存储文本。“如果它存储在数据库中，开发人员将不得不清理该文本无论如何。在同一个地方同时进行XSS和结构化查询语言（SQL）注入过滤通常可以保存很多痛苦，因为开发人员必须已经在输入时进行SQL注入过滤。
1.“输入编码还有一个优点。输入编码可以成为所有滤波的中心位置，这确保了所有滤波都有一个瓶颈，而不是许多输出滤波器位置。
[1]：“跨站脚本攻击Xss漏洞利用和防御”，第401页，关于输入编码的部分