Каковы наилучшие методы защиты раздела администратора веб-сайта?

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

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

Например:

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

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

Введите искусственную паузу на стороне сервера в каждую проверку пароля администратора, чтобы предотвратить атаки с использованием грубой силы [Developer Art]
Используйте отдельные страницы входа для пользователей и администраторов, используя одну и ту же таблицу DB (чтобы остановить XSRF и доступ к сеансу, предоставляющий доступ к областям администрирования) [Thief Master]
Рассмотрим также добавление собственной аутентификации веб-сервера в область администрирования (например, через .htaccess) [Thief Master]
Рассмотрите возможность блокировки пользователей IP после нескольких неудачных попыток входа администратора [Thief Master]
Добавить captcha после неудачных попыток входа администратора [Thief Master]
Обеспечьте одинаково сильные механизмы (используя вышеуказанные методы) для пользователей, а также администраторов (например, не обрабатывайте админов специально) [Lo'oris]
Рассмотрим аутентификацию второго уровня (например, клиентские сертификаты, смарт-карты, карты и т.д.) [JoeGeeky]
Разрешать доступ только к доверенным IP-адресам/доменам, если это возможно, добавить проверку на базовый HTTP-конвейер (например, HttpModules). [JoeGeeky]
[ASP.NET] Заблокируйте IPrincipal и Principal (сделайте их неизменяемыми и неперечислимыми) [JoeGeeky]
Элемент прав администратора - например. email других администраторов, когда какие-либо права администратора обновляются. [JoeGeeky]
Рассмотрите мелкомасштабные права для админов - например, а не прав на основе ролей, определяют права на индикативные действия для администратора [JoeGeeky]
Ограничить создание админов. Администраторы не могут изменять или создавать другие учетные записи администратора. Для этого используйте заблокированный "суперадмин". [JoeGeeky]
Рассмотрите SSL-сертификаты на стороне клиента или брелоки типа RSA (электронные маркеры) [Daniel Papasian]
При использовании файлов cookie для проверки подлинности используйте отдельные файлы cookie для администрирования и обычных страниц, например. помещая раздел администратора в другой домен. [Даниэль Папасян]
Если это практично, подумайте о том, чтобы сохранить сайт администратора в частной подсети, вне интернет-сети. [Джон Хартсок]
Переиздайте авторизационные/сеансовые билеты при переходе между административными/нормальными контекстами использования веб-сайта [Richard JP Le Guen]

Ответ 1

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

Аутентификация второго уровня. Это могут быть сертификаты клиентов (пример x509 certs), смарт-карты, карты и т.д.
Ограничения домена /IP . В этом случае только клиенты, поступающие из доверенных/проверяемых доменов; таких как внутренние подсети; разрешены в админ-зоне. Удаленные администраторы часто проходят через доверенные точки входа в VPN, поэтому их сеанс будет поддающимся проверке и часто защищен ключами RSA. Если вы используете ASP.NET, вы можете легко выполнить эти проверки в HTTP-конвейере через HTTP-модули, что не позволит вашему приложению получать какие-либо запросы, если проверки безопасности не выполняются.
Заблокировано IPrincipal и авторизация на основе основного языка. Создание пользовательских Принципов - обычная практика, хотя распространенная ошибка делает их модифицируемыми и/или перечислимыми правами. Хотя это не просто проблема с администратором, это более важно, поскольку здесь пользователи могут иметь повышенные права. Убедитесь, что они неизменны и не перечислимы. Кроме того, убедитесь, что все оценки для авторизации сделаны на основе Принципала.
Eleverate Rights Elevation. Когда какая-либо учетная запись получает выбранный номер прав, все администраторы и сотрудник службы безопасности немедленно уведомляются по электронной почте. Это гарантирует, что, если злоумышленник повысит права, мы сразу узнаем. Эти права обычно вращаются вокруг привилегированных прав, прав на просмотр информации, защищенной конфиденциальностью, и/или финансовой информации (например, кредитных карт).
Игнорировать права экономно, даже для админов. Наконец, и это может быть немного более продвинутым для некоторых магазинов. Права на авторизацию должны быть максимально осторожными и должны поддерживать реальное функциональное поведение. Типичные подходы к обеспечению безопасности на основе ролей обычно имеют менталитет Group. С точки зрения безопасности это не лучший образец. Вместо "Группы", например "Менеджер пользователей", попробуйте разбить его дальше (например, Создать пользователя, Авторизовать пользователя, Поднять/Отменить права доступа и т.д.). Это может иметь немного больше накладных расходов с точки зрения администрирования, но это дает вам гибкость в том, чтобы назначать права, которые действительно необходимы более крупной группе администраторов. Если доступ скомпрометирован, по крайней мере, они могут не получить всех прав. Мне нравится обернуть это в разрешениях безопасности доступа к коду (CAS), поддерживаемых .NET и Java, но это выходит за рамки этого ответа. Еще одна вещь... в одном приложении администраторы не могут управлять изменениями других учетных записей администратора или делать пользователями admin. Это можно сделать только через заблокированный клиент, доступ к которому может получить только пара людей.

Ответ 2

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

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

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

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

Ответ 3

Я отвергаю неясность
Использование двух систем аутентификации вместо одного - перебор.
Искусственная пауза между попытками должна быть сделана для пользователей.
Блокирование IP-адресов неудачных попыток должно выполняться для пользователей.
Сильные пароли должны использоваться пользователями также
Если вы считаете, что captchas в порядке, угадайте, что вы могли бы использовать их для пользователей.

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

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

Вот еще несколько вещей, которые следует учитывать:

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

Ответ 7

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

Ответ 8

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

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

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

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

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

Ответ 9

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

Ответ 10

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

Многие предложения касаются проверки подлинности. Я думаю, вам просто следует рассмотреть возможность использования аутентификации OpenId/Facebook в качестве логина. (Скорее всего, они будут тратить больше ресурсов на безопасность аутентификации, чем вы)
Сохранить изменения, а также обновить значения в базе данных. Таким образом, вы можете отменить изменения от пользователя X или между датой X и Y.

Ответ 11

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

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

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

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

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

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

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