QML 应用程序和安全性 - 有吗？

Posted 2023-02-17

【中文标题】QML 应用程序和安全性 - 有吗？

【英文标题】：QML applications and security - is there any?

【发布时间】：2016-01-30 00:50:56

【问题描述】：

我刚刚做了一个令人震惊的发现——在部署 QML 应用程序时，项目中使用的所有“库存”QML 组件都部署为裸 QML 文件，直接在文件系统中可见，它们甚至没有隐藏在应用程序 qrc 中作为用户 QML 文件的二进制文件。这意味着任何人都可以打开那些人类可读的文件，并编写他需要执行的任何代码。此外，可以对QObject 派生类型进行大量自省，即使从 QML，您也可以爬下对象树，分析应用程序结构，遍历对象的方法和属性。有足够的空间进行恶意黑客攻击。您甚至不必挖掘一些被忽视的低级漏洞 - 一切都在等待。

是否有任何安全功能可以防止这种情况发生？可能需要检查已部署的 QML 以进行修改，甚至像校验和一样基本？如果没有，是否有任何手动实施安全性的策略？部署流程好像已经设置好了，就是这样，没有定制的余地？

还请注意，根据我对this question 的调查，似乎可以覆盖 QML 文件的解析方式，但即使采取这种艰苦的方式，这与现有的部署方案有什么关系？是否有一种“漂亮”的方式来自定义部署过程，尤其是考虑到不同目标平台之间的差异很大。

问题不是关于保护我的代码免受窃，问题是关于保护Qt的代码免受篡改。

---

由于很多人似乎对理解手头的问题有问题，让我以一种隐喻的形式来表达，希望这样更容易理解。所有的锁都可以打开，但这并不意味着如果你的门没有任何锁就没有问题。门无法锁上的安全问题并非没有根据，因为锁并非万无一失。

是的，所有应用程序都可能被黑客入侵，但是这是否需要对二进制文件进行逆向工程、找到一个被忽视的低级漏洞以及利用它来实现恶意目的的方法，或者它只是微不足道的，这一切都会有所不同就像打开一个文本文件并写下你想要发生的事情。

这不是典型的、内在的和不可避免的漏洞，这取决于开发人员尽可能地减少漏洞，这是一个巨大的、巨大的漏洞，在 Qt 的部署策略中设计存在用于 QML 应用程序。解决这个问题不仅不是开发人员的责任，而且 Qt 的许可方案很可能会阻碍开发人员这样做。当框架级别存在不安全性并且不允许您解决它时，实现安全性有点困难。

由于某种原因，人们似乎忽略了这种内在缺乏安全性的逆向工程方面。在黑客开始针对用户之前，他必须开发黑客。这是不安全感最明显的地方。毫无疑问，黑客将拥有对自己机器的管理员/root 访问权限，因此任何保护 QML 源代码不被写入的方案都行不通。让 QML 引擎随意解释文本文件使得破解应用程序变得容易得多，比利用可执行二进制文件容易得多。从那时起，还有其他途径可以破坏用户的系统（并且所有广泛使用的系统都容易受到攻击），但关键是，至少从单个应用程序开发人员的角度来看，受感染的系统本身并不会破坏用户的数据在我的应用程序中，因为它存储在文件系统中受保护，但它在应用程序中公开。让 QML 引擎如此不安全且容易将任何代码注入应用程序 - 这是这里的大问题。破坏用户系统上的 QML 文件的难易程度是次要的和次要的问题。 最大的问题是 QML 使 hack 的初始开发变得多么容易。

最后，某些人的偏见是可以理解的，他们的工作围绕 Qt用户的安全和隐私受到威胁。努力降低风险并不是提高产品声誉的最佳方式，这些风险不会因为你否认它们就消失，但是如果你改进你的产品，它们就会消失。与成为头条新闻的潜在高调数据泄露相比，承认风险并承诺解决这些风险肯定不会那么尴尬。

【问题讨论】：

我不明白你的担忧。您同样可以将应用程序安装文件夹中的任何 Qt dll 替换为恶意的。是的，这是你可以颠覆应用程序的方式，是的，如果有人找到一种方法来修改它们，那么他可能会篡改股票 QML 文件以造成一些伤害，这样它实际上可能会造成伤害。但这与老式的 dll 替换没有什么不同。

@ixSci - 除了它更容易。我担心这是不受保护的，将 QML 文件放在文件系统上，再加上 QML 对象结构的动态性、内省性和可预测性，会导致前所未有的应用程序漏洞。现在，如果您问我，作为一名开发人员，我关心我的应用程序的安全性和漏洞 - 我认为这样的问题甚至不值得回答。

“是否有任何安全功能可以防止这种情况发生？” - 是的，不要让那些 QML 文件对每个人都可写（并且在任何正常的安装中，它们都不是）无论您从不安全的位置加载 QML、其他脚本还是编译代码对我来说都没有什么区别。

@ddriver GPL 的真正目的是允许用户控制他们计算机上的软件......而且，不，这不是真正的安全问题。如果恶意的第 3 方可以修改您使用的程序，那么您将被淹没。以有害方式编辑纯 QML 文件将比仅部署 root 工具包困难得多。

@ddriver：好像编译修改后的 DLL 需要低级的漏洞利用技能。你修改 Qt 源代码，编译它，然后替换 QtCore.dll 或目标系统上的任何东西。或者将二进制 X 全部替换为二进制 Y。如果系统允许这样做，那么系统本质上是不安全的。在任何健全的系统上，已安装的应用程序和它附带的文件（包括 QML）不是用户可写的，但需要 root/管理员权限。这是 Linux 和 Windows 上的标准，您似乎指的是。

【参考方案1】：

With Qt 5.7，Qt 的静态构建（使用 -static 配置 Qt）将导致属于 Qt 模块的 QML 文件通过资源系统构建到插件中。例如，考虑Qt Graphical Effects 模块中的relevant change。以下是更改前qtbase/qml/QtGraphicalEffects 的目录列表：

Blend.qml
BrightnessContrast.qml
Colorize.qml
ColorOverlay.qml
ConicalGradient.qml
Desaturate.qml
DirectionalBlur.qml
Displace.qml
DropShadow.qml
FastBlur.qml
GammaAdjust.qml
GaussianBlur.qml
Glow.qml
HueSaturation.qml
InnerShadow.qml
LevelAdjust.qml
LinearGradient.qml
MaskedBlur.qml
OpacityMask.qml
private
qmldir
RadialBlur.qml
RadialGradient.qml
RectangularGlow.qml
RecursiveBlur.qml
ThresholdMask.qml
ZoomBlur.qml

之后：

private
qmldir
qtgraphicaleffectsplugin.lib
qtgraphicaleffectsplugin.prl
qtgraphicaleffectsplugind.prl

这是一种让访问 Qt 模块的 QML 文件变得更加困难的方法。

【讨论】：

这听起来很不错，即使 5.7 可能至少需要 9 个月的时间，但是需要静态构建，LGPL 用户似乎不会从中受益。

是的，我不确定那里的合法性/实用性......虽然我的印象是可以使用开源许可证发布静态链接的应用程序。

如果您所说的“开源”许可是指 LGPL - 不是真的，尽管由于缺少其他选项，这似乎是 ios 部署的情况。现在，如果您的应用程序是开源的，可能没问题，但总而言之，LGPL + 专有代码似乎要求动态链接。

@ddriver 如果您提供专有部分的目标文件，并链接 Makefile/脚本，以便用户可以重新链接不同/修改的 LGPL 部分，那么静态链接应该没问题。我不知道有什么软件可以做到这一点。可能是那些 iOS 应用。

【参考方案2】：

使用 Qt 资源系统管理资源文件

Qt 资源系统允许将资源文件作为二进制文件存储在应用程序可执行文件中。这在构建混合 QML/C++ 应用程序时很有用，因为它允许通过资源系统 URI 方案而不是文件系统资源的相对或绝对路径来引用 QML 文件（以及图像和声音文件等其他资源）。但是请注意，如果您使用资源系统，则无论何时更改 QML 源文件，都必须重新编译应用程序可执行文件以更新包中的资源。

在混合 QML/C++ 应用程序中使用资源系统：

创建一个以 XML 格式列出资源文件的 .qrc 资源集合文件从 C++ 中，使用 :/ 前缀将主 QML 文件作为资源加载或作为带有 qrc 方案的 URL 加载

完成此操作后，QML 中由相对路径指定的所有文件都将从资源系统加载。资源系统的使用对 QML 层完全透明；这意味着所有 QML 代码都应使用相对路径引用资源文件，并且不应使用 qrc 方案。此方案只能在 C++ 代码中用于引用资源文件。

来源：http://doc.qt.io/qt-5/qtquick-deployment.html

【讨论】：

这并没有回答问题，Qt 不会将自己的库存 QML 文件打包到资源中，它们只是公开地坐在那里。除非您提供一种方法让 Qt 将这些文件部署为资源，否则这不是一个有效的答案。

@ddriver 有什么东西可以阻止人们在 Qt 的 .qml 文件上使用它吗？我没试过。

@hyde - 好吧，你提到了关于部署和 LGPL 的事情，尽管还不清楚 qml 文件是否属于“库”类别。从技术上讲它是可以做到的，这也是一个很好的机会来剥离 cmets 的 qml 文件，这可能比实际代码占用更多的空间。但是，当不清楚是否允许您这样做时，这并不是一条真正安全的道路。此外，特别是 android 部署，这意味着您将部署 qml 文件两次，一次在 qrc 中，一次在 apk 和文件系统中自动部署。

@hyde - 如果库存 qml 文件被 Creator 自动部署为资源会更好，即使资源文件本身没有受到保护，但由于某种原因，这并没有完成。目前尚不清楚这是由于疏忽还是故意造成的，但在后者的情况下，可能是因为这种方法存在问题，与其说是技术问题，不如说是法律问题。