Тестування безпеки (Security and Access Control testing)
Це тип тестування програмного забезпечення, який виявляє вразливості, загрози та ризики. Метою тестів безпеки є виявлення всіх можливих лазівок та слабких місць у ПЗ, які можуть призвести до втрати інформації, доходів, репутації компанії, співробітників чи клієнтів. Загальна стратегія безпеки ґрунтується на трьох основних принципах:
Конфіденційність - приховування певних ресурсів чи інформації;
Цілісність – ресурс може бути змінений тільки відповідно до повноважень користувача;
Доступність - ресурси мають бути доступні лише авторизованому користувачеві, внутрішньому об'єкту чи пристрою;
Тестування безпеки зазвичай виконує окремий фахівець із безпеки. Під час тестування безпеки випробувач грає роль хакера. Йому дозволено все:
спроби дізнатися пароль за допомогою зовнішніх засобів;
атака системи за допомогою спеціальних утиліт, що аналізують захист;
перевантаження системи (у надії, що вона відмовиться обслуговувати інших клієнтів);
цілеспрямоване введення помилок, сподіваючись проникнути в систему в ході відновлення;
перегляд несекретних даних, сподіваючись знайти ключ для входу в систему;
За необмеженого часу та ресурсів хороше тестування безпеки зламає будь-яку систему. Завдання проектувальника системи - зробити ціну проникнення вищою, ніж ціна одержуваної результаті інформації.
Типи тестування безпеки :
Сканування вразливостей/оцінка захищеності (Vulnerability Scanning) виконується за допомогою автоматизованого програмного забезпечення для сканування системи на наявність відомих сигнатур уразливостей;
Сканування безпеки (Security Scanning) включає виявлення слабких сторін мережі і системи, а потім надає рішення для зниження цих ризиків. Це сканування може бути виконане як вручну, і автоматизовано;
Тестування на проникнення (Penetration testing) імітує атаку зловмисника. Це тестування включає аналіз конкретної системи для перевірки потенційних уразливостей під час спроби зовнішнього злому;
Оцінка ризиків (Risk Assessment) включає аналіз ризиків безпеки, що спостерігаються в організації. Ризики класифікуються як Низькі, Середні та Високі. Це тестування рекомендує заходи щодо зниження ризику;
Аудит безпеки (Security Auditing) – внутрішня перевірка додатків та операційних систем на наявність уразливостей. Аудит може бути виконаний шляхом рядкової перевірки коду;
Етичний зламування (Ethical hacking) - відбувається з метою виявлення проблем безпеки в системі. Це робиться White Hat хакерами - це спеціалісти з безпеки, які використовує свої навички законним способом для допомоги у виявленні уразливостей системи, на відміну від Black Hat (злочинців);
Оцінка стану (Posture Assessment) поєднує сканування безпеки, етичний зламування та оцінки ризиків, щоб показати загальний стан безпеки організації;
SDLC фаза
Security Processes
Requirements
Аналіз безпеки для вимог та перевірка випадків зловживання/неправильного використання
Design
Аналіз ризиків безпеки для проектування. Розробка плану тестування з урахуванням тестування безпеки
Coding and Unit testing
Статичне та динамічне тестування безпеки та тестування білої скриньки
Integration testing
Тестування чорної скриньки
System testing
Тестування чорної скриньки та сканування вразливостей
Implementation
Тестування на проникнення, сканування вразливостей
Support
Аналіз впливу патчів
Тестування безпеки може виконуватися методом будь-якої скриньки, а також Tiger Box: цей злом зазвичай виконується на ноутбуці з набором операційних систем та інструментів для злому. Це тестування допомагає тестерам на проникнення та тестерам безпеки проводити оцінку вразливостей та атаки.
Методи тестування безпеки :
Доступ до програми . Будь то настільна програма або веб-сайт, безпека доступу забезпечується функцією «Керування ролями та правами». Часто це робиться неявно при описі функціональності, наприклад, у системі управління лікарнею адміністратор найменше турбується про лабораторні дослідження, оскільки його робота полягає в тому, щоб просто зареєструвати пацієнтів та призначити їх зустрічі з лікарями. Таким чином, усі меню, форми та екрани, що стосуються лабораторних тестів, не будуть доступні для ролі «реєстратора». Отже, правильна реалізація ролей та прав гарантує безпеку доступу.
Як протестувати доступ до програми: Щоб це перевірити, необхідно виконати ретельне тестування всіх ролей та прав. Тестувальник повинен створити кілька облікових записів користувачів з різними, а також кількома ролями. Потім він повинен використовувати програму за допомогою цих облікових записів і переконатися, що кожна роль має доступ тільки до своїх власних модулів, екранів, форм та меню. Якщо тестувальник виявляє конфлікт, він має упевнено зареєструвати проблему безпеки. Деякі з тестів автентифікації включають перевірку правил якості пароля, перевірку входу в систему за умовчанням, перевірку відновлення пароля, перевірку перевірки автентичності, перевірку функціональності виходу, перевірку зміни пароля, перевірку контрольного питання / відповіді і т. д. Аналогічним чином,
Захист даних . Є три аспекти безпеки даних. По-перше, користувач може переглядати або використовувати лише дані, які він повинен використовувати. Це також забезпечується ролями та правами. Наприклад, TSR (представник по телефону) компанії може переглядати дані про наявні запаси, але не може бачити, скільки сировини було закуплено для виробництва. Отже, цей аспект тестування безпеки вже пояснено вище. Другий аспект захисту даних пов'язаний з тим, як ці дані зберігаються у БД. Усі конфіденційні дані мають бути зашифровані, щоб зробити їх безпечними. Шифрування має бути надійним, особливо для конфіденційних даних, таких як паролі облікових записів користувачів, номери кредитних карток або іншої критично важливої для бізнесу інформації. Третій та останній аспект є продовженням цього другого аспекту. При передачі конфіденційних або важливих для бізнесу даних необхідно вжити належних заходів безпеки. Незалежно від того, чи переміщуються ці дані між різними модулями однієї й тієї ж програми або передаються в різні програми, вони повинні бути зашифровані для забезпечення безпеки.
Як протестувати захист даних: Тестувальник повинен запросити в базі даних «паролі» облікового запису користувача, інформацію про виставлення рахунків клієнтів, інші важливі для бізнесу та конфіденційні дані та переконатися, що всі такі дані зберігаються у зашифрованій формі. Так само він повинен переконатися, що дані передаються між різними формами чи екранами лише після належного шифрування. Більше того, тестувальник повинен переконатись, що зашифровані дані належним чином розшифровані у місці призначення. Особливу увагу слід приділити різним діям «надіслати». Тестувальник повинен переконатися, що інформація, що передається між клієнтом та сервером, не відображається в адресному рядку веб-браузера у зрозумілому форматі. Якщо будь-яка з цих перевірок завершиться невдало, значить, у додатку безумовно є баги безпеки. Тестувальник також повинен перевірити правильність використання соління (salting - додавання додаткового секретного значення до кінцевого введення, наприклад пароля, що робить його більш надійним та важким для злому). Небезпечна випадковість також має бути перевірена, оскільки це свого роду вразливість. Інший спосіб перевірити захист даних – перевірити використання слабкого алгоритму. Наприклад, оскільки HTTP - це протокол відкритого тексту, якщо конфіденційні дані, такі як облікові дані користувача, передаються через HTTP, це загроза безпеки програми. Замість HTTP конфіденційні дані слід надсилати через HTTPS (захищений через SSL, тунель TLS). Однак HTTPS збільшує поверхню атаки, тому необхідно перевірити правильність конфігурації сервера та гарантувати дійсність сертифіката;
Атака грубої сили (Brute-Force Attack, атака повним перебором) переважно виконується деякими програмними інструментами. Ідея полягає в тому, що використовуючи дійсний ідентифікатор користувача, програмне забезпечення намагається підібрати пов'язаний пароль, намагаючись увійти в систему знову і знову. Простим прикладом захисту від такої атаки є призупинення облікового запису на короткий період часу, як це роблять усі поштові програми, такі як Yahoo, Gmail та Hotmail. Якщо певна кількість послідовних спроб (в основному 3) не дозволяє увійти до системи, цей обліковий запис блокується на деякий час (від 30 хвилин до 24 годин).
Як протестувати атаку грубої сили: Тестувальник повинен переконатися, що якийсь механізм блокування облікового запису є доступним і працює правильно. Він повинен спробувати увійти в систему з неприпустимими ідентифікаторами користувача та паролями, як альтернативу, щоб переконатися, що програмне забезпечення блокує облікові записи, якщо робляться постійні спроби входу з неприпустимими обліковими даними. Якщо програма робить це, вона захищена від атаки методом перебору. В іншому випадку тестувальник повинен повідомити про цю вразливість системи безпеки. Тестування перебором також можна розділити на дві частини - тестування чорної скриньки та тестування сірої скриньки. При тестуванні «чорної скриньки» метод аутентифікації, що використовується додатком, виявляється та тестується.докладніше ).
Вищезазначені три аспекти безпеки слід враховувати як для веб-застосунків, так і для настільних програм, тоді як наступні моменти стосуються лише веб-застосунків .
SQL-ін'єкції та XSS(Міжсайтовий скриптинг). З концептуальної точки зору теми обох спроб злому схожі, тому вони обговорюються разом. У цьому підході шкідливий сценарій використовується хакерами для маніпулювання веб-сайтом. Є кілька способів застрахуватись від таких спроб. Для всіх полів введення веб-сайту довжини полів мають бути достатньо малими, щоб обмежити введення будь-якого скрипту. Наприклад, поле «Прізвище» повинно мати довжину поля 30 замість 255. Можуть бути деякі поля введення, які потребують введення великих даних, для таких полів необхідно виконати правильну перевірку введення до збереження цих даних у додатку. Більше того, у таких полях повинні бути заборонені будь-які HTML-теги або введення тегів скрипту. Щоб спровокувати XSS-атаки, програма повинна відхиляти перенаправлення скриптів від невідомих або ненадійних програм.
Як тестувати SQL-ін'єкцію та XSS: Тестер повинен переконатися, що максимальна довжина всіх полів введення визначена та реалізована. Він також повинен гарантувати, що задана довжина полів введення не відповідає введенню сценарію, а також введенню тега. Обидва можуть бути легко протестовані. Наприклад, якщо 20 - максимальна довжина, вказана для поля "Ім'я", а вхідний рядок "<p> thequickbrownfoxjumpsoverthelazydog" можна перевірити обидва ці обмеження. Тестувальник також повинен переконатися, що програма не підтримує методи анонімного доступу. Якщо будь-яка з цих уразливостей існує, програма знаходиться в небезпеці. В основному тестування SQL-ін'єкції може бути виконано такими п'ятьма способами:
Методи виявлення;
Стандартні техніки SQL-ін'єкцій;
Експлойти;
Методи впровадження у сигнатуру SQL-ін'єкції (SQL Injection Signature Invasion Techniques);
Точки доступу до сервісу (закриті та безпечні відкриті).
Сьогодні компанії залежать один від одного і співпрацюють один з одним, те саме стосується і додатків, особливо до веб-сайтів. У такому випадку обидва учасники повинні визначити та опублікувати кілька точок доступу один для одного. Поки що сценарій здається досить простим і зрозумілим, але для деяких веб-продуктів, таких як торгівля акціями, все не так просто і легко. Коли існує велика кількість цільової аудиторії, точки доступу повинні бути достатньо відкритими, щоб полегшити роботу всіх користувачів, достатньо пристосованими для виконання всіх запитів користувачів і безпечними, щоб впоратися з будь-якою небезпекою.
Як протестувати точки доступу до сервісу (Service Access Points): дозвольте мені пояснити це на прикладі веб-програми для торгівлі акціями; інвестор (бажаючий придбати акції) повинен мати доступ до поточних та історичних даних про ціни на акції. Це вимагає, щоб програма була достатньо відкритою. Під зручністю та безпекою я маю на увазі, що додаток повинен полегшити інвесторам можливість вільно торгувати (відповідно до закону). Вони можуть купувати або продавати 24/7 і дані транзакцій повинні бути захищені від будь-яких хакерських атак. Більше того, велика кількість користувачів буде взаємодіяти з програмою одночасно, тому програма повинна надавати достатньо точок доступу, щоб задовольнити всіх користувачів. У деяких випадках ці точки доступу можуть бути закриті для небажаних програм або людей. Це залежить від бізнес-домену програми та її користувачів, наприклад, веб-система управління офісом, що настроюється, може розпізнавати своїх користувачів на основі IP-адрес і відмовляти у встановленні з'єднання з усіма іншими системами (додатками), які не потрапляють в діапазон допустимих IP-адрес для цієї програми. Тестувальник повинен гарантувати, що весь міжмережевий та внутрішньомережевий доступ до програми здійснюється довіреними програмами, машинами (IP) та користувачами. Щоб переконатися, що відкрита точка доступу досить безпечна, тестувальник повинен спробувати отримати доступ до неї з різних машин, які мають як довірені, так і ненадійні IP-адреси. Слід випробувати різні типи транзакцій у реальному часі відразу, щоб бути впевненим у продуктивності програми. Таким чином, пропускна спроможність точок доступу програми також буде чітко відстежуватися. Тестувальник повинен переконатися, що додаток обробляє всі запити зв'язку від довірених IP-адрес та програм лише тоді, коли всі інші запити відхиляються. Так само, якщо в програмі є відкрита точка доступу, тестувальник повинен переконатися, що вона дозволяє (за потреби) завантаження даних користувачами безпечним способом. Під цим безпечним способом я маю на увазі обмеження розміру файлу, обмеження типу файлу та сканування завантаженого файлу на віруси чи інші загрози безпеці. якщо у програмі є відкрита точка доступу, тестувальник повинен переконатися, що вона дозволяє (за потреби) завантаження даних користувачами безпечним способом. Під цим безпечним способом я маю на увазі обмеження розміру файлу, обмеження типу файлу та сканування завантаженого файлу на віруси чи інші загрози безпеці. якщо у програмі є відкрита точка доступу, тестувальник повинен переконатися, що вона дозволяє (за потреби) завантаження даних користувачами безпечним способом. Під цим безпечним способом я маю на увазі обмеження розміру файлу, обмеження типу файлу та сканування завантаженого файлу на віруси чи інші загрози безпеці.
Управління сесією . Веб-сеанс - це послідовність транзакцій HTTP-запиту та відповіді, пов'язаних з одним і тим самим користувачем. Тести керування сеансом перевіряють, як керування сеансом обробляється у веб-програмі. Ви можете перевірити закінчення терміну дії сеансу після певного часу простою, завершення сеансу після максимального часу життя, завершення сеансу після виходу з системи, перевірити обсяг та тривалість сеансу cookie, перевірити, чи може один користувач мати кілька одночасних сеансів і т.д.
Обробка помилок. Тестування на обробку помилок включає:
перевірку кодів помилок, які повертаються із докладним повідомленням. Ці повідомлення не повинні містити критичної інформації, яка може бути використана для злому;
перевірку трасування стека: в основному це включає передачу в додаток деяких виняткових даних, так що повідомлення про помилку, що повертається містить трасування стека, які містять цікаву інформацію для хакерів;
Конкретні небезпечні функції. В основному, дві ризиковані функції - це платежі та завантаження файлів. Ці функції слід дуже добре протестувати. Для завантаження файлів вам необхідно в першу чергу перевірити, чи завантаження небажаних або шкідливих файлів обмежене. Для платежів вам необхідно насамперед протестувати на наявність уразливостей ін'єкцій, небезпечного криптографічного сховища, переповнення буфера, підбору пароля тощо.
Джерела:
Дод. матеріал:
Last updated