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


72

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

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

Например:

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

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

  • Ввести искусственную сторону сервера паузу в каждую проверку пароля администратора в предотвращать атаки грубой силы [Developer Art]
  • Используйте отдельные страницы входа для пользователей и администраторов, используя одну и ту же таблицу БД (чтобы остановить XSRF и предоставление доступа к сеансу доступа к области администрирования s) [Thief Master]
  • Рассмотрите возможность добавления собственной аутентификации веб-сервера в область администрирования (например, через .htaccess) [Thief Master]
  • Рассмотрим блокирование пользователей IP после нескольких неудачных попыток входа в систему администратора [Thief Master]
  • Добавить Captcha после неудачных попыток входа в систему администратора [Thief Master]
  • Обеспечить одинаково сильные механизмы (с использованием вышеуказанных методов) для пользователей, а также администраторов (например, не обрабатывать админов специально) [Lo'oris]
  • Рассмотрите аутентификацию второго уровня (например, клиентские сертификаты, смарт-карты, карты и т. Д. .) [JoeGeeky]
  • Разрешить доступ только с доверенных IP-адресов/доменов, добавить проверку на базовый HTTP-конвейер (например, HttpModules), если это возможно. [JoeGeeky]
  • [ASP.NET] Блокировка IPrincipal & Principal (сделать их неизменны и не перечислимы) [JoeGeeky]
  • Federate Права Elevation - например, email других администраторов, когда какие-либо права администратора обновляются. [JoeGeeky]
  • Рассмотрите мелкозернистые права для администраторов - например. а не прав, основанных на ролях, определить права на индикативные действия для администратора [JoeGeeky]
  • Ограничение создания админов - например, Администраторы не могут изменять или создавать другие учетные записи администратора. Для этого используйте заблокированный «суперадмин».[JoeGeeky]
  • Рассмотрим на стороне клиента SSL-сертификатов, или брелоками RSA типа (электронные жетоны) [Daniel Папазян]
  • При использовании куки для проверки подлинности, используйте отдельные куки для администратора и обычные страницы, с помощью, например, помещая раздел администратора в другой домен. [Daniel Papasian]
  • Если это практично, подумайте о том, чтобы сохранить сайт администратора в частной подсети, вне общедоступного Интернета. [John Hartsock]
  • Переиздание авториз/сеансовые билеты при перемещении между администратора/нормальных условиях использования веб-сайта [Richard JP Le Guen]
+2

Просто мысль, но. Вероятно, лучший способ защитить раздел администратора - это не использовать его в общедоступном Интернете. Вы можете сохранить сайт администратора только в частной подсети. 27 май. 102010-05-27 20:44:27

+1

Какие из этих идей вы указали, было бы неплохо обратиться ко всем пользователям, а не только к администраторам? 28 май. 102010-05-28 16:59:18

  0

Возможно, вы захотите проверить WebLoginProject по адресу http://www.webloginproject.com/, это совместная система входа в систему, предназначенная для защиты от XSS, SQL Injection, Session fixation и CSRF. Он имеет исходный код в ASP и PHP, он многоязычный, и он выглядит круто. Многие разработчики работают над этим, фиксируя отверстия, поэтому это, вероятно, как можно ближе к безопасности. 31 май. 102010-05-31 11:32:06

  0

-1 для включения ужасно неправильного «надежного пароля» (который на самом деле является ** очень ** слабым паролем) предложение 27 мар. 122012-03-27 13:37:34

  0

@Lohoris - Я действительно не понимаю, почему вы отказали в этом вопросе. Вы сбиваете с толку, потому что я судировал какое-то предложение, с которым вы не согласны? Возможно, более отрицательный ответ будет более конструктивным. :/Можете ли вы точно выяснить, с чем у вас проблема? 27 мар. 122012-03-27 14:06:09

  0

@UpTheCreek Я сделал downvote, что на конкретный ответ, конечно, и объяснил это там. Поскольку я считаю, что это «предложение» крайне плохое, я считаю правильным свести все эти советы только от того, что этот совет присутствует здесь. 27 мар. 122012-03-27 14:11:20

  0

@UpTheCreek Я говорил об этом ужасе -> http://stackoverflow.com/a/2848151/207655 27 мар. 122012-03-27 14:18:08

  0

@Lohoris - Ну ладно. 27 мар. 122012-03-27 14:26:44

  0

Я беру на себя смелость удалить это предложение, это сообщество wiki в конце концов. 27 мар. 122012-03-27 14:31:37

  0

NARQ ........... 27 мар. 122012-03-27 14:43:16

  0

Получите номер, в котором вы двое! :) 27 мар. 122012-03-27 16:06:45

14

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

  • аутентификации Второй уровень: Это может включать в себя клиентские сертификаты, смарт-карты, CardSpace и т.д. (Ex X509 CERTS). ...
  • Ограничения домена/IP: В этом случае только клиенты, поступающие из доверенных/проверяемых доменов; таких как внутренние подсети; разрешены в админ-зоне. Удаленные администраторы часто проходят через доверенные точки входа в VPN, поэтому их сеанс будет поддающимся проверке и часто защищен ключами RSA. Если вы используете ASP.NET, вы можете легко выполнить эти проверки в HTTP-конвейере через HTTP-модули, что не позволит вашему приложению получать какие-либо запросы, если проверки безопасности не выполняются.
  • Заблокирован IPrincipal & Авторизация пользователя: Создание пользовательских Принципов является распространенной практикой, хотя распространенная ошибка делает их модифицируемыми и/или перечислимыми правами. Хотя это не просто проблема с администратором, это более важно, поскольку здесь пользователи могут иметь повышенные права. Убедитесь, что они неизменны и не перечислимы. Кроме того, убедитесь, что все оценки для авторизации сделаны на основе Принципала.
  • Elevate Rights Elevation: Когда какая-либо учетная запись получает выбранный номер прав, все администраторы и сотрудник службы безопасности немедленно уведомляются по электронной почте. Это гарантирует, что, если злоумышленник повысит права, мы сразу узнаем. Эти права обычно вращаются вокруг привилегированных прав, прав на просмотр информации, защищенной конфиденциальностью, и/или финансовой информации (например, кредитных карт).
  • Выдавать права экономно, даже админам: И наконец, это может быть немного более продвинутым для некоторых магазинов. Права на авторизацию должны быть максимально осторожными и должны поддерживать реальное функциональное поведение. Типичные подходы к обеспечению безопасности на основе ролей имеют тенденцию иметь менталитет . С точки зрения безопасности это не лучший образец. Вместо 'Группы' like 'User Manager', попробуйте разбить его дальше (Ex. Создать пользователя, авторизовать пользователя, Поднять/Отменить права доступа и т. Д. ...). Это может иметь немного больше накладных расходов с точки зрения администрирования, но это дает вам гибкость в том, чтобы назначать права, которые действительно необходимы более крупной группе администраторов. Если доступ скомпрометирован, по крайней мере, они могут не получить всех прав. Мне нравится обернуть это в разрешениях безопасности доступа к коду (CAS), поддерживаемых .NET и Java, но это выходит за рамки этого ответа. Еще одна вещь ... в одном приложении администраторы не могут управлять изменениями других учетных записей администратора или делать пользователями admin. Это можно сделать только через заблокированный клиент, доступ к которому может получить только пара людей.

1

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

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

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

  0

Не могли бы вы немного объяснить, что такое «пауза»? Вы имеете в виду делать что-то вроде Thread.Sleep (5000), чтобы просто убить какое-то время? 25 май. 102010-05-25 18:17:04

  0

@senloe: Да, просто добавьте задержку искусственного отклика для ограничения попыток за интервал времени. 25 май. 102010-05-25 20:03:01

  0

Это ничего не обслуживает. Вы можете запросить другой пароль, пока другой запрос будет спящим. 31 май. 102010-05-31 11:46:57

  0

@Andreas Bonini: Если вы не ограничиваете запросы по IP и не имеете общий лимит для проверок в минуту. 31 май. 102010-05-31 12:04:29

+4

Это глупо: пароль, который слишком сложный, чтобы его помнили, записывается где-то (или сохраняется), что делает ситуацию намного хуже, чем если бы вы допустили ДЕЙСТВИТЕЛЬНО хороший пароль (то есть пароль, который будет набран, потому что вы помните его вместо копирования вставили). 12 сен. 102010-09-12 21:34:54

+3

О, мне жаль, что я не смогу спустить это дерьмо до каменного века, это так глупо, так неправильно ... Я ненавижу людей, распространяющих дезинформацию, такую ​​как эта. 18 май. 112011-05-18 08:12:26

+1

@ Lo'oris: С чем вы не согласны? 18 май. 112011-05-18 18:23:58

+2

Я написал это в ... как ... комментарий чуть выше? 19 май. 112011-05-19 18:28:01


17

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

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

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

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


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

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

+5

Спасибо за ответ. Лично я склонен не соглашаться, например: будет ли пользователь счастлив с паролями, такими как «ksd83», 4d # rrpp0% 27 & lq (go43 $ sd {3> '? И, не сброс IP-блоков, которые действительные пользователи вызвали, будучи забыв о том, что вы создадите ненужную работу администратора/клиента? Лично я думаю, что разные уровни риска оправдывают разные подходы. 17 май. 102010-05-17 11:22:42

+1

. Пароль администратора должен быть сложным, но не слишком сложным, иначе даже администратор не запомнит его и запишет где-нибудь (вы заставит его бросить вызов каждому правилу безопасности).Временное блокирование IP-адресов с неудачной попыткой является довольно стандартным, vbulletin делает это, phpbb делает это IIRC, пользователи к нему привыкли. 17 май. 102010-05-17 11:44:51

  0

Я действительно не хочу искать phpbb или vbulletin для лучших рекомендаций по безопасности;) 27 мар. 122012-03-27 14:12:38

  0

@UpTheCreek, конечно, согласен! Я просто спрашивал об этом: «Не переустанавливает IP-блоки, которые действительные пользователи вызвали, забыв о том, что вы не выполняете ненужную работу администратора/обслуживания клиентов» _ <- Я не думаю, что это будет проблемой, потому что пользователи уже привыкший к такой функции. 27 мар. 122012-03-27 14:17:36

  0

А я вижу, правильно 27 мар. 122012-03-27 14:28:18


1

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

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

-2

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

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

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

+1

Facebook-аутентификация для раздела администрирования веб-сайта ... вы действительно думаете, что это хорошая идея? Для обычных пользователей да ... но для раздела _admin_? Мне немного опасно ... 30 май. 102010-05-30 21:55:47

  0

Я не уверен. но я думаю, что на этих сайтах работает только аутентификация openid. И я не думаю, что существует большая (теоретически) разница между аутентификацией facebook и openid. Но я не читал никаких лицензионных соглашений или таких. 30 май. 102010-05-30 22:30:03

+1

Очень плохой идеей openid для аутентификации администратора, также откат в большинстве случаев невозможно, а плохой парень готов в вашей системе ... какой откат? 01 июн. 102010-06-01 12:31:17

  0

Не стесняйтесь объяснять, почему вы думаете, что это плохо. Ну, если вы входите в систему как администратор, вы получаете полный доступ к db и резервную копию, которую, безусловно, трудно откат, но в этом случае вы все готовы потерять. Мои предложения были направлены на сайт cmsisch. 01 июн. 102010-06-01 13:24:56


3

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

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

  0

Не могли бы вы объяснить, что это значит? 15 сен. 162016-09-15 20:51:13

  0

Я считаю, что это не поможет столько, сколько вы думаете. Поскольку, если злоумышленник может получить ваш текущий идентификатор сеанса на обычной пользовательской странице, он может использовать его для доступа к странице администратора и генерации нового идентификатора сеанса. Поправьте меня если я ошибаюсь. 15 сен. 162016-09-15 21:15:46

+1

Но злоумышленник не может получить доступ к странице администратора без пароля. Смена уровня привилегий до авторизации не происходит. Невозможность восстановить идентификатор сеанса означает, что они могут повторно использовать сеанс, созданный в незащищенном режиме, чтобы обойти аутентификацию. 15 сен. 162016-09-15 21:44:38

  0

Получил это сейчас. Я думал, что вы описали сценарий, когда пользователю не нужно повторно регистрироваться при переключении между обычным/административным контекстом. 15 сен. 162016-09-15 21:54:21


-1

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

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

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

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

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

  0

Я думаю, что это было бы действительно полезно или практично только в ситуациях CMS/публикации, когда вы нажимаете контент, а не обрабатываете данные. 01 июн. 102010-06-01 06:55:51

  0

Возможно, но я знал (и видел) ситуации, когда это делается для обработки и ввода пользователя. Для одной фермы с отдельным сервером редактирования это не проблема. Для нескольких ферм то, что вы делаете, - это вход с сайта в очередь (DB или иначе) и, используя внешнюю процедуру, обрабатывается и копируется в «редактирующий» сервер/БД. Это дает вам больше контроля над тем, что входит в вашу систему. Это, однако, сложно реализовать. 02 июн. 102010-06-02 12:09:37


1

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


-3

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

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

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

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

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

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

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


-1

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

  0

-1 для md5. Вы не хотите быстрый хэш для паролей, даже вне других проблем с md5ing. bcrypt будет лучшим вариантом. 28 дек. 112011-12-28 16:26:43