PCI 合规性的资源/服务？修复“类别参数中的跨站脚本漏洞”漏洞？

Posted 2023-02-22

【中文标题】PCI 合规性的资源/服务？修复“类别参数中的跨站脚本漏洞”漏洞？

【英文标题】：Resources/services for PCI compliance? Fix for "Cross-site scripting vulnerability in category parameter" vulnerability?

【发布时间】：2011-09-02 21:11:09

【问题描述】：

一家审计公司表示我们不符合 PCI 标准，但提供了有关如何解决问题的无益说明。他们显然希望我们与他们的咨询部门合作。

在收到 PCI 合规性审计警报后，您使用了哪些资源/服务来填补空白？

是否有网站提供有关解决 PCI 合规性问题的有用资源？

例如，这是我们被标记的神秘失败消息之一：

“描述：URL X 的类别参数中的跨站脚本漏洞”

但是对于如何关闭这个漏洞没有明确的指导。

谢谢。

【参考方案1】：

他们是说哪个 URL 导致了漏洞，还是字面上的“X”？

检查以确保没有任何用户输入或从 URL 中获取的输入显示在页面上的任何位置（或在您的 javascript 中使用）而未经适当清理。

如果您发布 URL，我相信这里的人们会很乐意寻找漏洞。

[在您发布 URL 后编辑：]

这是显示漏洞的格式错误请求的链接：

http://www.cengraving.com/s/category?category=Outdoor+signs+'-'alert("Cross%20Site%20Scripting%20Vulnerability%20Here");

防止这种攻击的一种方法是验证所有用户输入。

客户端您可以删除任何可疑字符，例如 '"-

在将有效查询输入数据库之前，您应该使用正则表达式将有效查询列入白名单。

【讨论】：

这里是完整的消息：“跨站点脚本漏洞在类别参数到 /s/category;jsessionid=6D8425AEB28A1C87D234AE3D97270C6B”其中唯一的查询参数是这样的，“?category=Brass+plates "

@Crashalot，您是否在页面某处显示该“类别”？如果是这样，有人可以将其更改为类似 '?category=' 的内容，这就是导致漏洞的原因

是的，参数是一个类别ID，我们用来标识要显示哪个类别。你是说我们需要改变我们的 URL 结构来关闭这个漏洞？我们不会在带有参数的页面上执行任何 Javascript。该参数在后端读取并索引到我们的数据库中。

确保在将 categoryID 放入数据库之前在后端对其进行清理，否则有人可能会使用它进行注入攻击。不管是不是在javascript中使用，如果直接显示在页面上，可能会被畸形执行任意客户端代码，因此存在XSS攻击的可能性

将会话 ID 放在 URL 中也不是一个好习惯，因为它可能被利用来劫持用户的会话。会话应该在服务器端处理，这是一个简单的调整，具体取决于您使用的平台