Які найкращі методи захисту адміністративного розділу веб-сайту? [зачинено]

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

Звичайно, є очевидні речі, такі як використання 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]
• Обмежте створення адміністраторів - наприклад, адміністратори не можуть змінювати або створювати інші облікові записи адміністратора. Для цього скористайтеся заблокованим клієнтом "superadmin". [JoeGeeky]
• Розгляньте клієнтські SSL-сертифікати або брелоки типу RSA (електронні токени) [Даніель Папасіан]
• Якщо ви використовуєте файли cookie для автентифікації, використовуйте окремі файли cookie для адміністратора та звичайних сторінок, наприклад, розмістивши розділ адміністратора на іншому домені. [Даніель Папасіан]
• Якщо це можливо, розгляньте можливість розміщення сайту адміністратора у приватній підмережі поза громадським Інтернетом. [Джон Хартсок]
• Перевидавати квитки для авторизації / сеансу при переході між адміністративним / звичайним контекстами використання веб-сайту [Richard JP Le Guen]

Це все хороші відповіді ... Я взагалі люблю додавати ще пару додаткових шарів для своїх адміністративних розділів. Хоча я використовував кілька варіантів теми, вони, як правило, включають одне з наступного:

• Аутентифікація другого рівня : сюди можуть входити сертифікати клієнта (наприклад, сертифікати x509), смарт-картки, простір карт тощо.
• Обмеження домену / IP : у цьому випадку лише клієнти, що надходять із довірених / перевіряваних доменів; такі як внутрішні підмережі; дозволено потрапляти в адміністративну область. Віддалені адміністратори часто проходять через надійні точки входу VPN, тому їх сеанс може бути перевіреним і часто також захищений ключами RSA. Якщо ви використовуєте ASP.NET, ви можете легко виконати ці перевірки в трубопроводі HTTP за допомогою модулів HTTP, що не дозволить вашій програмі отримувати будь-які запити, якщо перевірки безпеки не будуть задоволені.
• Заблокована авторизація на основі IPrincipal & Principal : Створення власних принципів є звичайною практикою, хоча типовою помилкою є їх модифікація та / або перелічення прав. Хоча це не просто проблема адміністратора, вона важливіша, оскільки тут користувачі можуть мати підвищені права. Будьте впевнені, що вони незмінні та незліченні. Крім того, переконайтесь, що всі оцінки для Авторизації проводяться на основі Довірителя.
• Федеральне підвищення прав : Коли будь-який обліковий запис отримує вибрану кількість прав, усі адміністратори та співробітник служби безпеки негайно отримують повідомлення по електронній пошті. Це гарантує, що якщо зловмисник підвищить права, які ми знаємо відразу. Ці права, як правило, обертаються навколо привілейованих прав, прав на перегляд інформації, що захищається конфіденційністю, та / або фінансової інформації (наприклад, кредитних карток).
• Видавати права економно, навіть адміністраторам : нарешті, і це може бути дещо вдосконаленим для деяких магазинів. Права на дозвіл повинні бути якомога стриманішими і повинні оточувати реальну функціональну поведінку. Типові рольові підходи (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

Коли це станеться, з’явиться поле ім’я користувача та пароль.