Содержание статьи
Silverlight, потеснив Flash, занял свою нишу среди платформ для разработки web-приложений с насыщенным пользовательским интерфейсом. Конечно, возможность создания интерфейса, не уступающего по юзабилити и внешнему виду десктопным приложениям, — это круто, но при создании web-приложения нельзя забывать о безопасности. Попробуем разобраться, насколько безопасно размещение Silverlight-контента на web-страницах.
Довольно долго динамика HTML-страниц обеспечивалась за счет использования JavaScript. Он идеально подходит для проверки корректности заполнения форм и простых манипуляций с элементами DOM, но JS не имеет достаточных возможностей для реализации по-настоящему удобного, привлекательного и быстрого пользовательского интерфейса. Поэтому и появились плагины для построения так называемых Rich Internet Application (RIA). Silverlight — один из таких браузерных плагинов. После очевидного провала платформы ActiveX компания Microsoft приложила немало усилий для разработки альтернативного решения. Большое внимание было уделено проблеме безопасности, так как именно проблемы с безопасностью, наряду с отсутствием кроссплатформенности, привели к неудаче ее первой RIA-платформы.
Silverlight основана на платформе .NET, а значит, Silverlight-приложения — это управляемый код, что, согласись, уже представляет собой некоторое достижение в плане безопасности по сравнению с ActiveX, в котором, используя нативные вызовы, можно было творить все что угодно.
Модель безопасности Silverlight
Silverlight следует стандартным принципам, которые применяются при расширении функциональности web-контента с помощью плагинов браузера. Предполагается, что все не-trusted (то есть не установленные пользователем как надежные) Silverlight-приложения потенциально опасны, и плагин ограничивает доступ этих приложений к ресурсам машины. Приложение Silverlight может запускаться в трех возможных режимах, для которых используются различные политики безопасности:
- in browser mode — управляемый Silverlight-код выполняется как часть web-страницы и находится в "песочнице" (sandbox), равно как и остальной контент, например, код на JavaScript. Этот режим является дефолтным, и когда SL-контрол добавлен на страницу с помощью тега object, используется именно он.
- out of browser mode — приложение может выполняться в браузере, а может быть установлено локально на машину пользователя. Этот вид приложений также выполняется в песочнице, и для него существуют практически те же ограничения, что и для inbrowser-приложений, но такие SL-контролы можно запускать как отдельные приложения.
- out of browser trusted mode — доверительный режим выполнения Silverlight-кода предоставляет ему полный доступ к файловой системе, сети и другим ресурсам, но должен быть подтвержден пользователем при установке приложения.
Наибольшую потенциальную опасность представляют собой приложения in browser, поскольку они не требуют от пользователя никаких дополнительных действий для запуска Silverlight-кода, а начинают работать сразу после загрузки web-страницы. Этот способ выполнения Silverlight-кода сейчас наиболее распространен, поэтому речь дальше пойдет в основном о таких контролах.
Sandbox
При ограничении доступа sandboxed-приложений к функциональности платформы существуют два основных принципа:
user initiated — доступ приложений к определенной функциональности (например, использование web-камеры, которое стало возможным в четвертой версии Silverlight) только в ответ на действия пользователя. То есть во время обработки событий KeyDown/KeyUp/MouseDown/MouseUp. Идея простая — контрол не может скрытно, без участия пользователя, совершать потенциально опасные действия. Есть, конечно, социальная инженерия, и многие юзеры могут-таки кликнуть на кнопку, не совсем понимая, что от них хотят, но это уже другой вопрос.
same origin police — если два файла загружены с одного доменного имени, считается, что они получены из одного источника. На взаимодействие объектов, которые загружены из разных источников, накладываются значительные ограничения. Первому принципу соответствуют следующие три фичи системы безопасности Silverlight:
- OpenFileDialog/SaveFileDialog — Silverlight позволяет приложениям читать и писать в файлы, расположенные на машине пользователя, но только после того, как пользователь выберет их в стандартном диалоговом окне. Причем приложение не может предложить дефолтное имя файла и каталог. Для файлов, созданных приложениями Silverlight, будет добавлен атрибут "загружен из сети".
- Webcam/Microphone – SL-приложение начиная с версии 4.0 имеет доступ к микрофону и web-камере, которые установлены на машине пользователя, но только после того, как пользователь подтвердит это. Один раз полученное разрешение действует, пока страница с SL-приложением не будет закрыта. Необходимость такого ограничения понятна: никому не хочется, чтобы за ним подсматривали через web-камеру.
- Clipboard access — начиная с версии 4.0 приложения Silverlight могут получать доступ к системному буферу обмена. Риск, которому при этом подвергаются данные пользователя, очевиден. Поэтому доступ к буферу обмена также должен быть разрешен пользователем в ответ на запрос Silverlight. Принцип ограничения кроссдоменного доступа к локальным данным в Silverlight оформлен в виде isolated storage. Изолированное хранилище данных приложений Silverlight позволяет странице сохранять данные в специальном каталоге на жестком диске клиентской машины. Приложения Silverlight, загруженные с одного домена, делят одно изолированное хранилище и имеют доступ к сохраненным данным друг друга. По умолчанию на каждый домен выделяется до 1 Мб дискового пространства, но этот предел может быть увеличен пользователем по запросу приложения.
Сетевое взаимодействие
Из-за наличия firewall’ов приложение Silverlight, выполняемое на машине пользователя, может иметь доступ к серверам, к которым не имеет доступа источник, с которого оно было загружено. В целях предотвращения неавторизованного доступа SL требует, чтобы сторонние сервера имели файлы кроссдоменной политики, хранящие список доменов, с которых разрешено к ним обращаться. Silverlight поддерживает два типа файлов, отвечающих за кроссдоменную политику:
- crossdomain.xml — файл кроссдоменной политики, который использует Flash-плеер:
<?xml version="1.0"?>
<cross-domain-policy>
<allow-http-request-headers-from domain="*" headers="SOAPAction,Content-Type"/>
</cross-domain-policy>
- clientaccesspolicy.xml — собственный формат, используемый Silverlight:
<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="SOAPAction">
<domain uri="*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
Так же, как для тега <img> в HTML, объекты Image и Media в Silverlight способны загружать изображения и медиафайлы с любого домена без дополнительных ограничений. Но для предотвращения утечки информации на домен-источник SL-приложения, оно не имеет доступа к контенту этих файлов и даже не может точно определить, есть файл с таким именем или нет. В дополнение к HTTP-запросам, Silverlight позволяет приложениям использовать TCP/UDP-сокеты. Однако порты, к которым будет коннектиться приложение, должны быть явно прописаны в файле кроссдоменной политики. Для предотвращения конфликта с другими сервисами диапазон портов ограничен, и коннектиться можно к TCP/UDP-портам 4502-4534. Поддерживаются только исходящие соединения. Создать слушающий сокет в Silverlight-приложениях невозможно.
Десктопные приложения Silverlight
Приложение out of browser — это обычное inbrowser-приложение Silverlight, которое пользователь установил на свою машину локально, выбрав пункт "install" из контекстного меню Silverlight. Как уже было сказано выше, десктопные SL-приложения могут быть либо sandboxed, либо trusted. Песочница для десктопных приложений Silverlight создает те же ограничения, что и для браузерных Silverligt-контролов, кроме следующих:
- размер изолированного хранилища по умолчанию увеличен до 25 Мб;
- можно изменять размер окна приложения (в не-trusted приложениях эта возможность запрещена, чтобы предотвратить "click jacking" атаку, когда из-за изменения размера окна происходит клик не на том элементе, на котором хотел кликнуть пользователь).
Что касается trusted-приложений, то они запускаются вне песочницы и получают доступ к дополнительной функциональности платформы:
- возможность вызова методов COM-серверов;
- свободное чтение/запись файлов;
- кроссдоменные запросы возможны без файлов кроссдоменной политики на сервере.
Но поскольку trusted Silverlight-приложения все же представляют собой управляемый код, они менее подвержены таким ошибкам как переполнение буфера или целых чисел и, соответственно, более безопасны, чем нативные.
Эксплуатация уязвимостей Silverlight-контролов
Как и в случае JavaScript + HTML, при использовании Silverlight-приложений существует возможность cross site scripting (XSS) атаки, когда можно исполнять код на машине клиента так, как будто он был загружен с сайта-жертвы. XSS открывает доступ к кукам, изолированному хранилищу и информации об авторизации сайта-жертвы. Стандартное исполнение XSS – это инжект HTML/JavaScript-кода за счет дыр в обработке ввода пользователя сайта, который передается на сервер. Возможность реализации XSS-атаки через Silverlight-контролы есть, но она менее вероятна, чем в обычном HTML/JavaScript.
XSS обычно происходит из-за того, что злоумышленник получает возможность добавлять строки на страницу без экранирования HTML-тегов. Однако Silverlight-приложения редко формирует HTML- или XAML-код простым объединением строк, то есть, в них намного чаще можно видеть
mybox.Text = badString;
вместо
XamlReader.Load("<TextBlock.Text= " + badString + "/>"
Таким образом, XSS-атака возможна, если SL-контрол делает что-нибудь вроде:
- XamlReader.Load() со строкой злоумышленника;
- Assembly.Load() c Dll, которую может подменить злоумышленник;
- SL-контрол использует неэкранированные строки при создании XAML- или HTML-разметки через System.Windows.Browser;
- SL-приложение использует сторонние xap-файлы и есть возможность загрузки таких файлов клиентом на сервер.
Во всех этих случаях необходим анализ xap-файла для поиска таких уязвимостей. На самом деле Silverlight-сборки очень редко обрабатывают обфускатором, а реверсинг managed-приложений — задача попроще, чем реверсинг native-кода. Поэтому анализ контрола на подобные уязвимости не слишком сложен.
Следует сказать, что наиболее распространенная XSS GIFAR-атака, при которой загружаемый медиа-контент может быть исполнен плагином, в случае с Silverlight невозможна, поскольку Silverlight-плагин считает объект Silverlight-приложением только если для него задан корректный MIME Type "application/x-silverlight-app".
И, наконец, существует возможность использовать .xap-файлы для стандартной heap-spray атаки, как и другой подгружаемый браузером контент. В этом случае блоки native-кода, которыми засоряется куча браузера, располагаются в xap-файле, что делает heap-spray менее очевидной при анализе web-страницы.
Как сделать Silverlight-контролы более безопасными?
Если на твоей странице располагаются сторонние Silverlight-контролы, которым ты не очень доверяешь, то один из возможных способов защиты — это задать свойство EnableHtmlAccess у тега object, в котором подгружается Silverlight-контрол. Это свойство определяет, возможен ли доступ со стороны SL-контрола к HTML-контенту и методам JavaScript. По умолчанию это свойство устанавливается в true, если страница и контрол загружены с одного домена, и в false — в противном случае. Если ты хочешь, чтобы твой Silverlight-контрол нельзя было повесить на чужую страницу, можно добавить в код инициализации следующие строки:
if (App.Current.Host.Settings.EnableHTMLAccess == false) throw new Exception();
string htmlurl = System.Windows.Browser.HtmlPage.Document.DocumentUri.ToString();
if (htmlurl != "http://my.com/my.html") throw new Exception();
Если со стороны Silverlight-контрола на сервер уходят данные, то на стороне сервера необходимо их правильно обработать:
- в опасных местах (например, обращение к базе) нужно проверять и экранировать данные от Silverlight-контрола, так как они могут содержать, например, SQL инъекции;
- для большей надежности можно проверять сайт-источник запроса (возможность задать referer появилась в Silverlight 4.0).
Если тебе нужно сохранять важные данные в изолированном хранилище, то необходимо шифровать их. Равно как и куки, данные из IS могут быть доступны администратору машины. Кроме того, IS доступно для любого приложения с того же домена. Иначе говоря, если кто-то контролирует DNS жертвы, он может получить доступ к этим данным. Другой способ неавторизованного доступа к IS — XSS описан выше.
Заключение
Silverlight-платформа сама по себе довольно безопасна, но решающее значение, как это обычно бывает, имеет то, как она используется. Silverlight-контрол, созданный без внимания к безопасности, может оказаться слабым звеном web-страницы и легкой добычей для хакера.
