Comments 46
Вероятно имелось в виде «декомпилировать его не представляется возможным»
Забавно, давно у Рихтера кажись было написано пару строк по поводу секурности дот нет не на серверах. Так вот секурности предполагалась за счёт недопущения получения сборок. То есть если ты влез на сервер но уже ничего не поможет. В связи с этим вопрос, строгие имена не гарантируют безопасность в случае со статьей. Мне на ум приходит только компиляция приложения в нативный код на клиентской машине и уже в таком виде проверять целостность и ТД. Какие ещё есть способы защиты?
В связи с этим вопрос, строгие имена не гарантируют безопасность в случае со статьей.
Если это вопрос — то нет, не гарантируют, если ваша цель именно сломать приложение. Просто цепочка слегка удлиняется — потребуется перелопатить все сборки через dnSpy.
Способы защиты, если уж мы считаем нормой лезть за активацией в сеть — просто чуть разумнее, чем в этом примере. Например идёте с ключём в сервис активации, он вам возвращает пароль к локальной базе. Непонятно зачем это делать напрямую конектом к базе, причем с такими роскошными правами. Если уж не хотелось заводить какой-то отдельный сервис — можно было права учётке ограничить на какую-нибудь хранимку которая вернула бы нужны данные.
Мне кажется тут плохая защита удаленной БД.
Во-первых не было смысла давать прямой доступ к БД, проще было разместить простое веб-приложение.
Во-вторых можно было ограничить права пользователя, только на одну конкретную операцию, а именно на проверку наличия ключа. К этому так же ограничит кол-во запросов в секунду.
Хотя о чем тут можно говорить, если весь тест расположен в локальной базе.
Эх… Наберут по объявлению…
Именно. Можно было просто найти в коде вызовы к базе и выдернуть оттуда данные для подключения.
Обфускация обсускацией, а язык-то не меняется.
Даже если подключаться к удалённой базе по логину/паролю, выдаваемому конкретному пользователю с адово-параноидально настроенными правами доступа… То всё равно будут дыры типа чтения чужих данных и тому подобное.
Так что ответ — никак. Делать поверх базы api и отдавать только его.
Использовать прямой коннект к базе из клиентского приложения можно разве что в доверенной среде. Например, в рамках локальной сети организации, когда авторизация в базе делается по AD-учётке текущего пользователя.
Вообще, по хорошему, база должна быть доступна только под 127.0.0.1 (по дефолту так и есть), либо внутри сети приложения (если мы говорим про масштабирование), т.к. в СУБД тоже могут быть 0-day уязвимости.
А уже на сервере запросы к БД можно делать как угодно: ORM, голый SQL, да хоть через handlersocket…
Во-вторых, в современных веб-приложениях повсеместно отделяют фронтенд и бэкенд. И общаются они между собой по API-интерфейсу.
Шифрование строк подключения производится ключом пользователя ОС. Если перенести этот файл на другой компьютер, расшифровать его приложение уже не сможет. Это защита только от удалённого доступа к файлам на серверах, локальный админ может расшифровать конфиги так же, как и зашифровал.
Если ну никак нельзя сделать АПИ, то можно просто плотить view по мастер таблице с аккаунтами и давать каждому клиенту доступ к view. Но далее — надо правильно настроить сервер, чтобы клиент не запускал n-n-n-n… запросы, отъедая по 100% от ядер.
А что бы ты делал, если данные в БД были зашифрованы, а ключ к расшифровке находится, где-нибудь на сервере(да, странно, но все все-таки)
Для Хабра можно было и постараться.
Да помню эти старые добрые времена
Декомпилировал сборку в dotPeek, разобрал логику, нашёл нужный переход. Нашёл соответствующее место в IL-коде. Однако, по какому смещению находится в файле нужный байтик, ни один инструмент, кроме IDA, мне не подсказал.
Как мне удалось взломать приложение