Что такое лучшие практики для обеспечения администраторского раздела веб-сайта? [закрытый]
11 ответов
Это все хорошие ответы ... Обычно мне нравится добавлять пару дополнительных уровней для моих административных разделов. Хотя я использовал несколько вариантов темы, они обычно включают одно из следующего:
- Аутентификация второго уровня : это могут быть клиентские сертификаты (например, сертификаты x509), смарт-карты, пространство для карт и т. Д. .
- Ограничения домена / IP : В этом случае только клиенты из доверенных / проверяемых доменов; такие как внутренние подсети; разрешены в админку. Удаленные администраторы часто проходят через доверенные точки входа VPN, поэтому их сеанс можно будет проверить, а также часто он защищен ключами RSA. Если вы используете ASP.NET, вы можете легко выполнить эти проверки в конвейере HTTP через модули HTTP, что предотвратит получение вашим приложением каких-либо запросов, если проверки безопасности не будут выполнены.
- Блокированная авторизация на основе IPrincipal и принципала : Создание настраиваемых принципов - обычная практика, хотя распространенной ошибкой является их изменение и / или перечисление прав. Хотя это не только проблема администратора, она более важна, поскольку именно здесь пользователи, вероятно, будут иметь повышенные права. Убедитесь, что они неизменяемы и их нельзя перечислить. Кроме того, убедитесь, что все оценки для авторизации производятся на основе принципала.
- Повышение прав федерации : когда любая учетная запись получает определенное количество прав, все администраторы и офицер безопасности немедленно уведомляются по электронной почте. Это гарантирует, что если злоумышленник повысит права, мы сразу узнаем. Эти права обычно связаны с привилегированными правами, правами на просмотр информации, защищенной конфиденциальностью, и / или финансовой информацией (например, кредитными картами).
- Выдавайте права экономно, даже администраторам : Наконец, это может быть немного более продвинутым для некоторых магазинов. Права авторизации должны быть как можно более скрытыми и должны окружать реальное функциональное поведение. Типичные подходы к обеспечению безопасности на основе ролей (RBS), как правило, основаны на менталитете группы . С точки зрения безопасности это не лучший шаблон. Вместо « Группы », например « Диспетчер пользователей », попробуйте разбить его дальше ( Например, создать пользователя, авторизовать пользователя, повысить / отменить права доступа и т. Д. ). Это может иметь немного больше накладных расходов с точки зрения администрирования, но это дает вам гибкость, чтобы назначать только те права, которые действительно необходимы более широкой группе администраторов.Если доступ скомпрометирован, по крайней мере, они могут не получить все права. Мне нравится обернуть это в разрешениях безопасности доступа к коду (CAS), поддерживаемых .NET и Java, но это выходит за рамки этого ответа. Еще одна вещь ... в одном приложении администраторы не могут управлять изменениями других учетных записей администраторов или делать пользователей администраторами. Это можно сделать только с помощью заблокированного клиента, доступ к которому имеет только пара человек.
Если веб-сайт требует входа в систему как для обычных действий, так и для администраторов, например для форума, я бы использовал отдельные логины, которые используют одну и ту же базу данных пользователей. Это гарантирует, что XSRF и кража сеансов выиграют » t разрешить злоумышленнику доступ к административным областям.
Кроме того, если раздел администратора находится в отдельном подкаталоге, защита этого подкаталога с помощью аутентификации веб-сервера (например, .htaccess в Apache) может быть хорошей идеей - тогда кому-то понадобится и то, и другое. пароль и пароль пользователя.
Сокрытие пути администратора почти не дает повышения безопасности - если кто-то знает действительные данные для входа в систему, он, скорее всего, также сможет узнать путь к инструменту администратора, поскольку он либо фишинг, либо кейлоггинг вас, либо получил его с помощью социальной инженерии (которая, вероятно, тоже укажет путь).
Защита от перебора, такая как блокировка пользователя I P после 3 неудачных попыток входа в систему или требование CAPTCHA после неудачного входа в систему (не для первого входа в систему, поскольку это очень раздражает законных пользователей).
Имейте хороший пароль администратора.
Не «123456» , а последовательность букв, цифр и специальных символов, достаточно длинная, скажем, 15-20 символов. Например "ksd83, '| 4d # rrpp0% 27 & lq (go43 $ sd {3>" .
Добавьте паузу для каждой проверки пароля, чтобы предотвратить атаку методом грубой силы.
- Я отвергаю неясность
- Использование двух систем аутентификации вместо одной - это перебор
- Искусственная пауза между попытками должна быть сделана и для пользователей
- Блокировка IP неудачных попыток должна быть сделана и для пользователей
- Сильные пароли должны использоваться и пользователями
- Если вы считаете капчи нормальными, угадайте что, вы можете использовать их и для пользователей
Да, после написания этого, я понимаю, что этот ответ можно обобщить как "ничего особенного для логина администратора, это все средства безопасности, которые должны использоваться для любого логина".
Вот некоторые другие вещи, которые следует рассмотреть:
- Один из вариантов, который можно рассмотреть, особенно если вы управляете компьютерами администраторов или они технически компетентны, - это использование чего-то на основе SSL-сертификатов для аутентификации клиентов. Для дополнительной безопасности можно также использовать брелоки RSA и т.п.
- Если вы вообще используете cookies - возможно, для аутентификации/маркера сессии - вы, вероятно, захотите убедиться, что cookies отправляются только на страницы администратора. Это поможет снизить риски, возникающие при краже cookie-файлов на вашем сайте в результате компрометации уровня 1/2 или XSS. Этого можно легко добиться, разместив административную часть на другом хосте или домене, а также установив флаг безопасности в cookie.
- Ограничение по IP также может быть разумным, и если у вас есть пользователи по всему интернету, вы все равно можете сделать это, если есть надежная VPN, к которой они могут присоединиться.
Если вы используете только один логин для пользователей, имеющих как привилегии обычного пользователя, так и администратора, регенерируйте их идентификатор сессии (будь то cookie или GET-параметр, или что-то еще...) при изменении уровня привилегий... как минимум.
Так что если я войду в систему, сделаю кучу обычных пользовательских действий, а затем зайду на страницу администратора, то регенерирую свой идентификатор сессии. Если я затем перехожу со страницы администратора на страницу обычного пользователя, снова регенерируйте мой ID.
Это очень сильно зависит от того, какие данные вы хотите защитить (требования законодательства и т. Д.).
Многие предложения касаются аутентификации ... Я думаю, вам просто стоит подумать об использовании аутентификации OpenId / Facebook в качестве входа в систему. (Скорее всего, они потратят больше ресурсов на безопасность аутентификации, чем вы)
Сохраните изменения, а также обновите значения в базе данных. Таким образом вы можете откатить изменения от пользователя X или между датами X и Y.
Мы используем Аутентификацию Windows для доступа администратора. Это наиболее практичный способ защиты административных областей, при этом аутентификация отделена от того, что применяется к обычным конечным пользователям. Системный администратор управляет учетными данными для доступа администратора и применяет политики паролей к учетной записи пользователя домена.
Добавьте поле пароля и секретный вопрос, который будет известен администратору, например как звали вашу первую девушку, или задавайте вопросы в случайном порядке каждый раз при просмотре панели администратора.
Возможно, вы всегда можете поместить раздел администрирования в большой каталог, например
Но это не очень хорошо, ха.
Возможно, вы могли бы включить строку запроса на домашнюю страницу, например:
Когда это произойдет, появится поле имени пользователя и пароля.
Строгий способ - иметь две совершенно разные "фермы", включая базы данных, серверы и все остальное, и перенести данные из одной фермы в другую. Большинство современных крупномасштабных систем используют этот подход (Vignette, SharePoint и т.д.). Обычно это называется наличием различных стадий "стадия редактирования" -> "стадия предварительного просмотра" -> "стадия доставки". Этот метод позволяет вам относиться к содержимому/конфигурации так же, как к коду (dev->qa->prod).
Если вы менее параноидальны, вы можете иметь единую базу данных, но иметь только ваш административный раздел, доступный на серверах "редактирования". Я имею в виду, чтобы только скрипты/файлы редактирования были размещены на сервере редактирования.
Естественно, стадия редактирования должна быть доступна только в локальной интрасети и/или с использованием VPN.
Это может показаться излишеством и не самым простым решением для всех случаев использования, но это определенно самый надежный способ.
Обратите внимание, что такие вещи, как "иметь надежные пароли администратора", хороши, но все равно оставляют вашего администратора открытым для умных атак всех видов.
Я не заметил, чтобы кто-то упоминал о хранении/проверке пароля администратора. Пожалуйста, не храните PW в виде обычного текста, и желательно даже не такого, который можно изменить - используйте что-то вроде соленого хэша MD5, чтобы, по крайней мере, если кто-то случайно получит сохраненный "пароль", у него не будет ничего особо полезного, если только он не знает вашу схему соли.