Блог Сергея Байдачного

Мой блог о технологиях

Archive for Январь 2010

Простые вещи о безопасности

with one comment

Сижу дома, болею, никого не трогаю. Но, изучая работу «песочницы» для SharePoint 2010, решил проверить, подписывает ли VS 2010 сборки для проектов, которые разворачивает в «песочницу» — подписывает. На фоне этого вспомнил о старых и «хорошо знакомых» вещах, связанных с цифровой подписью, о чем и написал предыдущий пост. И тут же получил комментарий – мол не интересно, все можно найти в MSDN. Оно конечно можно, но этот комментарий побудил меня написать еще один пост, связанный с безопасностью. Я об этом часто рассказываю, об этом написано в MSDN, об этом написано везде, но я сталкиваюсь с этим регулярно.

Итак, была у меня учетная запись в одной онлайн банковской системе. Назовем ее eBank. Система работала замечательно (хотя и была написана какими-то студентами) и позволяла делать много полезных вещей (создавать счета в разных валютах, оформлять переводы и т. д.). И вот, в один прекрасный день, систему решили улучшить. Ну, как у нас принято, переписатьJ Проблема в том, что те студенты уже ушли (в банках платят не очень, а любое повышение в 10 баксов выставляют как мега событие). Поэтому систему писали уже другие студенты. А Вы все знаете, что уровень нынешних студентов уже не тот…

Так вот, сижу я месяц – не работает, три – не работает. Месяцев через шесть, начинаю связываться со службой поддержки. Мол, так и так, когда заработает. А в службе поддержки мне отвечают, что работает уже как полгода. Мне от этого не жарко и не холодно – войти в систему я не могу, появляется страшная ошибка. Пообщавшись, некоторое время, с поддержкой, я получил рекомендацию: «переустановить операционную систему (мало ли что с моими настройками) и обновить браузер IE 6 на IE 5» (еще бы Оперу предложили).

Естественно, рекомендации я выполнять не стал, так как на тот момент уже немного умел программировать. Я просто попросил поменять пароль. Меняли пароль мне дня три. Процедура очень сложная. Отдали в запечатанном конверте, пароль был «123456». После этого я перестал пользоваться услугами этого банка.

В чем же была проблема? В конкатенации строк при построение запроса, который выглядел примерно следующим образом:

“Select count(*) from UserTable where Login=”+login+” and Password=“+password+”

Как вы знаете, текстовые значения в SQL заключаются в апострофы (одинарные кавычки), а мой пароль как раз и содержал апостроф (предположим 123’45). Следовательно, мой запрос выглядел примерно так:

Select count(*) from UserTable where Login=sbad and Password=12345

То есть, в качестве пароля подставлялось 123, а 45’ ассоциировалось с неизвестной командой, что и вызывало ошибку.

Конечно, можно было попробовать в качестве логина (или пароля) ввести одну из двух команд:

“1 or 1=1 —“ – входим в системуJ

“1; drop table UserTable —“ – проверим, случайно не администратор ли используется для входа в системуJ

Естественно, вторая команда работать не будет, если пользователь, под которым работает приложение, имеет минимум прав (то есть не умеет удалять таблицы).

А вот теперь запишем еще два правила, которые следуют из этой истории.

Правило 1. Ваше приложение не должно взаимодействовать с базой данных под правами администратора. Создайте специальный аккаунт приложения, который будет иметь ровно те права, которые необходимы для работы приложения. Сознайтесь, что Вы часто писали код, использующий права администратора?

Правило 2. Не используйте конкатенацию строк для формирования запросов к БД. На мой взгляд, запросам в коде вообще делать нечего (поэтому я не люблю LINQ).

И, наконец, чтобы обучить начинающего разработчика всем этим премудростям, существует множество утилит, выполняющих статический анализ кода. Если Вы используете Visual Studio, то анализатор встроен в оболочку и анализ SQL запросов там есть:

clip_image002

А если Вы используете и Team Foundation Server, то можете сделать прохождение кода через анализатор перед его выгрузкой в хранилище, обязательным правилом – пусть учатся.

Да, я злой:)

Реклама

Written by Sergiy Baydachnyy

29.01.2010 at 20:46

Опубликовано в Security

Tagged with ,

Сборки со строгим именем: повышение уровня безопасности приложения

5 комментариев

Всегда, рассказывая о сборках со строгим именем, я делал основной акцент на механизме развертывания подобных сборок.

Как Вы помните, при работе с неуправляемым кодом, все динамические библиотеки сохранялись в одной директории (System32). При этом не было никакого механизма хранения нескольких версий библиотек. Различить библиотеки можно было только по имени, которое совсем не информативно и не несет информации о версии, культуре и т. д.

С появлением .NET Framework ситуация кардинально поменялась.

С одной стороны, практически все управляемые библиотеки начали размещать в Глобальном кеше сборок (GAC), который представляет собой целый набор вложенных директорий, количество которых зависит от количества развернутых сборок. Так, каждой сборки соответствует своя директория. При этом задача развертывания ложится на вспомогательные утилиты, такие как gacutil.

С одной стороны, чтобы избежать путаницы, характерной для неуправляемых библиотек, сборки начали делить на два типа: сборки со строгим именем и сборки с нестрогим именем. Сборки с нестрогим именем размещаются только в директории самого приложения и не могут использоваться другими продуктами. Сборки со строгим именем могут быть развернуты в GAC и использоваться всеми приложениями системы. Основное различие между двумя типами сборок состоит в том, что для сборок со строгим именем в качестве имени учитывается не только имя файла (.dll), но и ряд других параметров, которые содержатся внутри сборки: версия сборки, культура сборки (языковая принадлежность) и цифровой ключ. Данные параметры позволяют развернуть несколько сборок с одинаковым именем, но с различными версиями или культурой. Таким образом, более старые приложения могут ссылаться на старые версии сборки, а новые – на более новые. Цифровой ключ позволяет полностью исключить тот вариант, когда две компании поставляют сборки с одним именем, версией и культурой.

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

Правило 1. Всегда старайтесь создавать сборки со строгим именем.

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

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

Сам я принимал участие в создании нескольких приложений, где сборки загружались динамически (например, сборка могла содержать новые отчеты, которые автоматически интегрировались в систему). При таком подходе, сборку подменить очень легко.

Правило 2. Ключ эффективен, если он содержится в безопасном месте.

Часто приходится сталкиваться с разработчиками, которые недовольны своим прошлым (текущим) местом работы и затаили обиду на работодателя. Например, работодатель может лишить сотрудника каких-то благ или премии, чтобы сохранить стоимость акций. Насколько сложно такому сотруднику сделать копию файла .snk и отправить его потенциальным взломщикам? Полагаю, что это не проблема вообще. Поэтому, подписывая Ваши сборки, храните ключ в надежном месте, а разработчикам выдайте открытую часть ключа, что позволит им использовать сборки без полной подписи.

Выделить открытую часть ключа можно следующей командой:

Sn.exe –p «ключ.snk» «открытый ключ.snk»

Настроить компьютеры разработчиков для игнорирования подписи можно с помощью команды:

Sn.exe –Vr «имя сборки» «открытый ключ»

Кроме этого нужно прописать атрибут [assembly: AssemblyDelaySign(true)], говорящий об отложенном подписании сборки.

Written by Sergiy Baydachnyy

29.01.2010 at 15:08

Опубликовано в .NET Development, Security

Tagged with ,

SharePoint 2010: Что нового? (часть 4) – Песочница

2 комментария

В одной из статей MSDN (http://msdn.microsoft.com/en-us/library/aa302436.aspx) описывается способ изолировать приложения с помощью установки различных уровней безопасности доступа кода (Code Access Security). Одна из областей применения CAS – хостинг веб приложений. Ведь с помощью атрибутов в конфигурационном файле или программно, хостер может разместить Веб-приложение, назначив ему определенные права доступа к различным ресурсам. При этом все приложения могут успешно работать под одним пользователем (ASPNET), а иметь абсолютно разный уровень доступа к ресурсам.

На практике мне не удавалось видеть много веб-приложений, использующих CAS. Большинство хостеров ограничивается отдельным пулом приложений для каждого веб-приложения (а некоторые не делают и этого). Но SharePoint 2010 использует именно CAS для реализации такого понятия как «песочница». Рассмотрим этот вопрос подробно.

Если Вы сталкивались с SharePoint 2007, то могли заметить, что развернуть решение под SharePoint мог только администратор сервера. Иными словами, если бы Вы задумали реализовать хостинг на базе SharePoint 2007, то Вам пришлось бы ограничить своих клиентов предопределенным набором фич, то есть предоставлять готовое веб-приложение, обладающее всей необходимой функциональностью. Как альтернативу, Вам пришлось бы принимать регулярные запросы от клиентов, с просьбой развернуть ту или иную фичу. При этом, механизмов проверки фичи на «профпригодность» не было, а развертывание некоторых сборок в GAC могло навредить всей системе. Именно поэтому, SharePoint 2010 позволяет разворачивать собственные решения не только под правами администратора сервера, но и под правами обычного владельца коллекции сайтов. При этом решения обладают всеми (практически) атрибутами, включая определение списков, веб-части, доступ к API и т. д.

Чтобы реализовать механизм развертывания решений под правами владельца коллекции, в SharePoint 2010 был реализован механизм песочница. Данный механизм позволяет развернуть решение, которое будет выполняться в изолированной рабочем процессе, с ограниченными правами, как раз и определяющимися с помощью Безопасности доступа кода (CAS). Эти права позволяют использовать API на уровне сайта (коллекции), но не веб-сервера или фермы серверов, запрещают развертывание в GAC и исключают влияние развернутых фич в песочнице на работу всего сервера.

Если Вы заинтересовались, какие права устанавливаются коду в песочнице, то можете обратиться к файлу wss_usercode.config, который находится в каталоге C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG (или похожем).

С точки зрения пользователя, функционал песочницы реализован с помощью Галереи Решений, которая доступна через настройки сайта:

clip_image002

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

Подобный подход позволяет хостеру не думать о функциональности, а продавать лишь доступ к SharePoint, создавая веб-приложения по определенному шаблону. Все расширения будет проводить сам владелец коллекции. Естественно, что такой подход удобен для работы с «продвинутыми» клиентами.

Written by Sergiy Baydachnyy

28.01.2010 at 18:51

Опубликовано в SharePoint

Tagged with

SharePoint 2010: Что нового? (часть 3) – Интеграция с VS2010

with one comment

В SharePoint 2010 достаточно большой акцент был сделан на повышение производительности разработчика. Ведь не секрет, что в предыдущей версии продукта, разработчик был лишен любых мастеров и дизайнеров, позволяющих создавать компоненты для SharePoint. Расширения, которые поставлялись для Visual Studio 2008, были настолько не практичны, что получили лишь негативные отзывы от разработчиков.

Между тем, Visual Studio 2010 содержит достаточно большое количество разнообразных шаблонов, позволяющих моделировать создавать процессы, веб-части, шаблоны сайтов и др. Поэтому, рассматривая процесс создания любого из компонентов, мы попытаемся использовать Visual Studio 2010. Но забывать о «низкоуровневой» структуре решения и механизмах развертывания без Visual Studio также не стоит.

Следует также отметить, что кроме отсутствия хороших утилит для разработчика, в SharePoint 2007 отсутствовала и хорошая документация. Большинство классов не имели описания вовсе, а количество технических статей было настолько маленьким, что разработчики тратили большое количество времени на создание простого решения. Была очень большая надежда на то, что с выходом SharePoint 2010 ситуация поменяется. Но, скачав SDK для версии бета 2, я убедился, что надежда была ложная. По-прежнему SDK содержит минимум полезной информации, а большинство новой функциональности не имеют описания вовсе.

Но хватит о грустном, перейдем к работе с SharePoint 2010 и Visual Studio 2010.

Первое, с чего хотелось бы начать, это поддержка SharePoint 2010 в окне Server Explorer.

clip_image002

В Server Explorer достаточно удобно можно просмотреть полную иерархию приложения, включая идентификаторы фич, поля списков и доступные рабочие процессы.

Следующая возможность, доступная из Visual Studio 2010, это большое количество шаблонов проектов для SharePoint 2010.

clip_image004

Тут присутствуют и веб-части, с инкапсулированным пользовательским элементом управления, что позволяет использовать визуальный дизайнер, и шаблоны сайтов, и шаблоны списков, и т. д. При этом, все шаблоны позволяют создать полноценное Решение в понятиях SharePoint.

Попробуем создать проект на основе Empty SharePoint Project шаблона. При этом обязательно обратите внимание на начальные параметры для развертывания проекта.

clip_image006

Тут есть возможность выполнить развертывание в «песочницу» или в стандартной конфигурации. Хочу обратить Ваше внимание на то, что по умолчанию выбрана песочница.

После создания нового проекта, добавим несколько веб-частей и посмотрим на структуру проекта.

clip_image008

Как видно, данный шаблон, как и положено решению для SharePoint, содержит манифест, в виде файла Package.Template.xml, а также спаренного с ним файла Package.package. Созданные фичи, имеют аналогичное описание в виде XML файла и спаренного файла с расширением features. Созданные веб-части, имеют в своей структуре Elements.xml, служащий инструкциями для заполнения фичи, с последующей ее упаковкой в пакет. Разделение же файлов описывающих фичи и решение, не случайно. Данный подход позволяет программисту редактировать XML файл, в то время как Visual Studio, вносит изменения в спаренный файл. Это позволит обезопасить от ошибок визуального дизайнера, да и разработчик может контролировать процесс. Иными словами, если посмотреть на текущую структуру проекта, то все на поверхности и поддается модификации, чего нельзя было сказать о предыдущей версии утилит.

Хочу отдельно отметить дизайнер, возникающий при попытке открыть файлы с расширением feature или package.

clip_image010

Этот дизайнер показался мне как достаточно простым, так и очень удобным.

Между тем, остается открытым вопрос развертывания решений. Я никогда не пользовался Visual Studio 2008, при создании SharePoint решений, в первую очередь потому, что не мог контролировать процесс развертывания. Теперь я не просто контролирую процесс развертывания и удаления решения, но и могу настроить любое количество конфигураций, тестируя различные механизмы развертывания. Для этого мне достаточно перейти в свойства проекта и войти в редактор конфигурации с вкладки SharePoint.

clip_image012

Напоследок хочется отметить, что Visual Studio 2010 позволяет отлаживать SharePoint решения, уже привычным для разработчика способом – устанавливая точки останова. Последнее делает разработку приложений для SharePoint детской забавой.

Таким образом, если говорить об утилитах для SharePoint 2010, встроенных в Visual Studio 2010, то, кажется, разработчики получили то, о чем так долго мечтали.

Written by Sergiy Baydachnyy

21.01.2010 at 08:04

Опубликовано в SharePoint

Tagged with

SharePoint 2010: Что нового? (часть 2) – Master-страницы или гвоздь в голову

4 комментария

В SharePoint 2010 произошли небольшие изменения, связанные с обработкой эталонных (master) страниц. Первое изменение коснулось страниц приложения (общих страниц для всех сайтов). Теперь страницы приложения подключают ту же эталонную страницу, что и контентные страницы самого сайта. Таким образом, интерфейс, позволяющий настраивать параметры сайта, списков и других элементов, будет выглядить в едином стиле со всем сайтом. При этом, чтобы гарантировать бесперебойную работу некоторых важных страниц приложения, было принято решение выделить несколько страниц в отдельную группу и сохранить старую модель использования эталонных страниц. Так, следующие страницы, используют simple.master, которая находится в общей директории со страницами приложения и не зависит от сайта:

· AccessDenied.aspx

· MngSiteAdmin.aspx

· People.aspx

· RecycleBin.aspx

· ReGhost.aspx

· ReqAcc.aspx

· Settings.aspx

· UserDisp.aspx

· ViewLsts.aspx

Если говорить о страницах сайта (контентных страницах), то теперь они используют новую эталонную страницу v4.master, которая находится в шаблоне Global (об этом позже).

На этом я закончу писать про интерфейсные изменения и перейду к разработке. Но описывая изменения, связанные с эталонными страницами, не могу не написать следующий абзац (или несколько).

Как говорит мой коллега, Виктор Шатохин: «Этим разработчикам нужно забить гвоздь в голову». Действительно, в документации говорится, что все страницы теперь имеют общую эталонную страницу v4.master. Но если Вы посмотрите на код страниц сайта, то обнаружите следующую запись:

MasterPageFile="~masterurl/default.master"

Если смотреть на код страниц приложения, то запись немного другая (но не на много лучше):

DynamicMasterPageFile="~masterurl/default.master"

Таким образом, v4.master обнаружить не удалось.

Оказывается, чтобы реализовать механизм для страниц приложений, в SharePoint 2010 используют атрибут DynamicMasterPageFile, который не задает реальный адрес эталонной страницы, а использует один из двух динамических шаблонов:

· "~masterurl/default.master"

· "~masterurl/custom.master"

В первом случае выбирается страница, которая используется конкретным сайтом для страниц сайта. Данную страницу можно получить через свойство MasterUrl объекта, связанного с веб-приложением (SPWeb). Во втором случае, страница выбирается из свойства CustomMasterUrl, связанного с объектом веб-приложения. Очевидно, это было сделано для того, чтобы иметь возможность установить альтернативную эталонную страницу, отличающуюся от эталона для контент страниц. Пожалуй это можно простить и догадаться о подмене по DynamicMasterPageFile атрибуту.

Теперь обратимся к страницам сайта. Тут установлен MasterPageFile атрибут, поэтому говорить о какой-то динамической подстановке v4.master сложно. Но при загрузке страницы используется именно v4.master. Оказывается, что страница переопределяется в конфигурационном файле шаблона onet.xml:

<Configuration ID="0" Name="Default" 
MasterUrl="_catalogs/masterpage/v4.master">

Естественно, что описанием изменений в onet.xml и не пахнет.

Таким образом, уже с первых строк, я столкнулся с ворохом проблем, после чего можно сделать вывод, что разработка под SharePoint проще не стала. Многие вещи нужно просто знать.

Written by Sergiy Baydachnyy

19.01.2010 at 13:36

Опубликовано в SharePoint

Tagged with

SharePoint 2010: Что нового? (часть 1) – Интерфейс

3 комментария

О чем пойдет речь?

При работе с SharePoint 2007 выделяли две версии продукта: Windows SharePoint Service 3.0 (WSS 3.0) и Microsoft Office SharePoint Server 2007 (MOSS 2007). Продукт WSS 3.0 являлся бесплатным и предоставлял фундамент для развертывания собственных решений. В свою очередь MOSS 2007 представлял собой настройку над WSS 3.0 с большим количеством расширений, дополнений и возможностью масштабироваться. Обычно разработчикам все равно, какой из двух продуктов используется, хотя, в сложных решениях, это принципиально.

В новой версии SharePoint произошла небольшая смена названий. Теперь бесплатная версия продукта носит название Microsoft SharePoint Foundation 2010, а платная – Microsoft SharePoint Server 2010.

Хочу сразу отметить, что мы будем вести речь только о Microsoft SharePoint Foundation 2010. Хотя все сказанное применимо и к старшему брату этого продукта. Для простоты мы будем говорить просто – SharePoint, подразумевая Microsoft SharePoint Foundation 2010.

Прежде чем переходить к отдельным темам, посвященным разработке решений для Microsoft SharePoint Foundation 2010, хотелось бы остановиться на тех нововедениях, которые реализованы в этом продукте и могут быть интересны разработчикам. Мы начнем с изменений в интерфейсе, а закончим описанием возможностей Visual Studio 2010 и SharePoint Designer.

Новый интерфейс

Лента

Начнем с первого, что, вероятнее всего, сразу бросится в глаза – Лента (Ribbon). Элемент управления Лента впервые появился в приложениях Microsoft Office 2007 и теперь перекочевал и в SharePoint. Фактически везде, где требуется меню, управляющее контентом (как сайта, так и списками), возникает Лента.

clip_image002

Для разработчика наличие ленты означает, что разработчику необходимо изучить механизмы настройки Ленты и подключения новой функциональности.

Изменения в CSS

В SharePoint 2010 изменения коснулись core.css. Теперь это не один файл, а целый набор файлов, разбивающих старый мега-стиль на несколько стилей, сгрупированных по назначению. Кроме того, в стандартный набор предопределенных списков входит список под названием Style Library. Даный список (библиотека) может быть использован разработчиком для размещения картинок, стилей и других элементов, связанных с оформлением сайта, полагаясь на то, что список всегда присутствует.

Диалоговые окна

Еще одно нововшество интерфейса SharePoint, это большое количество всевозможных всплывающих диалоговых окон. Как и лента, они выполнены в стиле Web 2.0 и используют технологию AJAX. Обычно они появляются при создании или редактировании элемента списка, сайта и др. При этом диалоговые окна выглядят весьма симпатично и могут быть любой сложности. Ниже окно, появляющееся при попытке создать новый сайт в коллекции.

clip_image004

Естественно, разработчик имеет возможность разрабатывать собственные диалоговые окна.

Редактирование содержимого

Как видно, при создании новой версии SharePoint, основной упор был сделан на удобство работы пользователя с интерфейсом. Особо нужно отметить переработанную функциональность, связанную с редактированием текста и добавлением изображений в редактируемый текст.

clip_image006

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

Поддержка разных браузеров

Несмотря на довольно привлекательный интерфейс, выполненный в стиле Web 2.0 с использованием AJAX, SharePoint 2010 поддерживается сразу тремя браузерами. Так Microsoft гарантирует поддержку для Internet Explorer, FireFox и Safari браузеров. Пока ничего не сказано о Google Chrome, но с ним тоже не должно быть проблем. А вот Opera традиционно не поддерживается. Последняя, несмотря на свою скорость, имеет множество проблем с логикой работы того же JavaScript и с обеспечением безопасности (отсюда и скорость).

Работа с группой элементов

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

clip_image007

Соответственно, как разработчик, Вы должны предусмотреть возможность работы с группами.

Локализация интерфейса

Еще одна возможность, удобная для пользователей, работающих в интернациональных компаниях, это локализация интерфейса управления порталами в зависимости от языковых предпочтений. Так, предыдущая версия SharePoint поддерживала только один язык для управления порталом (например, английский). Теперь, после установки языковых пакетов, пользователю будет отображаться тот язык, который установлен в его локальных настройках. Следовательно пользователей, работающий в США, получает англоязычный интерфейс управления, а пользователь, работающий в Украине – русскоязычный или украиноязычный интерфейсы.

XSLT веб-часть

Еще одно нововведение, которое я хотел бы рассмотреть, это поддержка двух специальных XSLT веб-частей, способных отображать данные из списков, используя XSL преобразования. Данные веб-части не присутствуют в списке по умолчанию, но могут быть легко туда добавлены. Первая из двух веб-частей, позволяет применять XSL преобразования при отображении всех данных из списка, а вторая – при отображении отдельного элемента. О том, как использовать эти веб-части и каке существуют еще, мы будем говорить в других разделах.

Written by Sergiy Baydachnyy

19.01.2010 at 13:32

Опубликовано в SharePoint

Tagged with

Введение в SilverLight 4: Повышение доверия

4 комментария

Как страшно жить! При создании SilverLight 2 и 3, в Microsoft задумывались о том, чтобы реализовать возможность размещения приложений в различных группах безопасности кода (подобие Code Access security). Данный подход не только не был реализован, но и принадлежность всех SilverLight-приложений к единому контексту безопасности (Web «песочнице») позиционировалось как преимущество технологии. Ведь если в данном контексте нет прав, например, на форматирование жесткого диска, то даже при наличии ошибок в приложении разработчика, возможность для атаки будет отсутствовать.

В SilverLight 4 ситуация координально изменилась. Теперь приложениям, устанавливаемым для работы вне браузера, можно назначать контекст безопасности с повышенными правами. Чтобы сделать это, достаточно немного изменить конфигурационный файл, установиви атрибут ElevatedPermissions в значение Required:

<OutOfBrowserSettings.SecuritySettings>
   <SecuritySettings ElevatedPermissions="Required" />
</OutOfBrowserSettings.SecuritySettings>

При инсталяции такого приложения пользователь получает вот такое окно:

image

Несмотря на то, что вид окна отличается от того, который используется для инсталяции обычных приложений, работающих вне браузера, нужно помнить, что приложения разрабатываются для обычных пользователей. Я встречал громадное количество пользователей, которые смело жмут кнопку Install, не читая предупреждений (или игнорируя их). Поэтому данная возможность безопасна скорее для корпоративных пользователей, где у администратора есть возможность запретить установку всех приложений, требующих повышенный полномочий. При этом, перед установкой запрета, можно установить все необходимые приложения, которые после установки запрета будут работать и дальше.

Если говорить о пользователях Интернет, то давайте рассмотрим, какими правами обладают приложения с повышенным доверием.

Расширенные возможности работы в полноэкранном режиме

В стандартных SilverLight-приложениях нельзя перейти в полноэкранный режим без реакции на событие, инициированное пользователем. Кроме того, в полноэкранном режиме действуют ограничения, связанные с клавиатурой (невозможен ввод).

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

Отсутствие сообщений о доступе к ресурсам

При работе с буфером обмена и другими внешними ресурсами (камера, микрофон), пользователь не будет получать сообщения, позволяющие разрешить или запретить доступ. При этом, такие классы как Clipboard, можно использовать в любом месте кода.

Запросы между доменами

Следующая возможность, доступная для приложений с повышенным доверием, это отправка запросов службам и приложениям, находящимся в любом домене. При этом не важно, какую конфигурацию имеет удаленным домен. Данная функциональность безвредна для пользователя, но незаменимая при организации DOS-атакJ

Доступ к некоторым папкам

В режиме с повышенным доверием, приложение получает полный контроль к некоторым специальным папкам, ассоциированными с пользователем: MyDocuments, MyVideos, MyPictures, MyMusic. Пути к указанным папкам можно получить, используя статический класс Environment. При этом нужно отметить, что SilverLight-приложение работает только с папками, но не с библиотеками (Win 7).

Данная возможность хоть и ограничена, но одна из самых опасных. Я не вижу никаких ограничений, запрещающих мне записать исполняемый файл в одну из этих папок, а затем запустить его. Если при этом пользователь имеет выключенным нотификации UAC (Windows 7), то права такого приложения будут неограниченные.

Взаимодействие с COM

И, наконец, самая интересная возможность – доступ к COM API.

С одной стороны это означает, что теперь разработчик может получить доступ к COM-модели таких продуктов как Word и Excel. Это позволит создавать документы «на лету» и заполнять их данными, выбранными пользователем из внешних хранилищ.

С другой стороны, пользователь обычно имеет достаточно большой спектр COM-объектов, установленных по умолчанию. Например, WScript, позволяющий запускать приложения из любой директории на вашей машине (даже те, которые Вы можете скопировать, используя предыдущую возможностьJ):

dynamic cmd = ComAutomationFactory.CreateObject("WScript.Shell");
cmd.Run(string.Format(writerApp, @ArgumentFileBox.Text),1, true);

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

В завершении темы хочу отметить, что объект Application имеет специальное свойство HasElevatedPermissions, которое позволяет проверить, запущено ли это приложение с повышенным доверием. Свойство имеет смысл, если Вы будете делать инсталяции сразу двух типов приложений, работающих вне браузера (с повышенным доверием и стандартное).

Written by Sergiy Baydachnyy

15.01.2010 at 13:11

Опубликовано в SilverLight

Tagged with