Линия смерти.

Источник: The Line Of Death.
Автор:  Eric Lawrence.
Перевод: .

В ходе создания приложений, функционал которых предусматривает отображение контента из непроверенных источников, отвечающие за безопасность разработчики сталкиваются с серьезной проблемой. Если, к примеру, злоумышленник получит полный контроль над определенной группой пикселей, то он без труда сможет сделать так, что эта группа пикселей будет выглядеть нужным для него образом. Маскируя подконтрольную ему область экрана под фрагмент пользовательского интерфейса самого же приложения, взломщик может склонить пользователя к небезопасным действиям, причем пользователь, совершая их, может даже не заметить, что произошло что-то плохое.

Если говорить о веб-обозревателях, то в них, как правило, верхняя область окна является полностью подконтрольной браузеру, а все нижележащие пиксели, контролируются сайтом. Не так давно я услышал, что разделяющую эти области линию называют "Line of death" («Линия смерти»):

Когда пользователь доверительно относится к верхней области окна, то мышление подсказывает ему, что представленный в ней контент не причинит ему вреда. Однако если убедить пользователя в безопасности пикселей, находящихся по нижнюю сторону линии, то его ждут серьезные неприятности.

Проблема в том, что в реальности эта ключевая демаркация остается невидимой для пользователя. Более того, мы, к сожалению, не можем с уверенностью назвать такую демаркацию абсолютно точной и окончательной.

Вот вам пример. По причине малого размера находящейся сверху LoD (Line of Death — линия смерти) области, в некоторых случаях для отображения доверенного UI может потребоваться больше места. В Chrome данную проблему пытаются решить с помощью маленького шеврона (*направленного вверх остроконечного фрагмента границы элемента), который пересекает LoD:

…таким способом пытаются обозначить расширение области надежного контента, поскольку по логике непроверенный контент не может пересекать LoD. К сожалению, внимательно рассмотрев скриншоты, в данном техническом решении можно увидеть отсутствие последовательности. Первый вариант шеврона информационного всплывающего окна (* так называемый flyout — диалоговое, всплывающее окно-подсказка или контекстное меню) указывает на нижнюю часть пиктограммы замка, а само окно при этом накладывается на LoD. Следующее же окно (в данном случае диалоговый flyout) содержит шеврон, который упирается в нижнюю грань омнибокса (*адресная строка), таким образом лишь касаясь «линии смерти». Иногда шеврон может вовсе отсутствовать, как это происходит в случае с диалоговым окном при аутентификации.

Увы, шеврон является слабо убедительным элементом, и я полагаю, что большинство пользователей просто не в состоянии отличить настоящий шеврон от поддельного, который последнее время начали использовать некоторые сайты:

Вы, вероятно, спросите: «А смысл им подделывать предложение о включении уведомлений? В чем секрет?» Дело в том, что если вы имеете дело с настоящим приглашением, то при клике на Block вас, скорее всего, больше не будут беспокоить по этому поводу. А в случае с поддельным предложением вас могут завалить спамом. С другой стороны, нажав Allow, они тут же предоставят вам подлинное приглашение.

Ситуация усугубляется еще и тем, что злоумышленник может разместить свои данные выше LoD. То есть осознание риска взлома системы безопасности при обращении к нижележащему контенту, не может гарантировать нам исключение подобных ситуаций, поскольку выше той самой линии тоже существуют потенциально опасные в плане безопасности места. Более детальная карта «смертельных зон» выглядит следующим образом:

В Зоне 1 показываются устанавливаемые на выбор злоумышленника название страницы и иконка. Эти данные на 100% подконтрольны взломщику и могут полностью состоять из дезориентирующей информации и лжи.

В рамках Зоны 2 содержится доменное имя ресурса нарушителя. Некоторые знатоки информационной безопасности могут утверждать, что это единственный заслуживающий доверия компонент URL, а поскольку в адресе используется схема HTTPS, то доменное имя корректно идентифицирует сайт, к которому вы в данный момент подключены. Но, к сожалению, ваше представление о заслуживающем доверия ресурсе может отличаться от мнения экспертов на этот счет. Так, к примеру, адрес https://paypal-account.com/ скорее всего, соответствует доменному имени загруженного вами ресурса, однако он не имеет никакого отношения к легитимной платежной системе размещенной на https://paypal.com/.

Компонент URL, содержащий путь к целевому файлу ресурса, находится в Зоне 3 и он абсолютно не заслуживает доверия. Адрес http://account-update.com/paypal.com тоже не имеет ничего общего с Paypal. И хотя имитация в этом месте выглядит менее убедительно, хорошим парням будет намного сложнее блокировать подобный ресурс, поскольку определение ложного контента такого типа средствами службы DNS невозможно, кроме того, он не создает каких либо записей в логах службы Certificate Transparency.

Зона 4 — это территория веб-контента, верить которому никак нельзя. Но, увы, применительно к операционным системам с «оконным» интерфейсом ситуация становится еще хуже чем кажется на первый взгляд. Дело в том, что такие системы являются благоприятной средой для атак типа "picture-in-picture" (*изображение в изображении), при которых все окно браузера целиком, включая относящиеся к доверенной области пиксели, могут быть подделаны и соответственно представлять собой опасность:

Многие люди, заслышав о вероятности появления picture-in-picture атаки, испытывают нечто вроде ментальной защитной реакции — «нет, такое может произойти с кем угодно, только не со мной». В большинстве случаев это связано с персонализацией. То есть, пользуясь, к примеру, видоизмененной с помощью пользовательской темы операционной системой или браузером, вы скорее всего подумаете, что обмануть вас будет сложно, поскольку внешний вид системных окон или свойственных браузеру уведомлений вам очень хорошо знаком. Может вы и правы, но поверьте, не в этом случае. Тому есть доказательства.

Время историй.

Еще в 2007 году, когда разработчики IE занимались выпуском в свет сертификатов с расширенной проверкой (EV — Extended Validation), службой Microsof Research был опубликовал документ, ставящий под сомнение эффективность самих сертификатов. В то время представители финансовой компании Fortune 500 провели встречу со специалистами IE с целью оценки возможностей центра EV-сертификации. Они были рады перспективе такого сотрудничества (как, собственно, и мы, так как это была известная компания с естественным синергическим ростом), но проблема picture-in-picture не осталась незамеченной, поскольку на тот момент представляла собой реальную угрозу безопасности.

Представляя сторону разработчиков, я был неприступен, пытаясь в тоже время смягчить ситуацию: «Все это, конечно, интересно, но мне кажется, что такая атака маловероятна.»

В ответ они вручили мне цветное изображение 8.5×11, с уверенностью добавив:«Ни один человек из нашего отдела безопасности не смог сказать, что на этом скриншоте изображена pitcture-in-picture атака.»

«Ну это и понятно» — заявил я, хотя прекрасно понимал серьезность последствий того факта, что они не смогли увидеть очевидные для меня отличия.

«Как?» — возразили они.

«Смотрите. Это IE7, работающий на Windows Vista с темой Aero Glass. А в самом браузере отображена страница, содержащая JPEG изображение того же IE7, но работающего на Windows XP с темой Luna, известной еще как Fisher Price» — отметил я.

«Вот как? Понятно» — был их ответ.

С тех пор мысли об использовании персонализации браузера в качестве эффективного способа защиты покинули меня навсегда.

Были представлены и другие методы снижения риска. Один из центров сертификации создал расширение, позволяющее выявлять подделку путем наведения курсора на пиктограмму замка EV-сервиса (так называемый Trust Bage или «знак доверия»), в результате которого затемняется весь экран, за исключением самой пиктограммы. Другая команда предложила задействовать анализ изображений с целью сканирования текущей страницы на предмет чего-нибудь похожего на поддельный знак EV-сервиса.

Лично я отдал предпочтение подходу, представленному Тайлером Клоузом (Tyler Close), который для идентификации сайта предлагал использовать в браузере плагин PetNames (*«Прозвища»). Результат работы данного расширения можно в какой-то степени сравнить с иконками Граватара подсоленных хешей сертификатов. Присваиваемые плагином прозвища способны были не только сделать внешний вид любого HTTPS сайта уникальным для каждого пользователя, но с их помощью можно было также выявить поддельные или некорректные сертификаты (ранее, во времена, когда стандарт Certificate Transparency был еще недоступен).

Будущее здесь… и оно еще хуже.

Стандартом HTML5 введен Fullscreen API, позволяющий контролировать все окно браузера, а это означает, что «Зона Смерти» станет вот такой:

Разработанный в стиле Metro, ультрасовременный и иммерсивный Internet Explorer в Windows 8 имеет ту же проблему. Дело в том, что он был оформлен по принципу "content over chrome", который просто не оставляет места для надежных, заслуживающих доверия пикселей. Согласно такого дизайна контент предоставляется в виде группы подвижных функциональных боксов. При этом каждый компонент всецело занимает область отведенного для него бокса. Пытаясь улучшить ситуацию, я все же настаивал на присутствии декоративного «знака доверия» (показывающий пиктограмму-замок и безопасный домен-источник) в правой нижней части экрана , но меня не услышали и предложение было отклонено.

Один предприимчивый специалист по тестированию из Windows создал идеальную визуальную подделку сайта Paypal. Эта копия могла даже перехватывать пользовательские жесты, отображающиеся в эфемерном пользовательском интерфейсе браузера, и заменять их фальшивыми идентичными указателями. Могу сказать одно — эта штука выглядела ужасающе. Оставалось только тешить себя надежной, что никто не воспользуется новым режимом.

В действительности, любая мобильная операционная система подвержена той же проблеме. Это связано с ограничениями, налагаемыми на отводимое под пользовательский интерфейс пространство, что в свою очередь приводит к отсутствию пикселей, образующих заслуживающие доверия области экрана. Таким образом создаются благоприятные условия для имитации одного приложения другим или даже фальсификации самой операционной системы.

Ранее, в некоторых операционных системах с целью смягчения данной проблемы использовались так называемые «пользовательские действия безопасности» ("secure user gesture"). Для Windows это комбинация клавиш Ctrl+Alt+Del. В результате их применения всегда показывался доверительный UI. Основным недостатком подобных методов является их радикальность, которая зачастую приводит пользователя к замешательству (ограничивая тем самым эффективность этих мер). Но они, как правило, попадали «под оптимизацию», когда конечным продуктом завладевали специалисты UX департамента.

Интересно будет посмотреть, как стандарт WebVR справится с этой проблемой, масштаб которой будет еще больше.

За пределами браузеров.

В других приложениях тоже присутствует концепция LoD («линии смерти») и веб-приложения тому не исключение. К сожалению, серьезность ситуации в данном случае зачастую просто недооценивают. Вот посмотрите, как выглядит баланс сил в окне отображения электронного сообщения Outlook.com:

Когда Outlook получает email от доверенного адресата, вниманию пользователя предоставляется соответствующее уведомление («Это сообщение получено от надежного адресата»), которое отображается непосредственно внутри «зоны смерти»:

Безопасность пользовательского интерфейса — дело непростое.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *