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

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

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

Например:

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

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

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

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

• Аутентификация второго уровня : это могут быть клиентские сертификаты (например, сертификаты x509), смарт-карты, пространство для карт и т. Д.
• Ограничения домена / IP : в этом случае только клиенты из доверенных / проверяемых доменов; такие как внутренние подсети; разрешены в админку. Удаленные администраторы часто проходят через доверенные точки входа VPN, поэтому их сеанс можно будет проверить, и он также часто защищен ключами RSA. Если вы используете ASP.NET, вы можете легко выполнять эти проверки в конвейере HTTP через модули HTTP, что предотвратит получение вашим приложением каких-либо запросов, если проверки безопасности не будут выполнены.
• Блокированная авторизация на основе IPrincipal и принципала : создание настраиваемых принципов - обычная практика, хотя распространенной ошибкой является их изменение и / или перечисление прав. Хотя это не только проблема администратора, она более важна, поскольку именно здесь пользователи, вероятно, будут иметь повышенные права. Убедитесь, что они неизменяемы и их нельзя перечислить. Кроме того, убедитесь, что все оценки для авторизации производятся на основе принципала.
• Повышение федеративных прав : когда любая учетная запись получает определенное количество прав, все администраторы и сотрудник службы безопасности немедленно уведомляются по электронной почте. Это гарантирует, что если злоумышленник повысит права, мы сразу узнаем. Эти права обычно связаны с привилегированными правами, правами на просмотр информации, защищенной конфиденциальностью, и / или финансовой информацией (например, кредитными картами).
• Выдавайте права экономно, даже администраторам : наконец, это может быть немного более продвинутым для некоторых магазинов. Права авторизации должны быть как можно более скрытыми и должны окружать реальное функциональное поведение. Типичные подходы к обеспечению безопасности на основе ролей (RBS), как правило, основаны на групповом менталитете. С точки зрения безопасности это не лучший вариант. Вместо « Группы », например « Диспетчер пользователей », попробуйте разбить его дальше ( например, создать пользователя, авторизовать пользователя, повысить / отменить права доступа и т. Д.). Это может иметь немного больше накладных расходов с точки зрения администрирования, но это дает вам гибкость, чтобы назначать только те права, которые действительно необходимы более широкой группе администраторов. Если доступ скомпрометирован, по крайней мере, они могут не получить все права. Мне нравится обернуть это в разрешениях безопасности доступа для кода (CAS), поддерживаемых .NET и Java, но это выходит за рамки этого ответа. Еще одна вещь ... в одном приложении администраторы не могут управлять изменениями других учетных записей администратора или делать пользователей администраторами. Это можно сделать только через заблокированный клиент, доступ к которому имеют только пара человек.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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