Тестування безпеки (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: цей злом зазвичай виконується на ноутбуці з набором операційних систем та інструментів для злому. Це тестування допомагає тестерам на проникнення та тестерам безпеки проводити оцінку вразливостей та атаки.
Методи тестування безпеки :
Доступ до програми . Будь то настільна програма або веб-сайт, безпека доступу забезпечується функцією «Керування ролями та правами». Часто це робиться неявно при описі функціональності, наприклад, у системі управління лікарнею адміністратор найменше турбується про лабораторні дослідження, оскільки його робота полягає в тому, щоб просто зареєструвати пацієнтів та призначити їх зустрічі з лікарями. Таким чином, усі меню, форми та екрани, що стосуються лабораторних тестів, не будуть доступні для ролі «реєстратора». Отже, правильна реалізація ролей та прав гарантує безпеку доступу.
Як протестувати доступ до програми: Щоб це перевірити, необхідно виконати ретельне тестування всіх ролей та прав. Тестувальник повинен створити кілька облікових записів користувачів з різними, а також кількома ролями. Потім він повинен використовувати програму за допомогою цих облікових записів і переконатися, що кожна роль має доступ тільки до своїх власних модулів, екранів, форм та меню. Якщо тестувальник виявляє конфлікт, він має упевнено зареєструвати проблему безпеки. Деякі з тестів автентифікації включають перевірку правил якості пароля, перевірку входу в систему за умовчанням, перевірку відновлення пароля, перевірку перевірки автентичності, перевірку функціональності виходу, перевірку зміни пароля, перевірку контрольного питання / відповіді і т. д. Аналогічним чином,
Як протестувати захист даних: Тестувальник повинен запросити в базі даних «паролі» облікового запису користувача, інформацію про виставлення рахунків клієнтів, інші важливі для бізнесу та конфіденційні дані та переконатися, що всі такі дані зберігаються у зашифрованій формі. Так само він повинен переконатися, що дані передаються між різними формами чи екранами лише після належного шифрування. Більше того, тестувальник повинен переконатись, що зашифровані дані належним чином розшифровані у місці призначення. Особливу увагу слід приділити різним діям «надіслати». Тестувальник повинен переконатися, що інформація, що передається між клієнтом та сервером, не відображається в адресному рядку веб-браузера у зрозумілому форматі. Якщо будь-яка з цих перевірок завершиться невдало, значить, у додатку безумовно є баги безпеки. Тестувальник також повинен перевірити правильність використання соління (salting - додавання додаткового секретного значення до кінцевого введення, наприклад пароля, що робить його більш надійним та важким для злому). Небезпечна випадковість також має бути перевірена, оскільки це свого роду вразливість. Інший спосіб перевірити захист даних – перевірити використання слабкого алгоритму. Наприклад, оскільки HTTP - це протокол відкритого тексту, якщо конфіденційні дані, такі як облікові дані користувача, передаються через HTTP, це загроза безпеки програми. Замість HTTP конфіденційні дані слід надсилати через HTTPS (захищений через SSL, тунель TLS). Однак HTTPS збільшує поверхню атаки, тому необхідно перевірити правильність конфігурації сервера та гарантувати дійсність сертифіката;
Атака грубої сили (Brute-Force Attack, атака повним перебором) переважно виконується деякими програмними інструментами. Ідея полягає в тому, що використовуючи дійсний ідентифікатор користувача, програмне забезпечення намагається підібрати пов'язаний пароль, намагаючись увійти в систему знову і знову. Простим прикладом захисту від такої атаки є призупинення облікового запису на короткий період часу, як це роблять усі поштові програми, такі як Yahoo, Gmail та Hotmail. Якщо певна кількість послідовних спроб (в основному 3) не дозволяє увійти до системи, цей обліковий запис блокується на деякий час (від 30 хвилин до 24 годин).
Вищезазначені три аспекти безпеки слід враховувати як для веб-застосунків, так і для настільних програм, тоді як наступні моменти стосуються лише веб-застосунків .
Як тестувати SQL-ін'єкцію та XSS: Тестер повинен переконатися, що максимальна довжина всіх полів введення визначена та реалізована. Він також повинен гарантувати, що задана довжина полів введення не відповідає введенню сценарію, а також введенню тега. Обидва можуть бути легко протестовані. Наприклад, якщо 20 - максимальна довжина, вказана для поля "Ім'я", а вхідний рядок "<p> thequickbrownfoxjumpsoverthelazydog" можна перевірити обидва ці обмеження. Тестувальник також повинен переконатися, що програма не підтримує методи анонімного доступу. Якщо будь-яка з цих уразливостей існує, програма знаходиться в небезпеці. В основному тестування SQL-ін'єкції може бути виконано такими п'ятьма способами:
Методи виявлення;
Стандартні техніки SQL-ін'єкцій;
Експлойти;
Точки доступу до сервісу (закриті та безпечні відкриті).
Сьогодні компанії залежать один від одного і співпрацюють один з одним, те саме стосується і додатків, особливо до веб-сайтів. У такому випадку обидва учасники повинні визначити та опублікувати кілька точок доступу один для одного. Поки що сценарій здається досить простим і зрозумілим, але для деяких веб-продуктів, таких як торгівля акціями, все не так просто і легко. Коли існує велика кількість цільової аудиторії, точки доступу повинні бути достатньо відкритими, щоб полегшити роботу всіх користувачів, достатньо пристосованими для виконання всіх запитів користувачів і безпечними, щоб впоратися з будь-якою небезпекою.
Як протестувати точки доступу до сервісу (Service Access Points): дозвольте мені пояснити це на прикладі веб-програми для торгівлі акціями; інвестор (бажаючий придбати акції) повинен мати доступ до поточних та історичних даних про ціни на акції. Це вимагає, щоб програма була достатньо відкритою. Під зручністю та безпекою я маю на увазі, що додаток повинен полегшити інвесторам можливість вільно торгувати (відповідно до закону). Вони можуть купувати або продавати 24/7 і дані транзакцій повинні бути захищені від будь-яких хакерських атак. Більше того, велика кількість користувачів буде взаємодіяти з програмою одночасно, тому програма повинна надавати достатньо точок доступу, щоб задовольнити всіх користувачів. У деяких випадках ці точки доступу можуть бути закриті для небажаних програм або людей. Це залежить від бізнес-домену програми та її користувачів, наприклад, веб-система управління офісом, що настроюється, може розпізнавати своїх користувачів на основі IP-адрес і відмовляти у встановленні з'єднання з усіма іншими системами (додатками), які не потрапляють в діапазон допустимих IP-адрес для цієї програми. Тестувальник повинен гарантувати, що весь міжмережевий та внутрішньомережевий доступ до програми здійснюється довіреними програмами, машинами (IP) та користувачами. Щоб переконатися, що відкрита точка доступу досить безпечна, тестувальник повинен спробувати отримати доступ до неї з різних машин, які мають як довірені, так і ненадійні IP-адреси. Слід випробувати різні типи транзакцій у реальному часі відразу, щоб бути впевненим у продуктивності програми. Таким чином, пропускна спроможність точок доступу програми також буде чітко відстежуватися. Тестувальник повинен переконатися, що додаток обробляє всі запити зв'язку від довірених IP-адрес та програм лише тоді, коли всі інші запити відхиляються. Так само, якщо в програмі є відкрита точка доступу, тестувальник повинен переконатися, що вона дозволяє (за потреби) завантаження даних користувачами безпечним способом. Під цим безпечним способом я маю на увазі обмеження розміру файлу, обмеження типу файлу та сканування завантаженого файлу на віруси чи інші загрози безпеці. якщо у програмі є відкрита точка доступу, тестувальник повинен переконатися, що вона дозволяє (за потреби) завантаження даних користувачами безпечним способом. Під цим безпечним способом я маю на увазі обмеження розміру файлу, обмеження типу файлу та сканування завантаженого файлу на віруси чи інші загрози безпеці. якщо у програмі є відкрита точка доступу, тестувальник повинен переконатися, що вона дозволяє (за потреби) завантаження даних користувачами безпечним способом. Під цим безпечним способом я маю на увазі обмеження розміру файлу, обмеження типу файлу та сканування завантаженого файлу на віруси чи інші загрози безпеці.
Управління сесією . Веб-сеанс - це послідовність транзакцій HTTP-запиту та відповіді, пов'язаних з одним і тим самим користувачем. Тести керування сеансом перевіряють, як керування сеансом обробляється у веб-програмі. Ви можете перевірити закінчення терміну дії сеансу після певного часу простою, завершення сеансу після максимального часу життя, завершення сеансу після виходу з системи, перевірити обсяг та тривалість сеансу cookie, перевірити, чи може один користувач мати кілька одночасних сеансів і т.д.
Обробка помилок. Тестування на обробку помилок включає:
перевірку кодів помилок, які повертаються із докладним повідомленням. Ці повідомлення не повинні містити критичної інформації, яка може бути використана для злому;
перевірку трасування стека: в основному це включає передачу в додаток деяких виняткових даних, так що повідомлення про помилку, що повертається містить трасування стека, які містять цікаву інформацію для хакерів;
Конкретні небезпечні функції. В основному, дві ризиковані функції - це платежі та завантаження файлів. Ці функції слід дуже добре протестувати. Для завантаження файлів вам необхідно в першу чергу перевірити, чи завантаження небажаних або шкідливих файлів обмежене. Для платежів вам необхідно насамперед протестувати на наявність уразливостей ін'єкцій, небезпечного криптографічного сховища, переповнення буфера, підбору пароля тощо.
Джерела:
Дод. матеріал:
Last updated