Valeriy1991
@Valeriy1991
Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow

Как защитить ASP.NET MVC приложение от администратора?

Добрый день, уважаемые коллеги!

Есть корпоративное (можно сказать, "интранет") ASP.NET MVC приложение. Данные хранятся в локальной БД на Firebird. Это приложение поставляется "в массы". Есть системные администраторы, которые разворачивают это приложение на своих серверах (т.е. развертывание выполняется нецентрализованно). В MVC-приложении вся логика, как известно, находится в *.dll. Но Views открыта для просмотра и редактирования, и при желании, какой-нибудь "ушлый" администратор может либо поломать что-либо во View, либо написать какой-нибудь JS-код (или изменить существующий), который будет работать "в обход" основной логики приложения (изменить поведение каких-либо кнопок, например).

Вопрос следующий: каким образом можно защитить всё приложение таким образом, чтобы "ушлые" пользователи не могли изменить логику работы приложения или его составных частей (Views, JS-кода)?

Возможные варианты:
  1. можно обфусцировать всё, что можно, но как тогда это сделать так, чтобы и Views рендерились нормально, и JS-код успешно выполнялся?
  2. можно шифровать всё содержимое Views и JS-кода, но ключ где тогда хранить? (ключ, впринципе, можно хранить и в локальной БД - особо страшного тут ничего не будет, т.к. логика по шифрованию/дешифрованию будет "зашита" в *.dll, которые, насколько я понимаю, достаточно трудно декомпилировать - или я ошибаюсь?)


Примечание: в локальной БД на Firebird данные хранятся в открытом виде, и по сути, ничего не мешает их оттуда считывать. В принципе, это не особо страшно, что эти данные могут увидеть сисадмины - главное, чтобы нельзя было "прочитать" и изменить логику работы и поведения всего приложения.
  • Вопрос задан
  • 1196 просмотров
Решения вопроса 1
Valeriy1991
@Valeriy1991 Автор вопроса
Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
Коллеги, в принципе, можно отнести это к решению вопроса - в Visual Studio при публикации ASP.NET приложения в настройках Publish'а есть такая опция - "Precompile during publish". При конфигурировании этой опции снимается галочка с "Allow precompiled site to be updatable" + можно поиграться с блоком "Merge option". Эта галочка способствует тому, что все View при публикации будут преобразованы в *.dll файлы, а блок "Merge option", насколько я понял, позволяет настроить различные способы этого преобразования View -> dll. Решение пока отмечать не буду - хотелось бы услышать еще варианты и "поиграться" с этими настройками публикации.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 4
MaxDukov
@MaxDukov
впишусь в проект как SRE/DevOps.
ИМХО пока и данные и приложение находятся у пользователя - никак.
только забрать данные и бизнесс-логику в контроллируемое пространство, пользователю отдать только интерфейс
Ответ написан
Комментировать
@Fredcapit
А может сервер всё-таки иметь один? Зачем куча экземпляров?
Ответ написан
@dmitryKovalskiy
программист средней руки
Можно анально огородить Базу. Доступ только до уровня хранимок, гранты на хранимки выдаются только вами при инициации базы.
Ответ написан
Комментировать
dmitry_pavlov
@dmitry_pavlov
World-class .NET freelance contractor (remotely)
Всю логику с клиента убрать - пусть будут старые добрые постбеки. Все делать на сервере, усиленную валидацию в том числе. Серверные сборки обфусцировать при билде. Если совсем хочется хардкорно и UI не слишком сложный - можно его рендерить тоже на сервере.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы