Защита VB.Net для публичного выпуска с шифрованием и, возможно, ASP.Net API / WebServices

Question

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

В настоящее время я завершаю работу над несколькими последними частями приложения Windows Desktop VB.Net.

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

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

Моя первоначальная теория была:

• Шифрование строки SQL в файле app.config

• Безопасное шифрование имен хранимых процедур в коде

• Обфусцировать / зашифровать код, чтобы он был легко перемешан и не читался

• Настройте пользователя SQL, который ТОЛЬКО имеет разрешение на выполнение именованных хранимых процедур, и удалите любые другие разрешения (даже не можете видеть таблицы / системные таблицы и т. Д.), Чтобы пользователь должен был знать имя процедуры и сами параметры.

Мое главное беспокойство и большой страх с этой конкретной установкой - это то, что она все еще довольно легко взломана. Итак, я думаю, первый вопрос ...

Вариант 1: (наименее безопасный) Насколько вероятно взломанное выше и какие шаги я пропускаю? Как легко пользователь может декомпилировать приложение, тщательно просеивая зашифрованный / зашифрованный код, извлекать зашифрованные имена процедур и строку подключения SQL, использовать IP для соединения через SSMS с именем пользователя и паролем и сидеть там, угадывая входные параметры имен пользователей до тех пор, пока не появятся хешированные и засоленные пароли?

Есть ли лучший способ сделать что-то выше или я пропустил шаг выше, который значительно повысил бы безопасность, если бы я пошел по этому пути? Я читал об отдельных учетных записях SQL для каждого пользователя, но не уверен, что это дает преимущества безопасности?

Вариант 2: (наиболее безопасный) Как веб-API или WebService помогают или работают в моем сценарии? Так что это вариант, который, конечно, будет использоваться в качестве пути, и я не против, но я серьезный новичок, когда дело доходит до ASP.Net и его сервисов. Поэтому я предполагаю, что мой главный вопрос заключается в том, есть ли где-нибудь руководство или хотя бы пример чего-либо, на что я могу взглянуть, или даже помощь, которую кто-то может предоставить, или даже платная тренировка, которая покажет мне, как я могу создать такую ​​вещь?

Кроме того, если API / WebService может обслуживать данные в формате JSON, например, как WebService может принимать данные в качестве запроса для вставки в базу данных? Я даже не уверен, возможно ли это с API / WebService, так как я думал, что эта настройка сделает передачу данных в один конец.

И если API / WebService размещен в Интернете, а URL-адрес для его получения встроен в приложение, как это будет более безопасным? Может ли конечный пользователь не просто захватить URL-адрес и затем отправить свои собственные запросы на данные с прекрасным графическим интерфейсом, чтобы помочь им?

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

Answer 1

Хорошо, давайте сначала рассмотрим параметры:

Опция 1

Во-первых, app.config не является безопасным, если строка подключения находится в чистом тексте.Вы можете зашифровать часть файла конфигурации, что может повысить безопасность.Далее идет декомпиляция кода.Это то, что вы вообще не можете делать.Независимо от того, какой уровень запутанности вы добавляете в свой код или насколько вы его минимизируете, он всегда будет декомпилируемым.В конце концов, ваш компьютер должен прочитать код, верно?Так что да, запутывание может повысить безопасность исходного кода вашего приложения.Однако это не гарантирует 100% безопасности.

И не уверен, насколько вы опытны с базами данных, но, как вы сказали, у вас есть конечный пользователь SQL-сервера, который может выполнять только определенные хранимые процедуры, тогда почему вы беспокоитесь о том, что кто-то получит доступ к вашим паролям??

И это также заставляет меня задуматься, почему вы беспокоитесь о хешированных + соленых паролях.Если ваше приложение не генерирует миллиарды долларов и вы не управляете рынком, таким как Google или Facebook, дайте мне причину, почему я взломал бы вашу систему?Просто чтобы посмотреть, какой скин вы применили к SSMS?

Вариант 2

Теперь мы говорим!Итак, если мы хотим поговорить о Web API , давайте сначала забудем о безопасности.

Допустим, пользователь, используя ваше приложение для настольного компьютера, пытается вставить его / ееданные в базу данных напрямую, без каких-либо веб-API.Предположим, когда он нажимает « Register » или что-то подобное, интернет-соединение пользователя падает.Вы знаете, что будет дальше?Пользователь открыл соединение с вашей базой данных, пытается вставить некоторые данные, но прежде чем база данных действительно сможет получить все данные, которые нужно вставить, приложение теряет соединение, ваш запрос SQL либо неполный, либо становится странным, этот запрос выполняетсяи БУМ! Вся таблица повреждена!Ну, иногда случается еще хуже, но, эй, позвольте мне больше не пугать вас.

A Web API избавит вас от этого.Я не буду вдаваться в подробности, но самая простая логика такова:

Либо вы вызываете API должным образом, и API выполняет вызовы из базы данных, либо вы не делаете правильный вызов, а API не 'Продолжить вызов базы данных.

API также дает вам больший контроль над тем, что на самом деле кто-то может получить от ваших серверов.У вас также есть огромное преимущество, когда речь заходит о масштабируемости.Поскольку вы вносите столько же обновлений в свой веб-API и базу данных, ничего не делая с приложением конечного пользователя, снижая потребности пользователя в загрузке каждого обновления.

Теперь давайте проясним одну вещь.Веб-сервис и веб-API - это две разные вещи (хотя и тесно связанные).В любом случае, запрос, который вам нужно сделать, чтобы получить данные из веб-API, называется GET запросом.Когда вы хотите вставить данные, вам нужно сделать запрос POST.Чтобы удалить, вам нужно сделать запрос Delete, чтобы обновить, вы можете выбрать PUT или PATCH.

. Как вы обрабатываете данные по каждому запросу, это совершенно другая тема.Вы можете Google для этого.Но я сделаю это легко для вас.Пойдите с этим: Учебник по Asp.Net Core 2.0 Web API .

Кроме того, обязательно включите " RESTful " в ваш поискзапросы.

В любом случае, лучший вариант для вас - это комбинация Опция 1 & Опция 2 .

1. Вы можете зашифровать части строки подключения
2. Запутать код
3. Создать RESTful Web API
4. Создать пользователей уровня сервера SQL с ограниченными разрешениями.
5. Обеспечение безопасности вашего сервера (это совсем другая тема)
6. Мониторинг входящих / исходящих вызовов с помощью соответствующих инструментов и установка границ.

Полагаю, это все, что вы можете сделать сейчас. Но если у вас есть много ресурсов, таких как, скажем, миллиарды долларов, таких как Google или Facebook, вы можете добавить больше к своей безопасности!

Приветствие.