Как можно предотвратить появление паролей и другой конфиденциальной информации в дампе ASP.NET? - PullRequest
26 голосов
/ 01 апреля 2012

Как предотвратить пароли и другие конфиденциальные данные, передаваемые и получаемые с веб-страниц ASP.NET в файлах дампа IIS / ASP.NET?

Шаги для воспроизведения

  1. Используя Visual Studio 2010, создайте приложение для интрасети ASP.NET MVC 3.
  2. Настройте его для использования IIS 7.5.
  3. Запустите его и зарегистрируйте учетную запись (например, bob123 в качестве пользователя и Pa ​​$$ w0Rd в качестве пароля. Я предполагаю, что база данных SQL Express создана и сайт полностью функционален.
  4. Используя диспетчер задач, щелкните правой кнопкой мыши по процессу w3wp и создайте дамп.
  5. Откройте дамп в редакторе, способном отображать его содержимое в шестнадцатеричном виде, например, SlickEdit.
  6. Найдите "Pa $$ 0Rd" и "Pa% 24% 24w0Rd" в шестнадцатеричном дампе. Вы должны быть в состоянии найти несколько его копий, сохраненных как ASCII, Unicode или закодированные.

Обратите внимание, что не имеет значения, используете ли вы HTTPS, потому что он только шифрует связь. ASP.NET хранит эти данные в открытом виде в памяти или на диске.

Проблема

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

Это подвергает их риску просто потому, что они имеют к нему доступ. Иногда дампы делятся с партнерами (такими как Microsoft), чтобы помочь им диагностировать проблемы в своем коде. Это необходимая часть диагностики действительно сложных проблем в приложении.

Вещи, на которые я смотрел

  1. Используйте SecureString для паролей и других конфиденциальных данных. Однако поставщик членства ASP.NET, наряду с другими платформами, такими как WCF, часто принимает пароли как System.String, что означает, что эти копии все еще будут в дампе.
  2. Посмотрел, есть ли в каркасе что-нибудь, чтобы очистить копию System.String, когда она больше не используется. Я ничего не смог найти.
  3. Исследовано, можно ли обнулить память, используемую для запросов и ответов, как только IIS будет работать с ним, но я не смог ничего найти.
  4. Я исследовал, можно ли зашифровать файлы, которые получает IIS (как HttpPostFile), чтобы они не сохранялись в открытом виде. Мы можем получать документы, которые являются чрезвычайно конфиденциальными, и каждый шаг делается для их шифрования и защиты на сервере. Однако кто-то может извлечь их в открытом виде из дампа IIS.

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

Ответы [ 2 ]

1 голос
/ 06 апреля 2012

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

Не могли бы вы передать свои базы данных / параметры конфигурации третьей стороне? если нет, то, вероятно, вам также не следует передавать файлы дампа. (Имхо)

0 голосов
/ 03 апреля 2012

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

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

На стороне файла, как эти файлы загружаются? прямо с веб-страницы? Существует довольно много библиотек JavaScript, которые выполняют шифрование (blowfish), и я бы определенно использовал эту опцию при отправке конфиденциального файла. У него есть ограничение скорости, но вы можете быть уверены, что данные в безопасности.

...