Основи аналізу вразливостей та етичний хакінг

Проф. Журавка А.В.

лабораторна робота 1

Основи аналізу вразливостей та етичний хакінг моделі безпеки ASP.NET

•Основні поняття моделі безпеки ASP.NET

•рівні безпеки

Основні поняття моделі безпеки ASP.NET

•Хоча платформа безпеки, запропонована .NET і ASP.NET, досить потужна, все ж варто постійно мати на увазі базові принципи і правильно застосовувати ці кошти в потрібний момент. У дуже багатьох проектах турбота про безпеку проявляється із запізненням; архітектори і розробники не думають про неї на ранніх стадіях проекту. Але якщо не взяти до уваги безпеку з самого початку, а саме - при розробці проектного рішення і архітектури додатку, - то як можна буде правильно і вчасно скористатися засобами захисту, пропонованими .NETFramework?

•Таким чином, важливо враховувати питання забезпечення безпеки з перших кроків роботи. Це єдиний спосіб прийняття правильних рішень, що стосуються захисту, в процесі розробки архітектури та проектного рішення.

Основні поняття моделі безпеки ASP.NET

•Безпека- найважливіша частина веб-додатків, і вона повинна прийматися до уваги з першого етапу процесу розробки. По суті, безпека - це все, що стосується захисту вашого майна від неавторизованих дій, І для її забезпечення використовується кілька механізмів, включаючи ідентифікацію користувачів, видачу або відгук прав доступу до важливих ресурсів, а також захист інформації, що зберігається на сервері і передається по мережі . У всіх цих випадках необхідна якась фундаментальна платформа, що забезпечує базову функціональність безпеки. ASP.NET задовольняє цю потребу завдяки вбудованим засобам, які можна застосовувати для забезпечення захисту своїх додатків.

•Платформа безпеки ASP.NET включає класи для аутентифікації і авторизації користувачів, а також для поводження з аутентифицироваться користувачами в додатках. Вона також включає високорівневу модель для управління користувачами і ролями, якпрограмно, Так і за допомогою інструментів адміністрування. Більш того, платформа .NETFramework сама по собі надає набір базових класів для забезпечення конфіденційності і цілісності через шифрування та цифрові підписи.

Поняття потенційних загроз

•Створення безпечного архітектури та проектного рішення вимагає глибокого розуміння середовища додатки. Побудувати безпечне програмне забезпечення не вдасться, якщо не відомо, хто має доступ до додатка і де знаходяться вразливі місця для атак. Таким чином, найбільш важливий фактор для створення безпечної програмної архітектури та проектного рішення полягає в хорошому розумінні таких факторів середовища, як користувачі, точки входу і потенційні загрози з точками для атаки.

•Саме тому моделювання загроз стає все більш важливим в сучасному процесі розробки програмного забезпечення. моделювання загроз- це структурований спосіб аналізу середовища додатки з точки зору можливих небезпек, класифікація загроз і рішення щодо прийомів їх пом'якшення. При такому підході рішення щодо технологій безпеки (таких як аутентифікація і SSL-шифрування) завжди має дійсне підставу - потенційну загрозу.

•Однак моделювання загроз важливо з ще однієї причини. Як ви, можливо, знаєте, не всі потенційні загрози можуть бути пом'якшені застосуванням технологій захисту, такими як аутентифікація і авторизація. Іншими словами, деякі з них взагалі неможливо вирішити технічно.

•Наприклад, банківське онлайнове рішення може використовувати SSL для захисту трафіку веб-сайту. Але як користувачі можуть знати, що вони дійсно використовують банківську сторінку, а не хакерський підроблений веб-сайт? Добре, єдиний спосіб переконатися в цьому - перевірити сертифікат, який використовується для установки каналу SSL. Але користувачі повинні бути попереджені про це, а тому ви повинні якимось чином їх інформувати. Тому "техніка пом'якшення" загроз - це не тільки технології захисту. Вона включає вимогу того, щоб всі користувачі знали, як перевірити сертифікат. (Звичайно, ви не можете змусити їх це робити, але якщо система спроектована відповідним чином, все ж можна стимулювати до цього більшість з них.) Моделювання загроз - метод аналізу, що допомагає виявити обставини на кшталт цих,

Правила безпечного кодування

•Ніколи не довіряйте призначеному для користувача введення даних

•Ні коли не використовуйте конкатенацію рядків для формування операторів SQL

•Ніколи не виводьте дані, введені користувачем, на веб-сторінку перед їх перевіркою та кодуванням

•Не ставте важливі дані в прихованих полях веб-сторінки

•Ніколи не зберігайте важливі дані в стані уявлення

•захищайте свої cookie-набори

•застосовуйте SSL/TLS

конвеєр безпеки

Модель рівнів передбачає, що безпечне додаток завжди має більше механізмів захисту, ніж це необхідно. Кожен з цих механізмів реалізований у вигляді рівня, що відповідає за перевірку деяких умов захисту. Якщо один з таких рівнів не спрацює, то атакуючий зіткнеться з наступним рівнем в конвеєрі. І чим більше рівнів безпеки мається на вашому додатку, тим важче доводиться зловмисникові. Насправді ця модель відповідає ключовому принципу створення безпечних додатків: забезпечувати наскільки можливо високу ступінь захисту і створювати максимум проблем порушників.

рівні безпеки

•В основному для більшої частини веб-додатків основні завдання для реалізації захисту (крім ідентифікованих під час моделювання загроз) завжди одні й ті ж:

•аутентифікація

•авторизація

•конфіденційність

•цілісність

аутентифікація

•У додатках ASP.NET аутентифікація реалізується однією з наступних можливих аутентифицирующей систем:

•аутентифікація Windows;

•аутентифікація за допомогою форм;

•спеціальний процес аутентифікації.

запозичення прав

•Запозичення прав (impersonation)- це процес виконання коду в контексті (або від імені) іншого користувача. За замовчуванням код ASP.NET виконується від імені фіксованою, специфічною для конкретної машини, призначеної для користувача облікового запису (зазвичайNetwork Service в IIS ). Щоб виконати код із застосуванням іншої ідентичності, можна скористатися вбудованими в ASP.NET можливостями запозичення прав. Можна застосувати визначену призначену для користувача обліковий запис або припустити призначену для користувача ідентичність, якщо цей користувач уже був аутентифікований за допомогою облікового запису Windows.