QML 应用程序和安全性 - 有吗? [英] QML applications and security - is there any?

问题描述

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

I just made a shocking discovery - when deploying QML applications, all the "stock" QML components used in the project are deployed as bare QML files, directly visible in the file system, they are not even tucked away in the application qrc binary as user QML files are. Meaning that anyone can open those human readable files, and write whatever code he needs executed. Also, it is possible to do a fair amount of introspection on QObject derived types, even from QML, you can crawl down the object tree, analyze the application structure, iterate through object's methods and properties. Plenty of room for malicious hackery. You don't even have to dig for some low level overlooked exploit - it is all just there for the taking.

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

Are there any security features to prevent that from happening? Something to check deployed QML sourced for modifications perhaps, even as basic as a checksum? If not, are there any strategies towards manually implementing security? It seems the deployment process is pretty much set, that's the way it is and there isn't room for customization?

另请注意，根据我对这个问题的调查，它似乎可以覆盖 QML 文件的解析方式，但即使采用这种艰巨的方式，它与现有部署方案如何叠加?是否有一种漂亮"的方式来定制部署过程，尤其是考虑到它在不同目标平台之间的巨大差异.

Also note that from my investigation in relation to this question, it does seem to be possible to override how QML files are resolved, but even if one goes this arduous way, how does that stack with the existing deployment scheme? Is there a "pretty" way to customize the deployment procedure, especially considering it varies drastically between different target platforms.

问题不是关于保护我的代码免受剽窃的影响，问题是关于保护Qt的代码免受篡改.

The question is not about protecting my code from plagiarism, the question is about protecting Qt's code from tampering.

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

Since many people seem to have a problem with understanding the issue at hand, let me put it in a form of a metaphor, which will hopefully be easier to understand. All locks can be picked, but that doesn't mean it is not a problem if your door comes with no lock whatsoever. Security concerns in the case of a door that cannot be locked are not unfounded just because locks aren't infallible.

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

Yes, all applications can be hacked, but it makes all the difference in the world whether this requires reverse engineering of binaries, finding an overlooked low level vulnerability and a way to exploit it to your malicious intent, or it is as trivial as opening a text file and just writing what you want to happen.

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

This is not the case of the typical, intrinsic and unavoidable vulnerability, which is up to the developer to try to minimize as much as possible, this is the case of a huge, gaping hole, existing by design in Qt's deployment strategy for QML applications. Not only is addressing this not a responsibility of the developer, on top of that Qt's licensing schemes might very well impede the developer from doing it at all. It is a little hard to implement security when insecurity exists at the framework level and you are not allowed to work around it.

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

For some reason people seem to miss the reverse engineering aspect of this intrinsic lack of security. Before a hacker begins targeting users, he has to develop the hack. This is where the insecurity is most pronounced. The hacker will undoubtedly have admin/root access to his own machine, so no scheme to protect QML sources from writing will work. Having the QML engine willy–nilly interpret text files makes it all that much easier to hack the application, tremendously easier than exploiting the executable binary. From then on, there are other routes to compromise the user's system (and all widely used systems are vulnerable), but point is, at least from the perspective of the individual app developer, that a compromised system alone doesn't compromise the user's data in my application, as it is stored protected on the file system, but it is exposed in the application. Having the QML engine so insecure and childishly easy to inject any code into the application - that's the big issue here. How easy it is to compromise the QML files on the user's system is secondary and a minor concern. The big problem is how easy QML makes the initial development of the hack.

最后，某些人的偏见是可以理解的，他们的工作围绕 Qt 展开，因为他们的职业责任"是淡化缺陷，这可能会阻碍 Qt 的采用，从而阻碍他们的业务，即使是专业人士，在以下情况下也是非常不道德的用户的安全和隐私受到威胁.努力降低风险并不是提高产品声誉的最佳方式，这些风险不会因为您否认它们而消失，但是如果您改进产品，它们就会消失.与成为头条新闻的潜在高调数据泄漏相比，承认风险并承诺修复它们肯定会少得多尴尬.

Lastly, the bias of certain people, whose jobs revolve around Qt is understandable, as is their "professional duty" to downplay flaws, which might hamper its adoption and therefore their business, and even if professional, it is highly unethical when the security and privacy of users is at stake. Investing efforts into undermining the risks is hardly the best way to improve on your product's reputation, those risks will not go away just because you are denying them, they will however go away if you improve on your product. Admitting to the risks and committing to fixing them will surely be a while lot less embarrassing than a potential high profile data leak that makes the headlines.

推荐答案

使用 Qt 5.7，Qt 的静态构建(使用 -static 配置 Qt)将导致属于 Qt 模块的 QML 文件通过资源系统构建到插件中.例如，考虑Qt Graphical Effects 中的相关变化 模块.下面是修改前qtbase/qml/QtGraphicalEffects的目录列表:

With Qt 5.7, static builds of Qt (configuring Qt with -static) will cause QML files belonging to Qt modules to be built into a plugin via the resource system. For example, consider the relevant change in the Qt Graphical Effects module. Here is the directory listing of qtbase/qml/QtGraphicalEffects before the changes:

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 文件更加困难的一种方法.

This is one way of making it harder to access the QML files of Qt modules.

这篇关于QML 应用程序和安全性 - 有吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！