Silverlight: защита и нападение

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:

1. OpenFileDialog/SaveFileDialog — Silverlight позволяет приложениям читать и писать в файлы, расположенные на машине пользователя, но только после того, как пользователь выберет их в стандартном диалоговом окне. Причем приложение не может предложить дефолтное имя файла и каталог. Для файлов, созданных приложениями Silverlight, будет добавлен атрибут "загружен из сети".
2. Webcam/Microphone – SL-приложение начиная с версии 4.0 имеет доступ к микрофону и web-камере, которые установлены на машине пользователя, но только после того, как пользователь подтвердит это. Один раз полученное разрешение действует, пока страница с SL-приложением не будет закрыта. Необходимость такого ограничения понятна: никому не хочется, чтобы за ним подсматривали через web-камеру.
3. Clipboard access — начиная с версии 4.0 приложения Silverlight могут получать доступ к системному буферу обмена. Риск, которому при этом подвергаются данные пользователя, очевиден. Поэтому доступ к буферу обмена также должен быть разрешен пользователем в ответ на запрос Silverlight. Принцип ограничения кроссдоменного доступа к локальным данным в Silverlight оформлен в виде isolated storage. Изолированное хранилище данных приложений Silverlight позволяет странице сохранять данные в специальном каталоге на жестком диске клиентской машины. Приложения Silverlight, загруженные с одного домена, делят одно изолированное хранилище и имеют доступ к сохраненным данным друг друга. По умолчанию на каждый домен выделяется до 1 Мб дискового пространства, но этот предел может быть увеличен пользователем по запросу приложения.

Сетевое взаимодействие

Из-за наличия firewall’ов приложение Silverlight, выполняемое на машине пользователя, может иметь доступ к серверам, к которым не имеет доступа источник, с которого оно было загружено. В целях предотвращения неавторизованного доступа SL требует, чтобы сторонние сервера имели файлы кроссдоменной политики, хранящие список доменов, с которых разрешено к ним обращаться. Silverlight поддерживает два типа файлов, отвечающих за кроссдоменную политику:

1. crossdomain.xml — файл кроссдоменной политики, который использует Flash-плеер:

<?xml version="1.0"?>
<cross-domain-policy>
    <allow-http-request-headers-from domain="*" headers="SOAPAction,Content-Type"/>
</cross-domain-policy>

2. 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-страницы и легкой добычей для хакера.