Там более безопасные альтернативы к классу.Net SQLConnection?

Я очень удивлен, что этот вопрос не был обсужден всесторонний:

Эта статья говорит нам, как использовать windbg для дампа рабочего процесса .NET строки в памяти.

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

Проблема входит, когда Вы используете ее значение и присваиваете его SQLConnection. Свойство ConnectionString, которое имеет Систему. Строковый тип. Что это означает? Хорошо...

  • Это хранится в простом тексте
  • Сборка "мусора" перемещает его, оставляя копии в памяти
  • Это может быть считано с windbg дампами памяти

Это полностью инвертирует функциональность SecureString!

Вдобавок ко всему, класс SQLConnection является ненаследуемым, я не могу даже прокрутить свое собственное со свойством SecureString вместо этого; Yay для закрытого исходного кода. Yay.

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

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

Как я могу защитить строку подключения в памяти, таким образом, она не может быть просмотрена с windbg?

6
задан Stan Shaw 20 October 2016 в 15:50
поделиться

4 ответа

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

Нет защиты от хакера, владеющего памятью вашего процесса. :)

10
ответ дан 8 December 2019 в 13:45
поделиться

Не настоящий ответ на вопрос, но все же:

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

Еще одно преимущество аутентификации Windows состоит в том, что серверу sql не нужно хранить хэши паролей пользователей. С помощью проверки подлинности sql хакер может подобрать пароль из хэша или заменить его другим. На самом деле пароль можно очень легко сменить с использованием некоторых программ.

4
ответ дан 8 December 2019 в 13:45
поделиться

Обмен данными между процессом и сервером Sql в идеале происходит на магистрали, и если это будет скомпрометировано, то это меньшая из ваших проблем.

2
ответ дан 8 December 2019 в 13:45
поделиться

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

Если вы подключаетесь к своему sql server с учетными данными администратора, это ваша проблема. Вы должны создать пользователя с ограничениями и использовать его в своем приложении.

Если вы боитесь раскрыть свою базу данных, вы можете получить доступ к веб-сервису из приложения. Затем этот веб-сервис получит доступ к базе данных и вернет результаты.

1
ответ дан 8 December 2019 в 13:45
поделиться
Другие вопросы по тегам:

Похожие вопросы: