如何避免意外在我的MSI中分发敏感信息？ [英] How do I avoid distributing sensitive information in my MSI by accident?

查看：605
本文介绍了如何避免意外在我的MSI中分发敏感信息？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

如何避免意外在WiX / MSI中分发敏感信息？




  • 我分发了密码，计算机名或登录凭据不小心与我的MSI文件有关。我该如何最好地解决这个问题？

  • 部署后，我的应用程序错误地连接到我的QA / UAT系统而不是生产系统上-由于设置的自定义操作代码中的调试构造错误。如何检测并避免这种情况？

  • 如何避免一般性地分发此类信息？



< hr>

这是一个 Q / A风格的问题，采用最简单的方法来避免意外地通过MSI传播敏感信息

解决方案


超级压缩 ：安装Orca，请其他人帮助并依次浏览原始表，然后浏览所有自定义操作代码。






所有这些都是显而易见的-如果您遇到了这种情况，并且您在野外拥有敏感信息：您所能做的就是拉回MSI（希望从下载中下载-情况更糟） （在光学媒体时代），请更改所有密码或显示的其他任何信息-然后确保您不再遇到这种情况。现在是重要的部分，如何在将来避免使用它。



除了下面有关敏感信息的信息外，还请记住您想要的某些文件包含在您的设置中的文件可能无法合法重新分配。典型示例是Microsoft的调试工具或第三方SDK工具包的调试工具。请仔细阅读文档，并避免在自定义操作中使用此类 hacky工具。





简短版



更新：让我记不起，在我忘记之前，您应该删除 从所有设置文件中下载了文件阻止标志（通常也是只读标志）。



以下建议的全部操作基本上是：1）使用Orca扫描最终的MSI ，2）查看已安装的设置文件以及任何模板MSI随附的安装脚本。此外，3）很好地检查编译的自定义操作源，并可能改善发行版本的配置实践（例如， #ifdef _DEBUG ，请参见下文）。 4）通过检查MSI中的实际内容（提取它们）来查看脚本自定义操作。至关重要的是：5）从其他人那里获得一些帮助以进行所有手动测试-获得一些帮凶:-)。 认真：设置与应用程序一样重要-要使您的解决方案成功，让QA人员和其他人员进行测试是您的责任-并告诉他们如何进行测试。



我会避免尝试自动进行此类检查。数据无可替代。也许社区解决方案将对长期有所帮助。它可以成为验证套件的一部分吗？半自动帮助可能会起作用，但会自动发挥作用：忘记它。



敏感数据可能是错误的术语，也许是无效内容更合适。应用程序指向测试服务器而不是启动时的生产服务器可能会导致问题。意外的消息框可能会因自定义操作（有时会泄露敏感数据）而弹出，而超出了暴露纯敏感数据的类似发布错误。





质量检查-错误任务



检查意外包含的敏感数据显然与您的包装的一般质量检查有关。它应与常规测试同时进行。质量检查人员忙于应用程序测试，以至于您实际上必须推动此部署测试并制定测试计划。没什么，但是可以测试所有安装模式（ install ，重新安装，修复，自我修复，升级，修补，卸载，管理安装，恢复/暂停安装 （设置重新启动问题），并且如果您具有测试该设备和网络的设备，则还应该进行发布和广告 ）并测试所有自定义操作功能（彻底）。实际上，您必须进行最低程度的测试安装，重新安装，卸载和升级，但是请测试所有模式。



如果您本地化，可以在所有版本的所有核心地区进行测试。也可以在德语地区使用英语，反之亦然，仅用于烟雾测试。实际上，请在所有地区测试英语-我想这很明显。在本地计算机上，自定义操作很容易失败，该本地计算机由该计算机上的随机状态触发（例如，CA试图访问硬编码的英语路径和异常结果），或者在异常处理程序代码或类似内容中以英语显示一些被遗忘的消息框从未在英语盒上触发过。不好，哦，是的，我经常看到它，因此应该把它归类为一个问题。



我想应该提到一个经验丰富的开发人员的话。 ： ...在找到的每个错误都是真正的惊喜之前，不要让太多的人参与测试。而且-他的有趣建议-对于预发行版，存在一些已知的错误，并告诉质量检查人员，有如此众多的错误可以找到-只是出于某种动机来集中精力：-)。附注：我想将这位经验丰富的开发人员称为 上古蚱，或者他通常被称为 素食男孩。孔子说： 永远不要相信一个可以用（有机）胡萝卜行贿的人！



题外话，回到真正的话题：敏感数据的错误包含。





检查MSI文件



在检查我的MSI文件中的敏感信息时，我保持简单。


  1. 首先a 迅速对源文件进行一次遍历（WiX，Installshield，Advanced Installer或您使用的任何工具）以解决硬编码开发箱中的问题。

  2. 然后非常注意检查已发布的候选MSI文件本身。真正的麦考伊。所有表格，以及一些嵌入式内容的提取以进行验证（脚本，自定义操作dll等）。

  3. 所有安装模式下的实际安装，如上所述。可以显示敏感的内容，但也可以显示很多其他问题，例如弹出意外的消息框，有时还包含敏感的调试信息（自定义操作测试重点）。

如何检查？一些脚本化的检查可能有用，但是根据经验，我对此并不满意。如果老实说，我喜欢花哨的脚本检查而不是第二双眼睛。


  1. 安装Orca


  2. 现在只需使用Orca打开候选发布的MSI -然后浏览表格。


    • 要说的很明显：


      • 强制执行真实源中的任何更改，请不要修复完成的MSI。

      • 如果您问我，根本就没有即时修复程序-我认为您需要从源头进行修复并重建完整的MSI文件。然后标记您的源代码（如果您有适当的老式源代码管理，并带有美味的修订和标签）。


    • 大多数易受攻击的表可能是：注册表，属性， IniFile -，但是在那里可能在其他几个地方。

    • 如果您实际使用MSI GUI：与GUI相关的表也很容易受到攻击。


      • 许多人只是使用标准GUI而不进行修改。这样应该可以消除大多数风险。

      • 如果您具有自定义GUI，则 MSI GUI声明中涉及很多表。我会全神贯注。

      • 也许特别关注： ListBox ， ComboBox ， UIText ，对话框

      • 显然，您需要特别关注自己，自定义对话框-如果有的话。


    • 第三方工具具有易受攻击的自定义表，用于诸如XML文件更新之类的事情。这些也要眼球。


      • 任何看起来像XMLFile，SQLUpdates等的东西。

      • 不同的供应商。它们现在与各种各样的事物有关，而不仅仅是配置文件（防火墙规则，SQL脚本等）。


    • 检查任何包含的脚本。


      • 签入源代码管理，而且...

      • CustomAction 表或 Binary 表-后者要求您流式传输任何脚本-或在其源位置检查它们）。



  3. 检查应用程序安装的所有设置文件（通过MSI的文件表）。


    • 具有硬编码设置的INI文件可以通过File表安装，因此在Orca中看不到它们的值（与INIFile表相反，后者显示了所有INI字段）。


      • 此处的区别本质上是文件是作为文件处理还是作为一组要写入INI的组值对处理。后一种方法是正确的方法。

      • 请注意，如果某些INI文件具有非标准格式，则可能需要将其安装为文件。字段以及各种与普通键/值对格式相反的奇怪情况），甚至更常见：INI文件可能包含巨大的注释部分，其中包含您要保留的帮助信息（通常用于开发人员工具），并且无法通过INI文件表。然后可以选择将其安装为文件。


    • 可以使用相同的方式安装其他设置文件（例如XML文件）。实际上很多时候。


      • 如上所述，第三方工具通常支持从Orca中可见的自定义表编写更新。

      • 有可以有许多这样的不同表（加密字段？其中有什么？）


    • 这样包含的文件通常由开发人员维护，但是仍然是检查的发布责任。对您的MSI进行管理安装（链接的答案中的其他链接）并检查创建的网络映像中提取的设置文件。 msiexec.exe / a Your.msi ，或 setup.exe / a （Installshield），或 setup.exe / extract （高级安装程序）。 一些setup.exe信息。


  4. 检查支持批量安装脚本， Powershell脚本或<设置中附带的strong>其他形式的脚本-用于实际安装软件。


    • 有时您会看到现成的脚本附带一些设置，以帮助实现自动化部署，通常某些形式的硬编码信息会潜入此处（UNC路径，甚至IP地址或其他类型的测试数据。

    • 这些脚本有时会作为单独的下载内容提供，可能是事后才想到的，根据我的经验，这些脚本最终被质量检查所忽略。 / li>
    • 在质量检查和测试（如果可用）中积极使用这些脚本，或者更好的方法是：在单页PDF中记录大规模部署（更多的是通用的，并且出错率更低）。


  5. 警告：即使在Orca中看不到任何东西，已编译的自定义操作仍然可以包含敏感内容-显然，有时容易忘记


    • 已编译的自定义操作不能直接查看因此，任何硬编码的敏感内容都较少暴露。

    • 但是，错误的硬编码IP地址可能会导致您的所有用户尝试连接到测试服务器或您想要的其他任何服务器...我怀疑

    • 再次：获得帮助-另一双眼睛可以为您节省麻烦，但是这次让他们将实际的源代码读取为好。告诉他们将重点放在意外的，硬编码的值上，并进行怪异的定义-任何看起来实验性的内容。


      • 这种 白盒或透明质量检查可能在这里很好。招募另一个开发者？我将只关注怪异的东西的代码，而不是测试实际功能（即用于黑盒测试）。

      • 显然，该代码应仅与MSI PUBLIC PROPERTIES一起用于值输入由用户或在命令行上设置。硬编码的内容都不应该真正存在。在现实世界中，大多数开发人员最终都会在调试版本中设置一些硬编码。

      • 质量保证专业人员，应被告知如何测试相同的自定义操作 黑匣子，这也是第一个启动应用程序以测试将正确的值写入到何处的方法。

      • 能否提供一些方便的应用程序级别记录他们知道存在并且知道如何使用的质量检查人员（并希望对他们进行检查？）。然后，您应该等待几分钟，才能让他们发现您的发布应用程序命中您的内部测试服务器，而不是生产服务器。


    • 对于已编译的C ++自定义操作，如果您坚持使用硬编码的东西，我建议您采用良好的挑剔调试实践。使用 #ifdef _DEBUG 包装调试消息框和任何硬编码测试变量。请参见下面的C ++代码段。这意味着发行版本中根本没有实验值（预处理器将删除所有调试结构）。

    • 也许还添加 NOMB 以及您的发布版本？也请参见下面的示例-应该防止误发布构建消息框-
      的定义本质上是禁止
      的（其他，可能的定义：如何驯服Windows标头（有用的定义）？）。


      • 我仅对此进行了简短测试。我有相当一部分被遗忘的C ++消息框出现在一个发行版本中-我不得不承认-幸运的是没有灾难（敲木头等等等等）。

      • 请记住，这样的消息框可能会神秘地暂停以静默模式远程运行的安装程序，而该安装程序却死在其轨道上，而没有任何警告或明确的原因（通常没有日志消息）。

      • 此类消息通常可能是由于大多数安装中通常不会触发的某种错误情况或异常而触发的-因此在某些PC上突然出现了该消息。远程部署时，您无能为力。设置无法正确回滚，只是卡住了。如果本地没有用户登录，则也无法在计算机上将其关闭。不完全是完全关于敏感信息的信息，而是相关的信息（准确显示在框中？），以及在测试自定义操作时要注意的事项。

      • 一个自然的问题是是否有办法自动使消息框超时？我简要测试了此建议的 MessageBoxTimeout 方法（来自 user32.dll ），似乎它甚至支持上述 NOMB 功能以及超时。换句话说，您可以将消息框设置为在发布版本中禁止，并在调试版本中设置为超时。未经充分测试。


    • C ++不是我的事，请按照最佳实践使用贵公司定义的发行版本。也许寻找定义和字符串变量。或所有设置都可能位于调试版本仅包含的设置文件中（但无论如何，奇怪的东西总会在这里和那里蔓延）。

    • 对于托管代码，我问自己一个问题：该托管二进制文件如何可反编译？我在这里经验很少。我从未花时间反编译托管二进制文件。


      • 无论如何，代码中都不应包含任何敏感内容-除非您有隐藏的私钥，许可证密钥或类似的怪异内容，否则我肯定会这么做

      • 对于诸如为您的应用程序设置试用期之类的功能，我想您可能希望更好地隐藏实现。某种混淆可能很常见，我无法跟上。也许这是.NET世界中更大的问题之一？ 有关该主题的专家：请教育我们。

      • 我将重点关注与上述相同的问题：调试错误地包含在发行模式二进制文件中且错误的结构设置为测试服务器和测试资源的链接和路径。



  6. 包括


    • 在某些情况下很容易发生的另一个问题：您包括以下版本的调试版本：您可以在MSI中自定义操作DLL 。

    • 显然，这可能发生在设置中的任何文件上，不仅是您的自定义操作DLL，而且自定义操作DLL是

    • 也许要确保添加 d 到您编译的自定义操作dll的文件名-还是其他任何文件？即使会导致您额外的工作？

    • 我不确定调试dll到底有多敏感（必须由适当的C ++专家来阐述）-但我当然不想意外地在我的设置中分发此类文件。我有时（很少）为质量检查小组制作调试构建MSI文件，这些文件仅包含调试二进制文件和符号用于测试目的，我认为这些设置应该在一两个月后过期，并且永远不会易于安装并且永远不会在质量检查小组之外使用。可以添加安装密码，但是MSI是一种开放格式，仍然可以提取。没有戏剧性，我想只是要记住和处理的事情。


  7. 现在，这对于敏感主题有所推动数据，但是对您打算进行数字签名并公开发布的任何内容进行彻底的恶意软件扫描呢？签名恶意软件不是您想要体验的东西。


    • 验证发布文件中的数字签名（如果有）。使用UAC等进行测试...

    • 也许使用 Virustotal.com 或等效的恶意软件扫描服务/解决方案，以扫描最终的MSI文件中的恶意软件（或误报）。

    • 使用 procexp64.exe （可直接下载Sysinternals Process Explorer）以在测试安装后扫描所有正在运行的进程。 在此处查看该工具的一些建议使用步骤。

    • 使用这些工具也可以帮助您消除误报。随着安全软件加强安全性和恶意软件变得越来越普遍，这个可怕的问题似乎变得越来越严重。


      • 错误的肯定结果可能会对部署的软件包造成无尽的自我修复（请参阅该链接中的问题7），因为文件被反复隔离然后放回由Windows Installer通过自我修复提供。

      • 假阳性反讽 ：对于真正的恶意软件，您告诉用户重建他们的电脑。 对于误报，您必须与安全软件供应商一起解决问题。现在如何对数十种安全工具和套件执行此操作？



在C ++自定义操作中仅调试消息框：



<我使用消息框来将调试器附加到C ++自定义操作代码。如何避免这些小动物出现在发行版本中？这是一个建议：

  #ifdef _DEBUG //仅显示调试信息
 MessageBox（NULL，文本，标题，MB_OK | MB_SYSTEMMODAL）; 
 #endif

高级C ++人士会立即看到，他们应该使自己成为更好的宏这-全部包裹-我不是C ++向导，所以我暂时将其留在外面（SafeMessageBox？DeploymentMessageBox？）。



在 stdafx.h ，也许还可以启用 NOMB （除非包装为 MessageBox ，否则应避免编译） #ifdef _DEBUG -使 MessageBoxes 仅在调试版本中可用）：

  #ifndef _DEBUG //发行版中的禁止MessageBox构建
 #define NOMB 
 #endif

（一个合理的选择，这可能成为您最讨厌的定义之一：-)。谁闻到被注释掉的部分？我不会使用 #undef 添加一个临时发布消息框-它破坏了整个保护功能-可能正是导致您希望避免的事情：一个流浪消息框。如果需要的话，也许只需注释掉 stdafx.h 中的#define，然后通过构建过程自动启用重新定义，以进行真正的公开发布，从而触发并为任何杂散消息框编译错误）



如上所述，您可以尝试使用新的 MessageBoxTimeout 方法（显然来自 user32.dll 从XP开始提供）以显示不会卡住但在指定的秒数后超时的消息框。



某些上下文：＃ifdef调试与#if调试。真正了解C ++的人可以根据需要随时进行澄清或阐述。上面的内容来自一个非常古老的C ++项目。



基本上，这几乎是火箭科学，只是小事一咬。下面的主题有一些进一步的讨论，但是不能代替此手动扫描恕我直言。我的诚实建议，请一些人（经理很好：-)-将他们拉进来！），为他们安装Orca，然后告诉他们单击表格并查看所有设置文件-并请开发人员提供有关已编译的自定义操作代码的帮助。仅仅查看原始的Orca表甚至可能对发现其他bug或缺陷也有效。





敏感信息



在开发过程中，有很多机会在您的MSI源中意外地包含敏感信息：登录凭据，密码，数据库连接字符串，用户名，共享名， IP地址，机器名， ftp密码， Web主机登录凭据或其他敏感数据。



您的MSI显然根本不应该包含任何此类敏感信息-除非您要指向您自己的网站当然，或者提供联系人电子邮件或电话号码。但是，其他任何事情几乎总是不合要求的-由于开发实验（通常在脚本自定义操作-或已编译的自定义中），很快忘记从生产MSI文件中删除此类硬编码信息操作-甚至更糟，并且无法通过上述建议的Orca审核方法检测到，但通常除非由意外消息框显示，否则用户通常无法查看-或如果分解了.NET托管代码）



如果安装真正需要，则此类敏感信息应为最终用户在安装时通过安装程序的交互设置的参数（属性）。 GUI或通过PUBLIC PROPERTIES进行设置，或者在安装安装程序时在命令行中进行转换。这里有一些有关使用转换和公共属性的信息： 如何更好地利用MSI文件 进行无提示的公司级MSI文件部署（链接的答案还从更一般的意义上对MSI问题和好处进行了专门的描述）


How do I avoid distributing sensitive information in my WiX / MSI by accident?

  • I distributed a password, machine name or login credentials by accident with my MSI file. How do I best deal with this problem?
  • After deployment my application connects erronously to my QA / UAT systems instead of my production systems - because of a faulty debugging construct in my setup's custom action code. How can I detect and avoid this?
  • How do I avoid distribution such information in general?

This is a Q/A-style question with the simplest possible approach to avoid spreading sensitive information via your MSI by accident

解决方案

Super Condensed: Install Orca, get someone else involved to help and go through the raw tables in sequence and then any custom action code.

All of this is obvious - if this has happened to you and you have sensitive information in the wild: all you can do is pull back the MSI (from download hopefully - it was even worse in the days of optical media), change any passwords or whatever else was revealed - and then make sure you don't experience it again. Now for the important part, how to avoid it for the future.

In addition to the information below on sensitive information, please also remember that some files you want to include in your setup may not be redistributable legally. Typical examples would be debugging tools from Microsoft or debugging tools from third party SDK toolkit. Please read documentation thoroughly and avoid use of such "hacky tools" in your custom actions.

Short Version

UPDATE: Let me jot down, before I forget, that you should eliminate the "downloaded file blocking flag" from all setup files (and generally read-only flags too).

All that is being suggested below is essentially to 1) scan your finalized MSI with Orca, 2) look over installed settings files as well as any template installation scripts delivered with your MSI. Further, 3) review your compiled custom action sources very well and maybe improve release build configuration practice (#ifdef _DEBUG for example, see below). 4) review your script custom actions by checking what is actually in your MSI (extract them). And crucially: to 5) get some help from other people for all manual testing - get some accomplices :-). Seriously: the setup is as important as the application - to make your solution succeed, it is your duty to get QA-personnel and other people involved testing - and also to tell them what and how to test.

I would avoid trying to automate such checking yourself. There is no substitute for real eyeballs on the data. Perhaps a community solution would help long term. It could become part of a validation suite? Semi-automatic help might work, but fully auto-magic: forget it. There are too many ways to use all the rope you've got to shoot yourself in the foot.

Sensitive data may be the wrong term, maybe "invalid content" is more appropriate. Problems can result by your application pointing to your test server rather than production server on launch. Unexpected message boxes may pop up from custom actions (sometimes revealing sensitive data), and similar release blunders beyond pure sensitive data being exposed.

QA - Bug Quest

Checking for sensitive data included by accident obviously ties into general QA of your package. It should be done simultaneously with general testing. QA people are so busy with application testing that you really have to push this deployment testing, and make a test plan. Nothing fancy, but do test all installation modes (install, reinstall, repair, self-repair, upgrade, patching, uninstall, administrative install, resume / suspended install (setup reboot issues) and you should also do publishing and advertisement - if you have the equipment and network to test this) and test all custom action functionality (thoroughly). Realistically and minimally you must test install, reinstall, uninstall and upgrade, but please test all modes.

And if you are localizing, test in all core regions in all editions. Also run English in German locations, and vice versa just for smoke testing. In fact, test English in all regions - obvious I guess. Custom actions could easily fail on localized machines triggered by a random state on that machine (CA trying to access a hard coded English path for example and an exception results), or show some forgotten message box in English inside your exception handler code or similar that was never triggered on an English box. Bad, oh yes, and I have seen it often enough that it should be chalked up as an issue.

And I guess it should be mentioned the words of an experienced developer: "...don't hit too many people with testing until every bug found is a genuine surprise". And also - his funnier advice - for pre-releases leave in a couple of known bugs and tell the QA guys that there are such and such number of bugs to find - just for some motivation to focus the mind :-). P.S: I like to refer to this experienced developer as "The Elder Grasshopper", or as he is more commonly known "Veggie Boy". Confucius says: "Never trust a man who can be bribed with (organic) carrots!"

A large digression, back to the real topic: erroneous inclusion of sensitive data.

Checking MSI Files

I keep it simple when it comes to checking my MSI files for sensitive information.

  1. First a quick once-over of the source files (WiX, Installshield, Advanced Installer, or whichever tool you use) for hard coded dev-box sins.
  2. Then significant attention checking the finished release-candidate MSI file itself. The real McCoy. All tables, and also extraction of some embedded content for verification (scripts, custom action dlls, etc...).
  3. Actual installations in all installation modes, as described above. Sensitive content can be revealed, but so can a lot of other issues - for example unexpected message boxes popping up - sometimes with sensitive debugging info (custom action test focus).

How to check? Some scripted checks could be useful, but from experience I don't get fancy about it. I prefer a second pair of eyes over fancy script checking if I am honest. Just my two cents from real release work.

  1. Install Orca
    • Orca is as down to the wire as you get with MSI - other tools often show bogus, proprietary tables. Orca is a straight up view of the file content.
    • Search for "Orca" here to find the installer quickly if you have Visual Studio installed - or tell someone with Visual studio installed to send you the installer MSI.
    • You can also try "Super Orca" - but Orca is recommended.
  2. Now just open your release-candidate MSI with Orca - and skim through the tables.
    • And just to say the obvious:
      • Enforce any changes in the real source, don't hotfix the finished MSI.
      • If you ask me, no in-situ hotfixing at all - you need a fix at the source and a full MSI file rebuild in my opinion. Then you label your source code (if you got proper, old-fashioned source control with delicious revisions and labels).
    • Most vulnerable tables are probably: Registry, Property, IniFile- but there could be something in several other locations.
    • If you actually use the MSI GUI: tables relating to GUI are also vulnerable.
      • Many people just use the standard GUI without modifications. This should eliminate most risks.
      • If you have a custom GUI, then there are quite a few tables involved in the MSI GUI declaration. I would eyeball them all.
      • Perhaps particular focus on: ListBox, ComboBox, UIText, Dialog
      • Obviously with extra focus on your own, custom dialogs - if any.
    • Third party tools feature vulnerable custom tables for things such as XML file updates. Eyeball these as well.
      • Anything that looks like XMLFile, SQLUpdates,etc...
      • There are more and more such custom tables from different vendors. They relate to all kinds of things now, not just config files (firewall rules, SQL scripts, etc...)
    • Check any included scripts.
      • Check in source control, but also...
      • CustomAction table or Binary table - the latter requiring you to stream out any scripts - or check them in their source locations).
  3. Check any settings files the application installs (via MSI's File table).
    • INI files with hard coded settings could be installed via the File table and hence not have their values visible in Orca (as opposed to the INIFile table which shows all fields of an INI to write).
      • The difference here is essentially whether the file is handled as a file or as a set of group-value pairs to write to an INI for example. The latter approach is the "correct" one.
      • Note that some INI files may need to be installed as files, if they have non-standard formatting (extra fields and various strangeness contrary to normal key-value pair formatting), or even more common: INI files may have huge comments sections with help information (often for developer tools) that you want to preserve - and you can't via the INI file table. Then the option is to install it as a file.
    • Other settings files such as XML files could be installed the same way. Very often in fact.
      • As stated above third party tools often feature support for writing updates from a custom table viewable in Orca.
      • There can be many such different tables (Encrypted fields? What is in there?)
    • Files included like this are generally maintained by developers, but it is still a release responsibility to check. Make an administrative installation (further links in linked answer) of your MSI and check the extracted settings files in the created network image. msiexec.exe /a "Your.msi", or setup.exe /a (Installshield), or setup.exe /extract (Advanced Installer). Some setup.exe info.
  4. Check supporting batch installation scripts, Powershell scripts, or other forms of scripts delivered with your setup - with the intent to do the actual installation of the software.
    • Sometimes you see ready-made scripts delivered with some setups to help automate deployment, often some form of hard coded information can sneak in here (UNC paths, even IP-addresses, or other kinds of test data").
    • These scripts, sometimes delivered as a separate download, may be an afterthought that ends up being neglected for QA in my experience.
    • Use these scripts actively during QA and testing if available, or better yet: document large scale deployment in a single page PDF instead (much more generic and less error prone).
  5. Warning: compiled custom actions can still contain sensitive stuff even if nothing is visible in Orca - obviously. Easy to forget sometimes in the heat of the moment. This is of high cruciality (new favorite word) - back to the source code.
    • Compiled custom actions are not directly "viewable" so any hard coded sensitive stuff is "less exposed".
    • However, an erroneous hard-coded IP address could cause all your users to try to connect to your test server or whatever other server you want for yourself... I would suspect this wouldn't happen during setup, but during first application launch.
    • Again: get help - a second pair of eyes will save you trouble, but this time let them read the actual source code as well. Tell them to focus on unexpected, hard-coded values and weird defines - anything that looks "experimental".
      • Such "white box" or "transparent" QA is probably good here. Recruit another developer? I would focus on just eyeballing code for "weird stuff" rather than testing actual functionality (that is for black box testing).
      • Obviously the code should work with MSI PUBLIC PROPERTIES only for values input by the user or set at the command line. Anything hard coded shouldn't really be there. In the real world most developers end up setting something hard coded in debug builds however.
      • QA professionals should be told how to test the same custom action "black box" obviously - and also the first application launch to test that correct values were written to wherever they were going.
      • Can you provide some convenient application level logging for the QA-guys that they know exist and they know how to use (and that checking it is expected of them?). Then you should be down to just a few minutes before they discover that your release application hits your internal test server and not your production server.
    • For compiled C++ custom actions I would suggest using good nitpicking debugging practice if you insist on hard coding stuff. Use #ifdef _DEBUG to wrap debugging message boxes and any hard coded test variables. See C++ snippet below. This means no experimental values are ever in release builds at all (the pre-processor will remove all debugging constructs).
    • Perhaps also add NOMB to your release build as well? See sample below as well - should prevent stray release build message boxes - the define essentially "forbids" them (other, possible defines: How to tame the Windows headers (useful defines)?).
      • I have only tested this briefly. I have had my fair share of forgotten C++ message boxes pop up in a release build though - I have to admit - no disasters luckily (knock on wood and such forth and whatnot, etc...).
      • Keep in mind that such a message box could mysteriously halt a setup run remotely in silent mode dead in its track without any warning or clear reason (usually no log message).
      • Such a message could typically be triggered by some sort of error condition or exception not generally triggered for most installations - so it is suddenly there, on some PCs. Nothing you can do to recover when deploying remotely. The setup doesn't correctly roll-back, it is just stuck. If there is no user logged on locally there is no way to dismiss it on the machine either. Not strictly about sensitive information outright, but related (exactly what is displayed on the box?), and something to look at when testing custom actions.
      • A natural question is whether there is a way to make message-boxes time-out auto-magically? I briefly smoke-tested this suggested MessageBoxTimeout method (from user32.dll), and it seems it even supports the above NOMB feature as well as timeout. In other words you can set the message box both forbidden in release builds and to time-out in debug builds. Not tested thoroughly.
    • C++ is not my thing, use best practice for release builds as defined by your company. Maybe look for defines and string variables. Or all settings may be in a settings file only included by debug builds (but weird stuff tends to creep in here and there anyway).
    • For managed code, the question I ask myself is: how de-compilable is this managed binary? I have little experience here. I have never taken the time to de-compile managed binaries.
      • There should be nothing sensitive in the code anyway - unless you have a hidden private key, a license key or something similarly weird in there - which I would definitely not do, leave it for the application to do.
      • For features such as setting up a trial period for your application I suppose you could want to "hide the implementation" better. Some sort of obfuscation is probably common that I am not up to speed on. Maybe this is one of the bigger problems in the .NET world? Experts on the topic: please educate us.
      • I'd focus on the same issues as above: debugging constructs that are erroneously included in release mode binaries and erroneous links and paths set to test servers and test resources.
  6. Including debug build binaries in your official release by accident
    • One more issue that in certain cases can easily happen: you include debug versions of you custom action DLL(s) in your MSI.
    • This can obviously happen to any file in your setup, not just your custom action DLL, but the custom action DLL is particularly "hidden" in your package after building (embedded in the MSI's Binary table - verify it).
    • Perhaps make sure to add a d to the file name for your compiled custom action dll - or any other file for that matter? Even if it causes you some extra work?
    • I am not sure how "sensitive" a debug dll really is (a proper C++ expert must elaborate) - but I sure don't want to distribute such files in my setups unintentionally. I sometimes (rarely) make debug build MSI files for QA teams containing only debug binaries and symbols for testing purposes, and in my opinion these setups should expire after a month or two and never be easy to install and never be used outside your QA team. Passwords to install could be added, but MSI is an open format and can still be extracted. No drama, just something to keep in mind and manage I guess.
  7. Now this is pushing it a little for the topic of "sensitive data", but how about a thorough malware scan of anything you intend to sign digitally and release publicly? Signed malware is not something you want to experience.
    • Verify your digital signature on your release file (if any). Test with UAC, etc...
    • Maybe use Virustotal.com or an equivalent malware scanning service / solution to scan your final MSI file for malware (or false positives).
    • Use procexp64.exe (direct download of Sysinternals Process Explorer) to scan all your running processes after test installation. See some suggested usage steps for the tool here.
    • Using these tools may help you eliminate false-positives for your solution as well. A terrible problem that seems to be getting worse as security software tightens security and malware becomes more prevalent.
      • False-positives may cause endless self-repair (see issue 7 in that link) for your deployed package as files are quarantined repeatedly and then put back by Windows Installer via self-repair.
      • The False Positive Irony: For real malware you tell your users to rebuild their computers. For a false-positive the pressure is on you to resolve the problem with security software vendors. Now how to do that for dozens of security tools and suites?

Debug only message box in C++ custom action:

I use message boxes in order to attach the debugger to C++ custom action code. How to avoid these critters showing up in a release build? Here is one suggestion:

#ifdef _DEBUG //Display Debug information only for debug builds
     MessageBox(NULL, "Text", "Caption", MB_OK|MB_SYSTEMMODAL);
#endif

Advanced C++ guys will immediately see that they should make themselves a better macro for this - wrapping it all - I am no C++ wiz, so I'll leave that out for now (SafeMessageBox? DeploymentMessageBox?).

In stdafx.h, maybe additionally enable NOMB (should prevent MessageBox from compiling unless wrapped with #ifdef _DEBUG - making MessageBoxes only available in debug builds):

#ifndef _DEBUG // Forbid MessageBox in Release builds
    #define NOMB
#endif

(a fair bet this may become one of your most hated defines ever :-). Who smells a commented out section? I wouldn't use #undef to add an ad-hoc release message box - it ruins the whole protection feature - likely causing precisely what you hope to avoid: a stray message box. Perhaps just comment out the #define in stdafx.h if you have to, and enable the define again - automatically via the build process - for a real, public release build triggering a compile error for any stray message boxes)

And as mentioned above, you could try the new MessageBoxTimeout method (from user32.dll, apparently available since XP) to show message boxes that don't get "stuck" but timeout after a specified number of seconds. Not for release use, but might be useful for debugging and QA.

Some context: #ifdef DEBUG versus #if DEBUG. People who actually know C++ properly, feel free to clarify or elaborate as required. The above is from a very old C++ project.

That is basically it - hardly rocket science - just "trifles that bite". Some further discussion on the topic below, but there is no substitute for this manual scanning IMHO. My honest suggestion, grab some people (managers are just fine :-) - pull them in as accomplices!), install Orca for them and just tell them to click through the tables and look in all settings files - and get a developer to help with the compiled custom action code. Just looking at the raw Orca tables may even be effective in order to find other bugs or imperfections as well.

Sensitive Information

There is plenty of opportunity to include sensitive information in your MSI sources by accident during development: login credentials, passwords, database connection strings, user names, share name, IP-address, machine names, ftp passwords, web host login credentials or other sensitive data.

Your MSI should obviously not contain any such sensitive information at all - unless you want to point to your own web-site of course, or provide a contact email or telephone number. However, anything else is almost always undesirable - and it is quick to forget to remove such hard coded information from production MSI-files due to development experimentation (often in script custom actions - or compiled custom actions for that matter - even worse and not detectable by the Orca review approach suggested above, but generally not view-able by the user unless it is show via an unexpected message box - or if .NET managed code is disassembled).

If actually required for the install, such "sensitive" information should be parameters (properties) that are set by the end user at install time, either via the setup's interactive GUI or set via PUBLIC PROPERTIES or transforms at the command line when the setup is being installed. There is some information here on using transforms and PUBLIC PROPERTIES: How to make better use of MSI files for silent, corporate deployment of MSI files (the linked answer also provides a rather ad-hoc description of MSI problems and benefits in a more general sense).

这篇关于如何避免意外在我的MSI中分发敏感信息？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆