Кодекс безопасности ASP.NET .CS - PullRequest
3 голосов
/ 19 июля 2011

Я новичок в веб-программировании и у меня есть вопрос о коде в ASP.NET C #.Насколько это безопасно, когда кто-то видит, что в нем?Причина, по которой я спрашиваю, заключается в том, что программа, с которой я связываю этот веб-сайт, требует от меня создания объекта, который принимает мои учетные данные администратора (это происходит в фоновом режиме тысячи раз, или я просто запрашиваю кредиты).Он использует учетные данные для создания вещей динамически.Я на 99,99% уверен, что это крайне небезопасно - жестко закодировать мои учетные данные на странице, но я решил спросить.

Ответы [ 6 ]

4 голосов
/ 19 июля 2011

Код, стоящий за файлами и необработанными aspx-файлами, защищен от извлечения веб-сервером, поэтому, если вы контролируете доступ консоли и общего файлового ресурса к серверу, вы относительно безопасны.

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

3 голосов
/ 19 июля 2011

ASP.NET-страницы компилируются перед отправкой страницы по HTTP. Это безопасно. Но если пользователь может получить доступ к файловой системе, у вас есть другая проблема.

3 голосов
/ 19 июля 2011

Вы должны поместить свои учетные данные в ваш файл web.config (или вы можете переместить их в отдельные файлы, такие как AppSettings.config или ConnectionStrings.config и т. Д.).Сервер будет никогда не должен их обслуживать.

Это может быть полезно: http://msdn.microsoft.com/en-us/library/4c2kcht0(v=VS.100).aspx

Это говорит о том, как вы можете сделать еще один шаг и зашифровать их, чтобы онине храните простой текстовый пароль и т. д .: http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx

2 голосов
/ 19 июля 2011

Это "безопасно".IIS (по умолчанию) не обслуживает файлы .cs.

Другой вариант - предварительно скомпилировать сайт, а затем просто удалить файлы .aspx на веб-сервере.

1 голос
/ 19 июля 2011

Здесь есть различные уровни «безопасности».

Да, IIS настроен так, чтобы не обслуживать файлы .cs или .config. Тем не менее, есть векторов атаки , которые оказались успешными в получении IIS для передачи этих файлов в руки злодеев.

Во-первых, я бы не стал развертывать файлы .cs на сервере. Если возможно, преобразуйте веб-сайт в веб-приложение и разверните его скомпилировано. Конечно, код .net может быть декомпилирован ( и здесь ); поэтому вы также должны заглянуть в обфускацию . Однако даже обфусцированный код может быть декомпилирован , но обычно его труднее читать. ;)

Обратите внимание, что каждый уровень не является действительно "безопасным". Это только усложняет.

Реальный ответ - вообще не хранить учетные данные на сервере и требовать, чтобы они были предоставлены клиентом через зашифрованный транспорт. Конечно, вы можете кэшировать их в памяти, но даже , который оказался небезопасным для тех, кто имеет физический доступ .

В конце дня спросите себя, насколько ценны ключи и сколько денег / времени вы можете инвестировать в защиту системы. Обычно где-то есть баланс.

1 голос
/ 19 июля 2011

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

...