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


92

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

Конечно, есть очевидные вещи, такие как использование 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 для административных и обычных страниц, например, поместив раздел администратора в другой домен. [Даниэль Папасян]
  • Если возможно, рассмотрите возможность сохранения административного сайта в частной подсети, вне общедоступного Интернета. [Джон Хартсок]
  • Повторно выпустить билеты авторизации / сеанса при переходе между административным и обычным контекстами использования веб-сайта [Ричард Дж. П. Ле Гуен]

2
Просто мысль, но. Вероятно, лучший способ защитить раздел администратора - не размещать его в общедоступном Интернете. Вы можете сохранить сайт администратора только в частной подсети.
Джон Хартсок

1
Какую из этих идей, которые вы указали, не было бы хорошей идеей применить ко всем пользователям, а не только к администраторам?
Vivian River

Вы можете проверить WebLoginProject на webloginproject.com. Это система совместного входа в систему, которая разработана специально для защиты от XSS, SQL-инъекций, фиксации сеансов и уязвимостей CSRF. Он имеет исходный код на ASP и PHP, он многоязычный и выглядит круто. Многие разработчики работают над исправлением дыр, так что это, вероятно, настолько безопасно, насколько это возможно.
stagas

-1 за включение ужасно неправильного «надежного пароля» (который на самом деле вместо этого является очень слабым паролем)
o0 '.

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

Ответы:


19

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

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

19

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

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

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

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


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

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


6
Спасибо за ответ. Лично я склонен не соглашаться, например: Был бы пользователь доволен такими паролями, как 'ksd83,' | 4d # rrpp0% 27 & lq (go43 $ sd {3> '? И не сбрасывает ли блокировку IP, которую действительные пользователи инициировали, будучи забывчивость
приведет

1
Пароль администратора должен быть сложным, но не слишком сложным, иначе даже администратор не запомнит его и где-нибудь запишет (вы бы заставили его нарушить все правила безопасности). Временная блокировка IP-адресов при неудачной попытке - это довольно стандартно, vbulletin делает это, phpbb делает это IIRC, пользователи к этому привыкли.
о0 '.

Я действительно не хочу обращаться к phpbb или vbulletin за лучшими практиками безопасности;)
UpTheCreek

@UpTheCreek конечно согласен! Я просто задавал вопрос: «Не сбрасывает ли IP-блоки, которые действительные пользователи запустили из-за того, что забывчивость создает ненужную работу администратора / обслуживания клиентов» <- я не думаю, что это будет проблемой, потому что пользователи уже используются к такой особенности.
о0 '.

3

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

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


Не могли бы вы объяснить, что это дает?
Денис Пшенов


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

1
Но злоумышленник не может получить доступ к странице администратора без пароля. До аутентификации уровень привилегий не меняется. Неспособность повторно создать идентификатор сеанса означает, что они могут повторно использовать сеанс, созданный небезопасно, для обхода аутентификации.
Ричард JP Le Guen

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

1

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

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

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


не могли бы вы немного объяснить, что такое «пауза»? Вы имеете в виду сделать что-то вроде Thread.Sleep (5000), чтобы просто убить время?
землянин

6
это глупо: пароль, слишком сложный для запоминания, будет где-то записан (или сохранен), поэтому дела обстоят намного хуже, чем если бы вы разрешили ДЕЙСТВИТЕЛЬНО хороший пароль (т.е. пароль, который будет набран, потому что вы его помните, а не скопируйте вставленный ).
о0 '.

4
О, как бы я хотел опустить это дерьмо до каменного века, это так глупо, так неправильно ... Я ненавижу людей, распространяющих дезинформацию, подобную этой.
о0 '.

1
@ Ло'орис: С чем именно вы не согласны?

2
Я написал это ... как ... комментарий чуть выше?
о0 '.

1

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

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

1

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


-1

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

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

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

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

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


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

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

-2

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

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

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


1
Аутентификация Facebook для раздела администратора веб-сайта ... вы действительно думаете, что это хорошая идея? Для обычных пользователей да ... а для админки ? Мне кажется немного опасным ...
Ричард Ле Гуэн,

Я не уверен. но я думаю, что на этих сайтах выполняется только аутентификация openid. И я не думаю, что есть большая (теоретически) разница между аутентификацией facebook и openid. Но я не читал никаких лицензионных соглашений и тому подобного.
Карл Бергквист,

1
Очень плохая идея openid для аутентификации администратора, к тому же откат в большинстве случаев невозможен, а плохой парень уже готов внутри вашей системы ... какой откат?
Аристос

Не стесняйтесь объяснять, почему вы думаете, что это плохо. Что ж, если вход в систему как администратор дает вам полный доступ к базе данных и резервному копированию, откат наверняка будет затруднен, но в этом случае вы все потеряете. Мои предложения были направлены на cmsisch-сайт.
Карл Бергквист

-3

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


1
-1 для md5. Вам не нужен быстрый хэш для паролей, даже помимо других проблем с md5ing. bcrypt был бы лучшим вариантом.
Kzqai

-4

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

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

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

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.