当开发的应用程序在展示一些不受信任的内容时，安全设计人员有一个非常重要的问题需要考虑——如果攻击者完全控制了一个像素块，那么他就可以使这些像素点看起来像是任何他想要的东西，包括应用程序本身的UI设计，再之后他就可以诱使用户去进行一些 不安全的动作，而用户则完全处在一种不知情的状态。

在我们的网络浏览器中，浏览器本身通常会完全的去控制窗口的顶部，而顶部的像素则会在网站的控制之下，就在最近我了解到这一条线其实被称为是死亡线（the line of death）：

 

原因就在于，如果用户相信这条线以上的像素其实它们是安全的，但如果他们选择了相信这条线以下的像素，那结果将极为惨淡，可能会带来“死亡”。

非常不幸的是，这个非常关键的界限并没有明确的去告诉用户，而更为不幸的是，这条线并不是绝对的。

例如，由于LoD（死亡线）上面的区域非常小，所以有时需要更多的空间来显示受信任的UI，而Chrome则尝试通过显示一个穿过LoD的小V形来解决此问题：

 

 

其实这是因为不可信的标记不能过LoD而不得已为之的。不幸的是，你可以在截图中看到，所得到的对待是不一样的：在PageInfo弹出的窗口中，V形指向锁的底部，PageInfo框与LoD重叠，而在Permission的弹出窗口中，V形则指向多功能框的底部，而Permission框仅抵靠LoD。 有时则会省略V形，如在认证对话框的情况下。

令人感叹的是V形显得很微妙的，我期望大多数用户会落到一个假的V形陷阱里，就像一些网站已经开始使用下图这种：

 

实际上，更大的问题在于一些攻击者的数据是被允许超过LoD的，也就是说不论是线的下面还是线的上面的内容，如果用户都简单的选择了信任，那么安全问题将非常堪忧。而更为准确的死亡范围可能是如下这种情况：

 

区域1可以显示攻击者选择的图标和页面标题，这些信息会完全被攻击者控制，所以这里的内容很可能会完全由攻击者的欺诈内容组成。

区域2则可以用来显示攻击者的域名，一些信息安全专家往往认为这是URL唯一“可信赖”的组件，因为如果URL是HTTPS，那么域名会正确的链接到你的站点。不幸的是，这个它可以信赖的想法可能并不存在，例如 https://paypal-account.com/可能是你加载的域名，但它与https://paypal.com内的合法付款服务却没有关系。

区域3中URL的路径组件是完全不可信的，比如链接 http://account-update.com/paypal.com/与Paypal完全无关，虽然欺骗性的内容在这里很难受到信服，但也会导致更难以被防范，因为如果没有找到欺骗内容，那么就不会在证书的透明日志中创建任何记录。

区域4是WEB内容的区域，这个部分的内容没有什么是值得信任的。但更为不幸的是，在Windows操作系统中，这部分显得更为糟糕，因为还会出现picture-in-picture攻击的可能性，特别是在整个的浏览器窗口中，包括其可信的像素都是可以伪造的：

 

当听到picture-in-picture攻击时，许多人会立即集思广益来进行防御，其中很多都与个性化有关。 例如，如果你运行你的操作系统或浏览器时选择自定义主题，那么你就不会被愚弄。 不幸的是，有证据表明情况并非如此。

早在2007年，IE团队当时推出了扩展验证（EV）证书，而Microsoft Research发布了一份文件，来质疑其有效性。这时有一家世界500强的金融公司来与IE团队进行对接，进而评估其公司是否需要接入EV证书颁发机构的业务。他们对这一业务的前景感到非常的兴奋，但他们指出，picture-in-picture的问题很可能是一个致命的缺陷。

IE团队的人这样说道，“我们处在一个防守阶段，我们承认这种攻击很有趣，但我们并不认为这种攻击是可能出现的。”

而那家公司则反驳称，“我们用这个截图询问了我们整个信息安全部门，但没有人能够告诉我它是一个picture-in-picture攻击。你能吗？”，他们在桌子上滑动着一个8.5×11的彩色打印。

IE团队的人一开始感到很兴奋，但最终却意识到了问题的严重性。他们这样说道，“此图为Windows Vista 上运行的IE7浏览器图，背景主题为透明Aero Glass效果，其中还包含一页主题为Luna aka Fisher Price的Windows XP上运行的 IE7浏览器JPEG”。他们能想出来的方法就是去使用浏览器的个性化来有效的缓解当天可能遭遇问题的命运。同时也提出了其他的缓解措施：在CA上构建一个扩展，将鼠标悬停在EV的锁定图标（“Trust Badge”）上会使整个屏幕变暗，除了徽章。另外还有团队建议使用图像分析来扫描当前网页，查找任何看起来像假EV徽章的内容。

而就我个人而言，我最喜欢的方法是Tyler Close的想法，浏览器应该使用PetNames来进行网站身份认证– 考虑将他们作为加盐证书哈希的Gravatar图标 ，而不仅仅使他们每个HTTPS网站的身份认证看起来像是对每个用户都是唯一的。不过这种方法也可能被用作检测欺诈或误发证书的手段（这是在我们拥有证书透明度之前的一个世界）。

技术的进步能否解决这一问题？

Html5中添加了全屏的API，而这意味着“死亡区”看起来像是这样子：zodfullscreen

 

Windows 8中Internet Explorer的Metro / Immersive / Modern模式也有同样的问题，因为它是用“内容超过Chrome”的哲学设计的，所以它并没有可靠的可以信赖的像素。有人曾经建议将一个持久的信任标识嵌在屏幕的右下角（显示安全起源和锁），但却被推翻了。 而在Windows中任何一个有能力的安全测试器都可以在视觉上完美的创造出Paypal的欺骗网站，并且其中即使是临时浏览器UI被拦截以及假指示器都会有用户手势的展示。这是可怕的东西，现在只有祈祷没有人会使用更新的模式了。

实际上，所有移动操作系统都存在相同的问题 – 由于UI空间占据，没有可信任的像素，从而允许任何应用程序欺骗另一个应用程序或操作系统本身。历史上，一些操作系统试图通过引入一个总是显示可信UI的安全用户手势（比如在Windows上，它的Ctrl + Alt + Delete）来缓解这个问题，但是这些措施往往会混淆用户（限制他们的有效性），并经常当UX团队的设计师把控产品时被优化掉。

令人感到兴奋的是，我们会非常期待来看看WebVR是如何以更大的规模的解决这个问题的。

不仅仅是浏览器

当然，其他应用程序也有LoD的概念，包括Web应用程序。 但仍然感到不幸的是，他们也经常犯这个错误，比如Outlook.com对电子邮件的呈现：

 

当Outlook收到来自可信任发件人的电子邮件时，会通过“此邮件来自受信任的发件人”通知用户。 而它会直接出现在“死亡区”内：

 

毫无疑问，这一问题增加了使UI安全性提高的难度。