Существуют ли более безопасные альтернативы классу .Net SQLConnection? - PullRequest
6 голосов
/ 08 апреля 2010

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

В этой статье рассказывается, как использовать windbg для вывода в память запущенных строк процесса .Net.

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

Проблема возникает, когда вы используете его значение и присваиваете его свойству SQLConnection.ConnectionString, которое имеет тип System.String.Что это значит?Ну ...

  • Он хранится в виде обычного текста
  • Сборщик мусора перемещает его, оставляя копии в памяти
  • Его можно прочитать с памятью windbgdumps

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

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

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

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

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

Ответы [ 4 ]

10 голосов
/ 08 апреля 2010

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

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

4 голосов
/ 08 апреля 2010

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

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

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

2 голосов
/ 08 апреля 2010

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

1 голос
/ 08 апреля 2010

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

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

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

...