WinForms 应用程序的常见漏洞

Posted 2023-02-19

【中文标题】WinForms 应用程序的常见漏洞

【英文标题】：Common vulnerabilities for WinForms applications

【发布时间】：2012-07-05 23:52:13

【问题描述】：

我不确定这是否是主题，但它是如此特定于 .NET WinForms，我相信它在这里比在 Security stackexchange 站点更有意义。

（此外，它与 安全编码 密切相关，我认为它与我在整个网站上看到的任何关于常见网站漏洞的问题一样热门。） em>

多年来，我们的团队一直在对网站项目进行威胁建模。我们模板的一部分包括 OWASP 前 10 名以及其他众所周知的漏洞，因此在进行威胁建模时，我们始终确保我们有一个记录在案的流程来解决这些常见漏洞中的每一个。

例子：

SQL 注入（Owasp A-1）

标准实践 尽可能使用存储参数化过程来访问数据 如果存储过程不可行，请使用参数化查询。 （使用我们无法修改的第 3 方数据库） 仅当上述选项不可行时才转义单引号 数据库权限必须按照最小权限原则设计 默认情况下，用户/组无权访问 在开发过程中，记录每个对象（表/视图/存储过程）所需的访问权限以及访问权限的业务需求。 [剪辑]

无论如何，我们使用 OWASP Top 10 作为网站特定漏洞的起点。

（最后是问题）

在极少数情况下，当 Web 应用程序不能满足需求时，我们会开发 WinForms 或 Windows 服务应用程序。我想知道是否有针对 WinForms 应用程序的常见安全漏洞的等效列表。

我脑海中浮现出一些....

SQL 注入仍然是一个问题。 缓冲区溢出通常由 CLR 防止，但如果将非托管代码与托管代码混合使用则更有可能 .NET 代码可以反编译，因此将敏感信息存储在代码中，而不是在 app.config 中加密...

是否有这样的列表，或者甚至是这样的列表的多个版本，我们可以从中借用来创建自己的列表？如果是这样，我在哪里可以找到它？

我一直没找到，但如果有的话，对我们以及其他 WinForms 开发人员都会有很大帮助。

【问题讨论】：

这是一个非常有趣的问题。我不确定整个社区对您针对 SO 的问题的主题性有何看法，但这仍然是一个好问题。

您的桌面应用程序是如何部署的？您是将此应用程序分发给任何需要它的人，还是仅限于现场受信任的个人？

仅供我们公司内部使用。我们从事零售业务，拥有相当多的零售地点（商店）。该应用程序是使用配置管理软件部署的，但本质上它是一个简单的 XCOPY 部署。我们确实信任我们的同事，但在这些站点有数千名同事，内部攻击的风险始终存在。我们创建的应用程序可能会或可能不会处理敏感信息。我们的模板包含一个“N/A”复选框，因此对于非安全应用程序，我们可能不会担心列表中的所有项目。我们只是想要一个好的列表开始。

【参考方案1】：

恐怕不可能构建一个真正安全的本地winform应用程序，因为用户总是可以破解你的应用程序。

但是有一些技术可以减缓破解过程。大多数技术都发生在组装层上，例如垃圾代码和包装。

另一种技术是使您的可执行代码（即程序执行时进入内存的代码）随时间变化。但是，您必须首先确保所有其他代码（然后不执行）是安全的。这可以通过加密来完成。但是您还必须确保加密程序的安全性更高。加密程序始终固定在 ROM 中，并通过物理方式进行保护。

另一种方法是利用网络。经常更新本地应用程序并禁止使用旧版本。通过这种方式，您的代码可能会以足够快的速度变化以击败破解过程。

哦...我是在扔垃圾还是只是跑题了？抱歉。

【参考方案2】：

也许您想调查检查安全漏洞的现有工具。 他们有时会列出要检查的缺陷。

托管代码中仍然存在所有可能的安全风险，因为开发人员可以打开各种漏洞。框架 (.NET) 本身没有风险，但开发人员有风险。

这里有一个工具列表，您可以在那里阅读它们将检查哪些安全风险：

Static code analysis list

但是，当然，存在已知的漏洞，您可以在此处看到：

technet remote code execution

technet elevation of priviledge

还有更多已知但未解决的缺陷，可以在知名的安全站点上找到。 （包括零日漏洞）

**更多详细信息，这是我在评论中提到的清单**

MS Security checklist (do not know why this is "retired" as this are mostly neutral infos

Open Web application security project

MS Anti cross-site-scripting

MS ASP security reference implementation (very good information site)

CAT.NET ... MS static security analysis tool

【讨论】：

+1 因为这些工具肯定有一席之地，但这些工具与我的想法不同。我们的威胁分析服务器有几个目的。 其中一个是在新开发人员加入团队时对其进行教育 - 列出需要注意的事项以及如何处理这些事项是一种培训工具，因此我们希望使用代码分析工具除了执行威胁建模和其他活动。这很棒，但有一组与我要求的控件不同的控件。

换句话说，这些是发现现有代码缺陷的好工具。我们正在寻找需要注意的事项列表，以便我们可以在编写单行代码之前规划软件以避免这些事项。

好的，我以另一种方式理解了这个问题。您想知道从一开始就没有安全漏洞的情况下要避免哪些事情，对吗？想我几个月前读过这样的清单，不得不挖掘一下......

【参考方案3】：

Web 环境和桌面环境之间存在很大差异。在开发网站和服务时，您不信任的是用户（用户输入）。在运行桌面应用程序时，不受信任的是应用程序本身，或者至少，系统管理员想知道应用程序本身是否不会造成任何伤害，因为在本地计算机上运行的代码是有风险的自己。

所以从某种意义上说，对于作为桌面应用程序开发人员的您来说，安全规则并不总是适用，因为您运行的应用程序不是黑盒子，而是白盒子。对于 Web 服务/站点，您希望攻击无法更改内部状态，但对于任何桌面应用程序（Java、.NET、本机），在应用程序运行时更改应用程序状态“相当”容易运行，尤其是使用 Java 和 .NET，调试和反编译应用程序非常容易。

换句话说，您必须考虑到桌面应用程序已完全受到威胁，如果这是一种风险，您必须将必须安全的所有内容（身份验证、授权、验证）提取到外部（Web）服务。对于此服务，“正常”OWASP 规则适用。

您应该注意的是，当桌面应用程序直接连接到数据库时，很难完全保护您的数据层。例如，在这种情况下，SQL 注入对于您的桌面应用程序来说不是问题，因为当应用程序可以直接连接到数据库时，用户也可以。如果用户可以连接到数据库，他可以执行任意查询。这是一种极端形式的 SQL 注入，但它完全跳过了您的应用程序。

试图保护 2 层应用程序，通常意味着使用存储过程作为中间（服务）层（并防止直接访问表）。开发和维护存储过程比开发 .NET (Web) 服务的成本要高得多。

【讨论】：

这是有道理的。我想它以一种方式转化为网络世界：浏览器被认为是完全不受信任的，我的工作是确保我的网站不会因为浏览器而泄露任何秘密。我的 WinForms 应用程序，就像我客户的网络浏览器一样，是“我无法控制的”。我必须计划，假设我的 Winforms 应用程序完全不可信，因此将任何需要保护的业务逻辑转移到我的 Web 服务，并严格使用 WinForms 应用程序作为 UI。这是一个准确的解释吗？

绝对。另请注意，SQL 数据库经常受到使用缓冲区溢出攻击的攻击。因此，如果您可以（再次）将您的数据库隐藏在 Web 服务后面。

我无法与这种逻辑争论，而且我以前从未这样想过，尽管我知道反编译和反向工程一个 .NET 应用程序是多么简单。谢谢。

暂时不要将我标记为答案。我想看看其他人对此有何看法。

Steven 的回答很好，但我认为 OP 不仅想要 SQL 注入，还想要各种缺陷，或者？