Нужно ли защищать строку подключения в web.config?

Ответ 1

Я бы не сказал, что сохранение пароля незашифрованного текста в Web.config является уязвимостью безопасности сама по себе. Но шифрование пароля - полезная защита в глубину, а не просто безопасность через неясность:

• Что делать, если IIS неправильно сконфигурирован для обслуживания Web.config?
• Что делать, если уязвимость безопасности обнаружена в ASP.NET(например, пропуская уязвимость оракула), которая позволяет любому пользователю загружать Web.config?
• Существует различная степень доступа к веб-серверу, от полных административных привилегий до ввода кода на стороне сервера. Если злоумышленнику удастся это сделать, он сможет читать Web.config, но не сможет получить доступ к машинным клавишам, особенно если ваше приложение работает под частным доверием.

В конце концов, вам решать, приемлемо ли риск хранения паролей открытого текста в Web.config. Конечно, если проверка подлинности Windows является опцией, тогда вы можете захотеть использовать это вместо проверки подлинности SQL.

ОБНОВЛЕНИЕ:. Говоря о безопасности, полезно идентифицировать активы и угрозы. В этом случае актив является конфиденциальными данными в базе данных (если данные несущественны, то зачем беспокоиться о защите его паролем?), А угроза - это возможность того, что злоумышленник каким-то образом получит доступ к Web.config и, следовательно, к базе данных также. Возможным смягчением является шифрование пароля базы данных в Web.config.

Насколько это опасно? Неужели мы действительно планируем такое астрономическое явление?

Это смягчение уже доказало свою ценность один раз: когда была обнаружена уязвимость оракула ASP.NET. Любой, кто хранил пароль открытого текста в Web.config, подвергался риску; любой, кто зашифровал пароль, не был. Насколько вы уверены, что другая аналогичная уязвимость в ASP.NET не будет обнаружена в ближайшие несколько лет?

Должны ли мы также шифровать исходный код и расшифровывать его во время выполнения? Мне кажется чрезмерным.

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

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

Как насчет уязвимостей безопасности в ASP.NET или вашего кода? Время от времени они появляются.

Меня беспокоит стандартная практика. Является ли это стандартом?

Microsoft рекомендовал шифрование строк подключения.

Что вам нужно сделать, это оценить риск того, что сохранение пароля открытого текста:

• Насколько вероятно, что злоумышленник сможет обнаружить и использовать уязвимость безопасности, которая предоставляет Web.config? Основываясь на прошлой истории, я бы сказал, что вероятность низкая (но не "астрономически" низкая).
• Насколько ценными являются ваши данные? Если все, что вы храните, это фотографии вашей кошки, тогда, может быть, неважно, получит ли злоумышленник пароль вашей базы данных. Но если вы храните , то с юридической точки зрения, я бы сказал, что вы должны принять все возможные меры для защиты своего приложения, включая шифрование строк подключения.

Ответ 2

Я думаю, что это не от "внешней" защиты, а от "внутри".

Иногда администратор SQL/пользователь и администратор ОС - разные люди. Но администратор ОС имеет доступ ко всем файлам, поэтому он может легко прочитать учетные данные SQL в файле web.config. Но эти учетные данные могут быть зашифрованы таким образом, что даже администратор ОС не имеет возможности расшифровать.

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

Ответ 3

Учтите, что если производственные пароли присутствуют в файле web.config, любой разработчик, имеющий доступ к этому файлу, имеет доступ к базе данных Production. Это особенно проблема, когда имя пользователя в строке соединения имеет доступ для чтения/записи в базу данных. Затем разработчикам становится возможно "исправлять" вещи без записи, что "исправление" когда-либо происходило.

Ответ 4

Я читал некоторые статьи в онлайн-блоге IHackStuff. Этот парень объяснил некоторые способы получить действительно интересную информацию, используя поисковую систему Google, набирающую вещи в окне поиска, например:

filetype:config web.config -CVS

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

Ответ 5

Вы правы, что web.config не будет обслуживаться ASP.NET в браузере. Но разработчики осторожны, поэтому, выпуская новую версию, иногда они копируют известный хороший web.config на что-то вроде web.config.old или web.config.bak. И поскольку разработчики ленивы, после релиза они забывают удалить старый web.config или держать его висящим в течение нескольких дней, если им нужно отменить выпуск.

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

Если вы не хотите попасть в командные строки и ключи RSA (и, откровенно говоря, зачем вам?), посмотрите этот инструмент для шифрования вашего web.config.