旧网站存在安全问题如何处理？

Posted 2023-02-16

【中文标题】旧网站存在安全问题如何处理？

【英文标题】：How to deal with old web site with security issues?

【发布时间】：2011-02-11 17:01:20

【问题描述】：

我最近登陆了一个旧的网络应用程序，里面充满了老派的把戏

GET 参数：URL 参数中的用户信息 会话信息 用于存储信息的隐藏元素 html/JS/CSS 转储到页面中。没有适当的编码。等 Window.open 以显示弹出窗口。 XSS 问题等 连接的 SQL 字符串适用于盲目 SQL 攻击。

还有更多...

让事情顺利进行。看起来应用程序在过去 5-7 年（ASP.NET 1.1）已经过时，并且看起来应用程序代码未能跟上更好的安全实践的步伐。

值得庆幸的是，随着时间的推移，浏览器和安全测试工具似乎发展得非常好。帮助人们/客户时不时地报告如此多的安全问题。让他们开心并确保系统安全已成为痛苦。

如果您遇到类似的事情，有人可以告诉我，并帮助我进行一些案例研究或如何解决这个问题？ “免费”可用的测试工具可用于在开发人员环境中测试网站的安全性？应该使用什么策略来处理这种情况？如何进步。

【参考方案1】：

首先让我这样说：虽然有开源和免费的安全扫描工具，但没有一个是完美的。根据我的经验（至少使用 php），它们往往会返回足够多的误报，以至于几乎不值得运行它们（但自从我上次使用它们以来，情况可能会变得更好）。如果您想使用一个来帮助识别问题，请务必这样做。但不要相信任何一种方式的输出（从假阳性和假阴性的角度来看）。

至于如何解决它，我建议采用循序渐进的方法。选择一种类型的漏洞，并在整个应用程序中消除它。然后转到下一个漏洞类型。因此，一个潜在的游戏计划可能是（按严重程度和修复难易程度排序）：

修复所有 SQL 注入漏洞。

浏览代码，找到它执行 SQL 查询的所有位置，并确保它们使用的是准备好的语句并且没有任何东西可以进入。

修复所有 XSS 漏洞

查找所有本地信息（用户提交或其他方式）被正确清理和转义的地方（取决于用例）。

修复所有 CSRF 漏洞

浏览网站并确保所有表单提交都正确使用 CSRF 令牌系统来保护它们免受欺诈性请求。

修复所有身份验证和会话修复漏洞

确保身份验证和会话系统不会被滥用。这涉及确保您的 cookie 是干净的，并且任何会话标识符都经常轮换。并确保您正确存储密码...

修复和信息注入漏洞

您声明在 URL 和隐藏的表单元素中有用户信息。遍历所有这些并更改它，以便用户不能在他们不应该能够的地方注入值。如果这意味着将数据存储到会话对象中，请这样做。

修复所有信息泄露漏洞

这与前一点有关，但略有不同。如果您在 URL 中使用了用户名，但无法通过更改它来做任何事情，那么这不是注入漏洞，它只是一个泄露问题。将这些清理干净，但它们并不那么重要（当然取决于所披露的内容）。

修复输出

修复编码问题和任何可能产生无效输出的方法。确保输出时一切正常。

需要注意的重要一点是，您修复的任何内容都会使应用程序更安全。如果它现在是实时应用程序，请不要等待！不要试图做所有事情，测试和发布。选择一个合理大小的目标（最多 2 到 4 天的工作），完成目标，测试并发布。然后冲洗并重复。通过迭代这个庄园中的问题，您可以使站点在您前进的过程中越来越安全。对您来说，这似乎工作量减少了，因为总会有尽头。

现在，如果应用程序足够严重，可能需要完全重写。如果是这种情况，我仍然建议在开始重写之前至少清理现有应用程序中的重要项目。在执行任何其他操作之前，至少要清理 SQL 注入、XSS 和 CSRF 漏洞。

这不是一件容易的事。但是一次吃一小口，您可以在在水面上保持显着进步......任何一点都会有所帮助，所以将旅程视为一系列步骤而不是整体。你最终会过得更好...

【参考方案2】：

好吧，每个问题的谷歌都会帮助解决它，所以我假设你只是担心实际风险。

这很容易解决，只需更改为$_POST，它更安全一点，尤其是与会话令牌一起使用时。 这仍然被广泛使用，所以我认为没有问题？ 嗯，只要在服务器端检查该数据，如果没有验证，用户必须重新登录或类似的，这是可以接受的。当然，首选 session，甚至是 cookie。 整理只是一项漫长的工作，除非在 JS 中显示密码等，否则没有任何问题。 Css + html 几乎总是未编码，所以这看起来很好。 我只是不喜欢弹出窗口，从不使用它们，在这里帮不上忙。 好吧，如果可能的话，在本地托管脚本，并通过剥离标签、URL 编码之类的方式清理任何必要的 XSS。

【参考方案3】：

几年前我在一个电子商务网站上遇到过这种情况。它在 ASP.NET 1.1 中，在代码质量和安全实践方面绝对令人震惊。此外，管理层告诉我，重写是绝对不可能的，并且无法说服他们让步。

在 2 年的时间里，我设法让这个系统符合 PCI-DSS。这意味着我们必须一一关闭所有这些安全漏洞，并采取措施确保它们不会再次发生。

第一个问题是你必须找到所有的错误和安全漏洞。你可以使用外部漏洞探测工具（我推荐QualysGuard）。但是手动测试是获得完整覆盖的唯一方法。编写老式的测试脚本来测试 XSS、SQL 注入、CSRF 等，并在测试人员的帮助下运行这些脚本。如果您可以使这些测试自动化，那是非常值得的。但是不要仅仅因为它太难自动化就避免覆盖测试用例。如果您负担得起安全顾问的费用，请让他们帮助您确定测试覆盖范围并编写测试用例。

这将为您提供： a) 错误/缺陷列表 b) 一种可重复的方式来测试您是否真的修复了每个人

然后你就可以开始重构和修复每个缺陷了。

我遵循的过程是： 第 1 步：重构，第 2 步：测试和发布，第 3 步：返回第 1 步。 IE。有一个固定、测试和发布的连续循环。我建议您承诺定期部署到您的生产系统，例如每月一次，并在每个发布周期中尽可能多地进行“重构”。

我发现自动化安全工具几乎没用，因为： a) 他们会给你一种虚假的安全感 b) 他们会给你很多误报，以至于你被无意义的切线送走，而不是处理真正的安全威胁。

您确实需要掌握每个安全漏洞的性质并准确了解其工作原理。这样做的一个好方法是研究每个缺陷（例如，从 OWASP 前 10 名开始），并编写一份文档，您可以将其提供给团队中的任何开发人员，向他们准确解释您要保护的每个缺陷是什么反对以及为什么。我认为我们经常寻求工具来帮助修复安全漏洞，认为我们可以避免真正了解每个威胁的努力。一般来说，工具只对提高生产力有用 - 你仍然需要负责并运行节目。

资源：

1)阅读OWASP top 10。

2)PCI-DSS 规范也是非常好的东西，它可以帮助您从整体上考虑安全性 - 即涵盖的方式不仅仅是 Web 应用程序，还包括数据库、进程、防火墙、DMZ/LAN 分离等。即使它结束了满足您的要求的顶部，非常值得浏览。