我有兴趣将Mylar用于即将开展的项目。
Mylar的承诺令人印象深刻。但是，开发人员是否可以在代码中写入后门攻击，允许运行（通过哈希/签名验证），以便数据受到威胁（可能通过XSS）？ Mylar文档说明：
＆＃34; Mylar确保客户端应用程序代码是可信的，即使是 服务器是恶意的。＆＃34;
我可以想象这是受到保护的唯一方法是浏览器本身不允许未加密数据的出站通信。但是，为了实现这一点，应用程序如何查询数据库，回调服务器（我知道Mylar最适合使用像Meteor这样的浏览器端框架，但仍然，Meteor需要与服务器通信以执行某些任务）。
Mylar是否能够提供完整的数据安全性，即使是来自应用程序开发人员/服务器管理员？
这是Mylar的声明（来自http://www.mit.edu/~ralucap/mylar.pdf）：
3.4威胁模型
威胁。攻击者可以完全控制应用程序和数据库服务器：攻击者可以获取所有数据 从服务器，导致服务器向Web发送任意响应 浏览器等。该模型包含广泛的现实世界安全性 问题，从服务器软件中的漏洞到内部攻击。聚酯薄膜也 允许一些用户机器由对手控制，并且 与服务器勾结。这可能是因为对手是a 应用程序的用户，或者因为对手闯入了用户的用户 机。与被动者相比，我们称这个对手为主动 在服务器上窃听所有信息的对手，但确实如此 不做任何更改，以便服务器响应所有客户端 请求好像没有受到损害。
保证。 Mylar保护数据项在面对任意服务器妥协时的机密性，只要没有用户 访问该数据项使用受感染的计算机。
在这种背景下，“受感染的机器”＃39;表示客户机/浏览器。
重新阅读Mylar white paper后，我会看到文档的位置：
假设。为了提供上述保证，Mylar制作了 以下假设。 Mylar假设Web应用程序为 由开发人员编写的不会发送用户数据或密钥 不值得信任的收件人，并且不能被欺骗 利用错误（例如，跨站点脚本）。我们的Mylar原型 建立在Meteor之上，这是一个帮助程序员避免的框架 在实践中有许多常见的错误类型。
这是指在加密时还是在攻击时编写应用程序的方式？换句话说，加密数据是否以某种方式与应用程序代码的特定版本相关联？在referenced Mylar white paper的其他地方，它表示应用程序代码是根据哈希签名进行验证的。
如果应用程序代码只能在服务器上被黑客攻击，这会极大地降低价值主张，因为任何获得源代码访问权限的攻击者都可以修改代码并按照请求（在浏览器中）获取数据。保证在面对任意服务器危害时保护机密性＆＃34;似乎足够广泛，包括攻击者修改应用程序源代码的想法，因此我感到困惑。
有关详细信息，另请参阅白皮书中的第6节。我相信Mylar doc正在传达它确实可以缓解受到破坏的应用程序代码攻击。我非常希望听到对Mylar有权威理解的开发人员。
答案 0 :(得分：3)
...开发人员可以在代码中写入后门攻击，允许运行（通过哈希/签名验证），以便数据受到威胁（可能通过XSS）？
是的，开发人员可以在代码中编写后门。没有办法阻止这种情况，因为开发人员可以声称他使用Mylar，尽管他没有或确实使用了受损版本。请注意，Mylar没有说，它可以防止这种情况发生。 它可以阻止服务器运营商的攻击，例如，如果您将应用程序托管在第三方云中。
3 MYLAR建筑
Mylar有三个不同的方：用户，网站所有者和服务器运营商。 Mylar的目标是帮助网站所有者在面对恶意或受到威胁的服务器运营商时保护用户的机密数据。
如果您不信任开发人员或网站所有者，则必须在加载时检查客户端源代码。
Mylar文档说明：＆＃34; Mylar确保客户端应用程序代码是可信的，即使服务器是恶意的。＆＃34;
我可以想象这是受到保护的唯一方法是浏览器本身禁止未加密数据的出站通信。但是，为了实现这一点，应用程序如何查询数据库，回调服务器 [...]
Mylar是否能够提供完整的数据安全性，即使是来自应用程序开发人员/服务器管理员？
没错，浏览器不会将未加密的数据发送到服务器（至少是您标记为机密的数据）。我无法提供有关如何在加密数据上允许大量SQL功能的完整说明，因为它很复杂。 As Raluca Ada Popa explains in one of her presentations，使用不同的算法对数据进行多次加密，因为每种算法都允许对加密数据进行不同的操作（相等检查，排序，文本搜索......）。麻省理工学院还开发了CryptDB，它使用相同的方法，但只保护数据库服务器。
3.4威胁模型：应用程序和数据库服务器都可以完全由对手控制 [...]
当攻击者控制应用程序服务器时，他可以用自己的应用程序交换整个应用程序，这会嘲弄原始用户界面。这里有浏览器插件：该应用程序在部署之前由网站所有者签名，因此浏览器插件可以检查签名并在应用程序被修改时向用户发出警告
您可能已经注意到Mylar需要用户自己检查真实性。用户需要注意的其他事项：
Mylar假设开发人员编写的Web应用程序不会将用户数据或密钥发送给不值得信任的收件人，并且不能通过利用错误（例如，跨站点脚本）来欺骗
这是指在加密时还是在攻击时编写应用程序的方式？
他们认为交付的应用程序不包含任何可能泄露私人数据的错误。 Mylar不会阻止编码错误，它会阻止以后进行不受信任的修改。
换句话说，加密数据是否与某个特定版本的应用程序代码绑定在一起？在referenced Mylar white paper的其他地方，它表示应用代码是根据哈希签名进行验证的。
如果应用程序代码可以简单地在服务器上被黑客入侵，这会大大降低价值主张，因为任何获得源代码访问权限的攻击者都可以修改代码并根据请求获取数据（在浏览器中） ）。
加密数据与特定版本无关。每个版本的应用程序都需要由网站所有者签名，以便浏览器插件可以检查它的签名和攻击对用户来说是显而易见的。 一个常见的动态网站不允许签名，因为每个用户数据不同并会修改收到的代码，因此应用程序代码（HTML，JavaScript，...）和数据都是严格分开。加载应用程序并检查其签名后，通过AJAX检索数据，而AJAX响应不得包含可执行代码（这是Meteor framework的一部分，我无法告诉任何内容关于它）。
<强>结论