我有以下情况:
让我们有一个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页,关于输入编码的部分