Каковы рекомендации по обеспечению безопасности раздела администратора веб-сайта? [закрытый]

Я хотел бы знать, что люди считают лучшей практикой для обеспечения безопасности административных разделов веб-сайтов, особенно с точки зрения аутентификации/доступа.

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

например:

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

до сих пор предложения от ответчиков включают:

  • введите искусственную паузу на стороне сервера в каждую проверку пароля администратора, чтобы предотвратить атаки грубой силы [разработчик Искусство]
  • используйте отдельные страницы входа для пользователей и администратора, используя одну и ту же таблицу БД (чтобы остановить XSRF и кражу сеанса, предоставляющую доступ к областям администрирования) [Вор Мастер]
  • рассмотрите также возможность добавления собственной аутентификации веб-сервера в административную область (например, через.htaccess)[Вор Мастер]
  • рассмотрите возможность блокировки IP пользователей после нескольких неудачных попыток входа администратора [Вор Мастер]
  • добавить капчу после неудачных попыток входа администратора [Вор Мастер]
  • обеспечить одинаково сильные механизмы (используя вышеуказанные методы) для пользователей, а также администраторов (например, не относиться к администраторам специально) [Ло'oris]
  • рассмотрим аутентификацию второго уровня (например, сертификаты клиента, смарт-карты, cardspace и т. д.)[JoeGeeky]
  • разрешить доступ только из доверенных IPs / доменов, добавить проверку в базовый http-конвейер (например, через HttpModules), если вероятный. [JoeGeeky]
  • [ASP.NET] заблокировать IPrincipal & Principal (сделать их неизменяемыми и не перечисляемыми)[JoeGeeky]
  • интегрировать высоты прав - например, по электронной почте другие админы, когда права администратора обновляются. [JoeGeeky]
  • рассмотрим мелкозернистые права для администраторов-например, вместо прав на основе ролей, определите права для indicidual действий для администратора [JoeGeeky]
  • ограничить создание админы - например, администраторы не могут изменять или создавать другие учетные записи администратора. Для этого используйте заблокированный клиент 'superadmin'. [JoeGeeky]
  • рассмотрим SSL-сертификаты на стороне клиента или брелки типа RSA (электронные токены) [Дэниел Папазян]
  • если вы используете куки для аутентификации, используйте отдельные куки для admin и обычных страниц, например, поместив раздел admin на другой домен. [Дэниел Папазян]
  • если это возможно, сохраните админ на частную подсеть от интернета. [Джон Хартсок]
  • переиздать билеты auth / session при перемещении между контекстами admin/normal использования веб-сайта [Richard JP Le Guen]
11 77
forms-authentication security

11 ответов:

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

  • аутентификация второго уровня: это может включать сертификаты клиента (например. x509 certs), смарт-карты, cardspace и т. д...
  • домен/IP ограничения: в этом случае только клиенты, поступающие из доверенных / проверяемых Домены, такие как внутренние подсети, допускаются в административную область. Удаленные администраторы часто проходят через доверенные точки входа VPN, поэтому их сеанс будет проверяться и часто защищен ключами RSA. Если вы используете ASP.NET вы можете легко выполнить эти проверки в HTTP-конвейере через HTTP-модули, которые не позволят вашему приложению получать какие-либо запросы, если проверки безопасности не будут удовлетворены.
  • заблокирован IPrincipal & Principal-based Авторизация: создание пользовательских принципов является обычной практикой, хотя распространенная ошибка делает их изменяемыми и/или перечисляемыми правами. Хотя это не просто проблема администратора, это более важно, так как здесь пользователи, вероятно, имеют повышенные права. Убедитесь, что они неизменны и не поддаются перечислению. Кроме того, убедитесь, что все оценки для авторизации производятся на основе Принципала.
  • Федеративное Повышение Прав: когда какая-либо учетная запись получает выберите количество прав, все администраторы и сотрудник Службы безопасности немедленно уведомляются по электронной почте. Это гарантирует, что если злоумышленник повышает права, мы сразу узнаем. Эти права, как правило, вращаются вокруг привилегированных прав, прав на просмотр защищенной конфиденциальности информации и/или финансовой информации (например, кредитных карт).
  • выдавать права экономно, даже админам: наконец, и это может быть немного более продвинутая по некоторым магазинам. Права должны быть сдержанный, насколько это возможно и должно окружать реальное функциональное поведение. Типичные подходы безопасности на основе ролей (RBS), как правило, имеют группа менталитет. С точки зрения безопасности это не лучший образец. Вместо'группы "как"Диспетчер Пользователей', попробуйте разбить его вниз ( Ex. Создать пользователя, авторизация пользователя, поднять и отмена прав доступа и т. д...). Это может иметь немного больше накладных расходов с точки зрения администрирования, но это дает вы можете гибко назначать только те права, которые действительно необходимы более крупной группе администраторов. Если доступ скомпрометирован, по крайней мере, они не могут получить все права. Мне нравится обертывать это в разрешениях Code Access Security (CAS), поддерживаемых .NET и Java, но это выходит за рамки этого ответа. Еще одна вещь... в одном приложении администраторы не могут управлять изменением других учетных записей администратора или сделать пользователей администратором. Это может быть сделано только через заблокированный клиент, который может только пара человек доступ.
14

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

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

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

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

18
  • Я отвергаю безвестности
  • использование двух систем аутентификации вместо одной является излишним
  • искусственная пауза между попытками должна быть сделана и для пользователей
  • блокировка IP-адресов неудачных попыток должна быть выполнена и для пользователей
  • надежные пароли должны использоваться пользователями тоже
  • Если вы считаете captchas ОК, угадайте, что, вы могли бы использовать их для пользователей тоже

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

7

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

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

3

есть хороший пароль администратора.

не "123456" но последовательность букв, цифр и специальных символов достаточно долго, скажем, 15-20 символов. Как "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>".

добавьте паузу для каждой проверки пароля, чтобы предотвратить атаку грубой силы.

1

вот некоторые другие вещи, чтобы рассмотреть:

  1. одним из вариантов рассмотрения, особенно если вы управляете компьютерами администратора или они технически компетентны, является использование чего-то на основе сертификатов SSL для аутентификации клиента. Брелки RSA и многое другое также могут быть использованы для дополнительной безопасности.
  2. Если вы вообще используете куки-файлы-возможно, для токена аутентификации / сеанса-вы, вероятно, хотите убедиться, что куки отправляются только на страницы администратора. Этот помогает снизить риски, связанные с вашим сайтом, путем кражи куки-файлов, либо компромиссом уровня 1/2, либо XSS. Это можно сделать легко, если часть администратора находится на другом имени хоста или домене, а также устанавливает безопасный флаг с помощью файла cookie.
  3. ограничение по IP также может быть умным, и если у вас есть пользователи по всему интернету, вы все равно можете это сделать, если есть доверенный VPN, к которому они могут присоединиться.
1

мы используем:Windows Authentication для доступа администратора. Это наиболее практичный способ защиты административных областей, сохраняя при этом аутентификацию отдельно от того, что относится к общим конечным пользователям. Системный администратор управляет учетными данными доступа администратора и применяет политики паролей к учетной записи пользователя домена.

1

строгий способ состоит в том, чтобы иметь две полные разные "фермы", включая базы данных, серверы и все, и перемещать данные из одной фермы в другую. Большинство современных, крупномасштабных систем используют этот подход (виньетка, SharePoint и т. д.). Обычно он упоминается как имеющий различные этапы "этап редактирования" - > "этап предварительного просмотра" - > "этап доставки". Этот метод позволяет обрабатывать содержимое / конфигурацию так же, как вы обрабатываете код (dev->qa->prod).

Если вы не менее параноик, вы можете иметь один база данных, но только ваш раздел администратора доступен на серверах "редактирования". Я имею в виду, только есть сценарии редактирования/файлы, размещенные на сервере редактирования.

естественно, этап редактирования должен быть доступен только в локальной интрасети и/или с помощью VPN.

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

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

-1

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

  • много предложений касается аутентификации.. Facebook OpenID я думаю, что вы просто должны рассмотреть возможность использования аутентификации OpenId / Facebook в качестве логина. (Они, скорее всего, потратят больше ресурсов на безопасность аутентификации, чем вы)

  • Сохранить изменения, а также обновление значений в базе данных. Таким образом, вы можете откатить изменения от пользователя X или между датами X и Y.

-2

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

-2

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

возможно, вы всегда можете поместить раздел администрирования в большой каталог, например

http://domain.com/sub/sub/sub/sub/sub/index.php

но это не очень хорошо хах.

возможно, вы могли бы включить запрос строка на главной странице, например:

http://domain.com/index.php?display=true

когда это произойдет, появится поле Имя пользователя и пароль.

-3