Авторизація та захист веб-ресурсів у
Надання кожному відвідувачу сайту унікального облікового запису дозволяє вам однозначно ідентифікувати будь-який з них. Ідентифікація дозволяє веб-сайту змінювати оформлення та контент залежно від переваг та інтересів відвідувачів.
Корпоративні сайти, розташовані в захищених внутрішніх мережах підприємств, можуть містити сторінки зі звітами, призначеними лише керівникам чи співробітникам певних відділів. Пересічні співробітники не повинні мати доступу до цих ресурсів.
Також сучасні веб-сайти можуть мати різні налаштування, одні з яких призначені для зручності широкого кола користувачів, в той час як інші розраховані лише на використання веб-майстрами. Авторизація дозволяє визначити, які функції сайту необхідні та достатні для кожного конкретного користувача.
Наприклад, в електронному магазині ви напевно дозволите кожному користувачеві переглядати вітрину та користуватися кошиком замовлень.
Такі функції, як замовлення товарів, коригування замовлень та відстеження доставки мають бути доступні лише зареєстрованим користувачам. І ви точно не захочете, щоб ті чи інші могли переглядати або змінювати замовлення, зроблені іншими користувачами.
Ваше завдання як веб-розробника полягає в тому, щоб захистити від несанкціонованого доступу не тільки сам сайт, а й дані, що залишаються на ньому користувачами. Порушення безпеки чужих даних може призвести до серйозних наслідків.
Як ми вже говорили, надання користувачам унікальних облікових записів дозволяє їх ідентифікувати. Механізм «розпізнавання» сайтом зареєстрованих відвідувачів називається автентифікацією.
За допомогою механізму аутентифікації миможемо підлаштувати сайт під потреби та повноваження кожного користувача, починаючи з банальної персоналізації вітання, що видається користувачеві при вході на сайт.
Аутентифікація сама по собі дозволяє розробнику використовувати багато корисних функцій і налаштувати сайт відповідно до переваг кожного конкретного користувача.
Управління доступом на основі груп та ролей
Хоча права можна призначати індивідуально кожному користувачеві сайту, управління цим процесом суттєво ускладнюється зі зростанням кількості користувачів. Будь-яка зміна в системі безпеки сайту може вимагати переналаштування прав великої кількості користувачів, що вимагає часу і може призвести до помилок.
Для вирішення цієї проблеми користувачі, які мають однакові права чи потреби, збираються до груп. Окремі права також можуть явно чи неявно групуватися так звані ролі. Ролі, своєю чергою, можуть призначатися окремим користувачам чи групам. У деяких системах «роль» та «група» є синонімами.
Новий користувач на сайті включається до будь-якої групи. Це може робити автоматично або вручну, адміністратором сайту. Таким чином, користувач отримує заздалегідь певний набір прав та обмежень.
Щоб відобразити зміну політики безпеки сайту на всіх наявних та майбутніх користувачах, адміністратору достатньо відкоригувати властивості групи.
Однак у випадку належності користувача до кількох груп або ролей у системі має бути передбачений механізм вирішення конфліктів прав. Наприклад, користувач блогу може бути включений до двох груп, одній з яких дозволено створювати пости, а інший – тільки переглядати. Яке право надавати користувачеві в результаті?
Більшість систем залишає вдії мінімальних прав або передбачає пріоритет заборон над дозволами. У такому разі наш гіпотетичний користувач не матиме права писати в блог, оскільки обмеження повноважень переважатиме над дозволом.
Хорошою практикою є поділ користувачів на групи на вид діяльності на сайті. Наприклад, наш блог може мати такі групи користувачів: Автори, Редактори, Модератори і т.д.
Захист сторінок засобами ASP.NET
Першим завданням при побудові сайту буде поділ доступу до сторінок. Я зосереджу вашу увагу на можливостях ASP.NET, хоча багато інших фреймворків і систем управління контентом мають схожі концепції, але істотно інші команди та налаштування.
При захисті сайту на ASP.NET використовуються три напрямки поділу доступу:
Захист сайту на веб-формах
Як веб-форми, так і роутинг ASP.NET використовує для захисту доступу web.config . Основа конфігурації для захисту доступу до ресурсів сайту виглядає приблизно так:
XML-елемент location визначає шлях до ресурсу, що захищається: папці, сторінці або елементу роутингу. У цьому прикладі він задає сторінку adminhome.aspx. Можна захистити вміст папки повністю, вказавши шлях до неї. Якщо атрибут path відсутній, параметри безпеки застосовуються до папки, в якій знаходиться файл web.config , з усіма її папками.
Елемент authorization визначає, хто має або не має доступу до ресурсу, що захищається. Права перевіряються послідовно, починаючи з першого і доти, доки збіг не буде знайдено. Вкладений елемент allow визначає дозвіл, а deny – заборона доступу до ресурсу для заданого користувача або ролі.
В іншому випадку перевірка продовжиться до наступного правила: ,що позбавить доступу до ресурсу всіх користувачів. Таким чином, наш приклад дає доступ до файлу лише адміністраторам. Всім іншим буде відмовлено у доступі.
Існує кілька спеціальних символів, що позначають групи, що часто використовуються. Ми вже бачили символ "*", який позначає всіх користувачів.
Символ «? » позначає анонімного (не встиг зареєструватися) користувача. Декілька груп або окремих користувачів можуть бути перераховані через кому. Користувачі та ролі можуть змішуватися в одному правилі, наприклад:
Захист MVC-сайту
Розробка сайту згідно з методологією MVC зосереджується не на файлах та папках, а на контролерах та їх діях. Відповідним чином змінюється захист. За промовчанням всі дії всіх контролерів доступні всім користувачам, як і у випадку з веб-формами. Вам доступні ті ж користувачі та ролі, але файлів web.config більше немає.
Натомість ви застосовуєте атрибут [ Authorize ] безпосередньо до контролерів та дій. Наприклад, якщо у вас є контролер, доступ до якого мають лише адміністратори, ви можете додати відповідну роль в тег. Врахуйте, що використання тегів в [ Authorize ] означає неявну заборону доступу для всіх користувачів, які не перераховані в них:
Для позначення анонімів та всіх користувачів доступні самі символи « ? » та «*». Ви можете застосовувати установки до всього контролера або окремих дій. При цьому налаштування дій матимуть більший пріоритет, ніж налаштування всього контролера:
Якщо ви не вкажете користувачів або ролей в атрибуті [ Authorize ], доступ буде дозволений всім зареєстрованим користувачам.
В ASP.NET 4 було додано атрибут [ AllowAnonymous ], який дозволив дозволити анонімномукористувачеві доступ до окремих дій захищеного контролера.
Керування контентом залежно від ролі
Обмеживши доступ до сторінок і контролерів, наступним кроком ви повинні переконатися в тому, що доступ до серверного коду здійснюється правильно. Деякі об'єкти легко захистити, тому що до них повинні мати доступ лише користувачі з певною роллю, і цей доступ – повний.
У більш складних випадках доступ до однієї і тієї ж сторінки повинен здійснюватися користувачами з різними ролями, але при цьому представлення сторінки для них має бути різним. Крім обмеження доступу до критичних об'єктів, переконайтеся, що користувачі не бачать елементів керування та посилань, якими не можуть і не повинні скористатися.
Код, який виконує сервер на сторінці, доступній декільком ролям, повинен завжди перевіряти права користувача та засновувати свої дії на результаті цієї перевірки.
При програмній перевірці доступу спочатку припускайте найменші права, а потім доповнюйте код перевірками і виведенням елементів і посилань, які потрібно убезпечити.
Завжди перевіряйте, наскільки безпечним є код, що обробляє GET-запити. Наприклад, ваш веб-магазин має запит для видалення замовлення:
Тепер, уявіть хакера, який видаляє всі замовлення перебором параметра order. Чи перевіряється належність замовлення користувачеві у відповідному обробнику?
В іншому випадку відсутність перевірки в чомусь на кшталт:
Аспекти безпеки сесій користувача
У цьому прикладі час життя сесії становитиме 30 хвилин. Атрибут slidingExpiration визначає, чи скидає лічильник закінчення сесії надходження запиту від користувача. Якщо встановити даному атрибуту значення false, користувачеві доведетьсяздійснювати вхід кожні 30 хвилин навіть під час активної роботи з сайтом.
Також необхідно враховувати можливість крадіжки сесії. Більшість веб-фреймворків зберігають ідентифікатор сесії в маленькому шматочку текстових даних, званому кукою або печінкою (cookie), у браузері користувача.
Якщо кука ніяк не захищена, її може використовувати зловмисник, перехопивши трафік легітимного користувача та представившись системі цим користувачем.
Фреймворк ASP.NET дозволяє посилити захист сайту, встановивши атрибут форми входу на сайт requireSSL="true" . Для більшої безпеки рекомендується також застосувати тег у конфігурації сайту.
Висновок
Використання одного і того ж веб-сайту відвідувачами з різними потребами та різним рівнем відповідальності вимагає використання різних методів запобігання несанкціонованому доступу до даних та функцій. Ви можете ідентифікувати користувача та застосувати до нього необхідні установки безпеки на вашому сайті.
Головне – переконатись, що критичними функціями вашого сайту зможуть скористатися лише потрібні користувачі.
На сторінках, що використовуються користувачами з різним рівнем привілеїв, ви повинні забезпечити показ тільки тих даних, які можуть використовуватися користувачем у конкретній ролі.
А оскільки від ідентифікації користувача залежить рівень його прав у вашій системі, ви маєте запобігти ситуації, коли відвідувач зможе представитися на вашому сайті кимось іншим.
Комбінація цих заходів дозволить вам створити безпечний та захищений веб-сайт.