Есть ли польза от использования SecureString в ASP.NET?

Question

Если я правильно понимаю, это для хранения простого текста вне памяти, чтобы приложение было защищено от эзотерических атак на память, кучу мусора или память, выгруженную на диск.SecureString получает неуправляемые байты и одновременно использует один неуправляемый байт - затем строка стирается из памяти.(Поправьте меня, если я ухожу!)

В ASP.NET секрет собирается в веб-форме, которая отправляется обратно в HTTPS.Но затем объект Request превращает все значения запроса из формы в пары имя-значение и помещает их в коллекцию, например, Request ["TxtPassword"] - так что даже прежде чем я смогу получить строку, она уже небезопасно записана в память.Хуже того, если бы я использовал элемент управления, то незащищенное представление будет иметь больше управляемых строк в свойстве TextBox.

Чтобы сделать что-нибудь с этой SecureString, мне нужен API, который принимает неуправляемые строки - так что кажетсяЯ не могу использовать защищенную строку для хранимого параметра proc или чего-то еще.

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

Переключение на OAuth или аутентификацию Windows не вариант.

Answer 1

Как вы правильно поняли, и другие уже упоминали, нет смысла использовать SecureString для хранения конфиденциальных данных, которые поступают из формы ASP.NET, потому что эти данные уже присутствуют в памяти вобычный текст.

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

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

char secret[512];
generate_secret(secret, sizeof(secret));
do_something_with(secret);
memset(secret, 0, sizeof(secret));
// Secret data is now gone.

Однако такой подход невозможен для управляемых строк, главным образом потому, что:

• Они не размещены в стеке,
• Они неизменны, поэтому их невозможно очистить,
• Они не подлежат утилизации, поэтому нет гарантии относительно времени, когдаGC освободит данные.Это может даже никогда не быть освобождено, в зависимости от условий памяти.

SecureString пытается решить эту проблему, будучи изменяемым и одноразовым, что позволяет написать:

using (SecureString secret = new SecureString()) {
    GenerateSecret(secret);
    secret.MakeReadOnly();
    DoSomethingWith(secret);
}
// Secret data is now gone.

Answer 2

SecureString лучше всего использовать для распределения сетевых учетных данных для прямых вызовов между системами. На веб-арене принято считать, что если учетные данные пришли через Интернет, то они где-то в виде открытого текста, но если вам нужно отправить эти учетные данные обратно через стандартный вызов учетных данных (ftp, службы каталогов и т. Д.), То использование SecureString не больно, как попутный метод. Хотя вы правы в том, что эта строка уже есть в вашей серверной системе в виде простого текста, вы можете по крайней мере уменьшить зону обслуживания между системами. Если вы используете этот пароль только локально, то я бы согласился, что SecureString, вероятно, не очень необходим.

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

Answer 3

Я думаю, у вас есть основы этого. SecureString разработан с точки зрения нахождения на стороне клиента. Так что для приложения WPF / Winforms (и, возможно, Silverlight, не могу вспомнить, если оно там есть), оно стоит тонны, в то время как для приложения на стороне сервера, не так много, потому что он не первый, кто обрабатывает строку.

Answer 4

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

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

Другой альтернативой является использование API защиты данных Windows. если возможно.

Обратите внимание, что целью SecureString является сохранение содержимого в памяти как можно более короткое время.

Answer 5

Если я не ошибаюсь, вы можете использовать следующее решение, чтобы не вводить данные в управление строками CLR: Веб-API: как получить доступ к многочастным формам при использовании MultipartMemoryStreamProvider?

Только чтение FormData в методе ExecutePostProcessingAsync (..) как ReadAsByteArrayAsync (), и оно никогда не должно становиться строкой в ​​пути.

Вам по-прежнему нужен https для обеспечения безопасности входа в пути.