Silverlight. Вопросы безопасности

Question

Скажите, пожалуйста, бизнес-приложения Silverlight безопасны?

Насколько я знаю, пользователь может получить .xap файл из кэша локального компьютера, которое загрузило приложение, или напрямую, если известно имя и местоположение файла (оно написано в HTML-коде) - просто введите его в адресной строке браузера и файла будут загружены. (Вопрос 1:? Это нормально Или, может быть, некоторые настройки конкретного хостинг может отказать напрямую загружать)

Существует самое интересное - так, пользователь, после загрузки веб-страницы, имеет .xap файл в файловой системе. Теперь Вопрос 2: Может ли пользователь открыть (я имею в виду, декомпилировать) этот файл xap и, таким образом, получить много данных, в том числе проверить определенную роль пользователя и т. Д.? В коде я периодически проверяю наличие уполномоченного пользователя в определенной роли. В зависимости от этого, он может быть предоставлен различным контентом.p.s. конечно, я знаю о роли проверки на стороне сервера по атрибутам, речь не об этом. Плюс, я использую модульность MEF, и для связи между модулями я использовал глобальный проект библиотеки с коммуникационным интерфейсом. Можно ли украсть информацию между модулями?

Дальше. Файл web.config, в котором содержатся некоторые параметры приложения, также содержит строку подключения к базе данных с информацией о пароле. Существует Вопрос 3: web.config, достаточно безопасный для хранения таких данных?

И последний вопрос - соединение SSL. Я знаю, мне нужно заплатить за это. В любом случае, Вопрос 4: Как SSL он может защитить приложение и содержать данные (в бизнес-приложении)?

Answer 1

Вопрос 1. Файл xap должен быть доступен конечному пользователю, поэтому я не думаю, что вы можете остановить аутентифицированного пользователя от его получения с сервера. И даже если он недоступен, пользователь может найти его в кеше браузера.

Вопрос 2a. Да, пользователь может декомпилировать xap. Это всего лишь zip-файл. Переименуйте zip, извлеките содержимое, просмотрите Reflector и т. Д. У вас есть игра с Silverlight Spy, и вы также можете увидеть интересные вещи. Вы можете использовать инструмент обфускации на своих сборках, что является полезным сдерживающим фактором, но даже это может быть декомпилировано кем-то с достаточными ресурсами/энергией.

Вопрос 2b. Я думаю, что можно было бы увидеть «информацию, проходящую между модулями», поскольку приложение Silverlight можно отлаживать с помощью WinDbg. Опять же, обфускация, по крайней мере, поможет сдержать случайную интроспекцию.

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

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

На основании вопросов, которые вы задали, вот вам риск, который вы должны смягчить. Представьте, что пользователь подключается к вашему SL-приложению, входит в систему, а затем вы получаете свои «роли» с сервера.Если они декомпилировали ваш xap и выяснили, что они должны быть в роли «admin», чтобы открыть доступ ко всему, они могли бы установить прокси-сервер между SL-приложением и вашим сервером и модифицировать ответы, чтобы приложение SL думает, что они находятся в роли «администратора». Это человек в средней атаке, когда конечный пользователь пытается взломать систему. Даже если вы используете SSL, это возможно, потому что прокси-сервер будет использовать свой собственный сертификат, а конечный пользователь может добавить сертификат прокси в хранилище доверенных сертификатов.

Я никогда не мог правильно решить вышеуказанный риск на стороне клиента. Я затруднил хакер, используя обфускацию, и добавив настраиваемый заголовок к запросам/ответам, который был фактически контрольной суммой со скрытым закрытым ключом для шифрования контрольной суммы. Однако, если конечным пользователям удалось де-обфускать/декомпилировать xap, они теоретически смогут найти закрытый ключ и увидеть мой алгоритм шифрования и, следовательно, смогут заменить его в новой контрольной сумме после изменения «роли» в приведенном выше пример.

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

Например, если пользователь должен быть в роли «admin» для просмотра «клиентов», тогда я покажу экран клиента на клиенте, если пользователь находится в «admin», роль. Тем не менее, на сервере, когда клиент SL вызывает службу для извлечения данных «клиентов», я также проверяю, что у текущего пользователя, прошедшего проверку подлинности, есть разрешение на просмотр данных (в отличие от экрана).