security testing
Як перевірити безпеку додатків - методи тестування безпеки веб- і настільних програм
Необхідність тестування на безпеку?
Індустрія програмного забезпечення досягла солідного визнання в цей вік. Однак протягом останнього десятиліття кібер-світ, здається, стає ще більш домінуючим та рушійною силою, яка формує нові форми майже кожного бізнесу. Веб-системи ERP, що використовуються сьогодні, є найкращим свідченням того, що ІТ революціонізували наше улюблене глобальне село.
У наші дні веб-сайти призначені не лише для реклами чи маркетингу, але вони перетворилися на потужніші інструменти для задоволення бізнес-потреб.
Інтернет-системи оплати праці, торгові центри, банківська справа, програма торгівлі акціями не тільки використовуються організаціями, але й сьогодні продаються як товари.
Це означає, що онлайн-програми завоювали довіру споживачів та користувачів щодо їхньої життєво важливої функції, яка називається БЕЗПЕКА.
Без сумніву, коефіцієнт безпеки є першочерговим значенням і для настільних додатків.
Однак, коли ми говоримо про Інтернет, значення безпеки зростає в геометричній прогресії. Якщо онлайн-система не може захистити дані транзакції, ніхто ніколи не подумає їх використовувати. Безпека - це ще не слово, що шукає її визначення, і не тонка концепція. Однак я хотів би перерахувати кілька компліментів щодо безпеки.
що з наведеного вірно для інтеграційного тесту?
Приклади недоліків безпеки програми
- Система управління студентами є небезпечною, якщо гілка «Прийом» може редагувати дані гілки «Іспит»
- ERP-система не захищена, якщо DEO (оператор введення даних) може генерувати „Звіти”
- Інтернет-торговий центр не має захисту, якщо деталі кредитної картки клієнта не зашифровані
- Спеціальне програмне забезпечення має неадекватну безпеку, якщо запит SQL отримує фактичні паролі своїх користувачів
Безпека
Зараз я представляю вам найпростіше визначення безпеки своїми словами.
'Безпека означає, що надається санкціонований доступ до захищених даних, а несанкціонований доступ обмежується' .
Отже, він має два основних аспекти; перший - це захист даних, а другий - доступ до цих даних. Більше того, незалежно від того, чи є програма настільною чи веб-мережею, безпека обертається навколо двох вищезазначених аспектів.
Давайте оглянемо аспекти безпеки як настільних програм, так і веб-програм.
Що ви дізнаєтесь:
Тестування робочого столу та веб-безпеки
Настільна програма повинна бути захищена не тільки щодо її доступу, але й щодо організації та зберігання своїх даних.
Подібним чином веб-програма вимагає, ще більше, безпеки щодо свого доступу, поряд із захистом даних. Веб-розробник повинен зробити програму несприйнятливою до SQL Injections, Brute Force Attacks та XSS (міжсайтовий сценарій). Подібним чином, якщо веб-програма забезпечує віддалені точки доступу, то вони також повинні бути захищеними.
Більше того, майте на увазі, що Brute Force Attack пов’язаний не лише з веб-додатками, а також настільне програмне забезпечення.
Сподіваюся, цієї передмови вистачає, а тепер дозвольте мені перейти до суті. Будь ласка, прийміть мої вибачення, якщо ви до цього часу думали, що читаєте про тему цієї статті. Хоча я коротко пояснив безпеку програмного забезпечення та її основні проблеми, моя тема - 'Тестування безпеки'.
Рекомендована література => Тестування безпеки веб-додатків
Зараз я поясню, як функції захисту впроваджуються в програмне забезпечення та як їх слід перевіряти. Моя увага буде зосереджена на тестах і хау тестування безпеки, а не безпеки.
Рекомендовані засоби перевірки безпеки
# 1) Net parker
Netsparker це рішення для тестування безпеки веб-додатків з можливостями автоматичного сканування та сканування для всіх типів застарілих та сучасних веб-додатків, таких як HTML5, Web 2.0 та програми для однієї сторінки. Він використовує технологію сканування на основі доказів та масштабовані скануючі агенти.
Це дає вам повну видимість, навіть якщо у вас є велика кількість активів для управління. Він має набагато більше функціональних можливостей, таких як управління командою та управління уразливістю. Його можна інтегрувати в платформи CI / CD, такі як Jenkins, TeamCity або Bamboo.
=> Спробуйте найкращий інструмент тестування безпеки Netsparker# два) Кіуван
Знайдіть та виправте вразливості у своєму коді на кожному етапі SDLC.
Кіуван відповідає найсуворішим стандартам безпеки, включаючи OWASP, CWE, SANS 25, HIPPA та ін. Інтегруйте Kiuwan у свою IDE для миттєвого зворотного зв’язку під час розробки. Kiuwan підтримує всі основні мови програмування та інтегрується з провідними інструментами DevOps.
=> Скануйте свій код безкоштовно# 3) Indusface БЕЗКОШТОВНО перевіряв шкідливий веб-сайт
Indusface був забезпечує як ручне тестування на проникнення, що постачається разом із власним автоматизованим сканером вразливостей веб-додатків, що виявляє та повідомляє про вразливості на основі 10 найкращих OWASP, а також включає перевірку репутації веб-сайту на посилання, шкідливе програмне забезпечення та перевірку зіпсованості веб-сайту під час кожного сканування.
=> Запустіть швидке сканування веб-сайту безкоштовно
=> Зв'яжіться з нами запропонувати список тут.
Список 8 найкращих методів тестування безпеки
# 1) Доступ до програми
Будь то настільна програма чи веб-сайт, безпеку доступу реалізує «Ролі та управління правами». Це часто робиться неявно, охоплюючи функціональність,
Наприклад, в системі управління лікарнею адміністратора найменше турбують лабораторні дослідження, оскільки його робота полягає в тому, щоб просто реєструвати пацієнтів і планувати їх зустрічі з лікарями.
що робити з торрент-файлами
Отже, всі меню, форми та екрани, пов’язані з лабораторними тестами, будуть недоступні Ролі «Ресепшн». Отже, належне здійснення ролей та прав гарантуватиме безпеку доступу.
Як тестувати: Для того, щоб перевірити це, слід провести ретельне тестування всіх ролей та прав.
Тестер повинен створити кілька облікових записів користувачів з різними, а також кількома ролями. Потім він повинен використовувати додаток за допомогою цих облікових записів і повинен перевірити, чи кожна роль має доступ лише до власних модулів, екранів, форм та меню. Якщо випробувач виявить будь-який конфлікт, він повинен з повною впевненістю зареєструвати проблему безпеки.
Це також можна розуміти як перевірку автентичності та авторизації, яке дуже красиво зображено на зображенні нижче:
Отже, по суті, вам потрібно перевірити „хто ти такий“ і „що ти можеш зробити“ для окремих користувачів.
Деякі з тестів автентифікації включають тест на правила якості пароля, тест на входи за замовчуванням, тест на відновлення пароля, тест-капчу, тест на вихід із системи, тест на зміну пароля, тест на безпечне запитання / відповідь тощо.
Подібним чином деякі тести авторизації включають тест на обхід шляху, тест на відсутність авторизації, тест на горизонтальні проблеми контролю доступу тощо.
# 2) Захист даних
Є три аспекти безпеки даних. Перший - це користувач може переглядати або використовувати лише ті дані, які він повинен використовувати . Це також забезпечується ролями та правами
Наприклад, TSR (представник телепродажів) компанії може переглянути дані про наявні запаси, але не може побачити, скільки сировини було придбано для виробництва.
Отже, цей аспект тестування безпеки вже пояснено вище. Другий аспект захисту даних пов'язаний з як ці дані зберігаються в БД .
Подальше читання = >> Що таке тестування безпеки баз даних
Усі конфіденційні дані повинні бути зашифровані, щоб забезпечити їх безпеку. Шифрування має бути надійним, особливо для конфіденційних даних, таких як паролі облікових записів користувачів, номери кредитних карток або інша важлива для бізнесу інформація.
Третій і останній аспект є продовженням цього другого аспекту. Відповідні заходи безпеки повинні бути прийняті, коли відбувається потік конфіденційних або важливих для бізнесу даних. Незалежно від того, чи ці дані плавають між різними модулями однієї програми або передаються різним програмам, вони повинні бути зашифровані, щоб забезпечити їх безпеку.
Як перевірити захист даних: Тестер повинен запитати в базі даних „паролі” облікового запису користувача, платіжну інформацію клієнтів, інші важливі для бізнесу та конфіденційні дані, а також перевірити, чи всі такі дані зберігаються в зашифрованому вигляді в БД.
Подібним чином він повинен перевірити, що дані передаються між різними формами або екранами лише після належного шифрування. Більше того, тестувальник повинен переконатися, що зашифровані дані правильно розшифровані в пункті призначення. Особливу увагу слід приділяти різним заходам „подати”.
Тестер повинен перевірити, що коли інформація передається між клієнтом та сервером, вона не відображається в адресному рядку веб-браузера в зрозумілому форматі. Якщо будь-яка з цих перевірок не вдається, то програма, безумовно, має недолік безпеки.
Тестер також повинен перевірити правильність використання засолу (додаючи додаткове секретне значення до кінцевого вводу, як пароль, і таким чином робить його сильнішим та важчим для злому).
Небезпечну випадковість слід також перевірити, оскільки це свого роду вразливість. Інший спосіб перевірити захист даних - перевірити слабке використання алгоритму.
Наприклад, оскільки HTTP - це прозорий текстовий протокол, якщо такі важливі дані, як облікові дані користувача, передаються через HTTP, то це загрожує безпеці додатків. Замість HTTP конфіденційні дані повинні передаватися через HTTPS (захищені через SSL, тунель TLS).
Однак HTTPS збільшує поверхню атаки, і тому його слід перевірити на належну конфігурацію сервера та забезпечити дійсність сертифіката.
# 3) Атака грубої сили
Brute Force Attack в основному здійснюється за допомогою деяких програмних засобів. Концепція полягає в тому, що за допомогою дійсного ідентифікатора користувача s oftware намагається вгадати пов'язаний пароль, намагаючись увійти знову і знову.
Простим прикладом захисту від такої атаки є призупинення дії облікового запису на короткий проміжок часу, як це роблять усі поштові програми, такі як „Yahoo”, „Gmail” та „Hotmail”. Якщо певна кількість послідовних спроб (здебільшого 3) не вдається ввійти, то цей обліковий запис заблокується на деякий час (від 30 хвилин до 24 годин).
Як перевірити атаку грубої сили: Тестувальник повинен перевірити, чи доступний якийсь механізм призупинення роботи акаунта і працює він точно. (S) Він повинен спробувати ввійти з недійсними ідентифікаторами користувачів та паролями, щоб переконатися, що програмне забезпечення блокує облікові записи, якщо постійно намагаються ввійти в систему з недійсними обліковими даними.
Якщо програма робить це, вона захищена від атаки грубої сили. В іншому випадку тестер повинен повідомити про цю вразливість системи безпеки.
Тестування на грубу силу також можна розділити на дві частини - тестування чорної скриньки та тестування сірої скриньки.
Під час тестування «чорної скриньки» виявляється та перевіряється метод автентифікації, що застосовується додатком. Крім того, тестування сірого ящика базується на частковому знанні даних пароля та облікового запису та атак компромісу пам'яті.
Клацніть тут дослідити тестування на чорну скриньку та сірий ящик разом із прикладами.
Вищезазначені три аспекти безпеки слід враховувати як для веб-програм, так і для настільних програм, тоді як наступні пункти стосуються лише веб-програм.
# 4) Ін’єкція SQL та XSS (міжсайтові сценарії)
Концептуально кажучи, тема обох спроб злому схожа, тому вони обговорюються разом. При такому підході зловмисний сценарій використовується хакерами для маніпулювання веб-сайтом .
Є кілька способів запобігти таким спробам. Для всіх полів введення веб-сайту довжини полів повинні бути визначені досить малими, щоб обмежити введення будь-якого сценарію
як почати тестування автоматизації з нуля -
Наприклад, Прізвище повинно мати довжину полів 30 замість 255. Можуть бути деякі поля введення, де необхідне введення великих даних, для таких полів слід провести належну перевірку введення перед збереженням цих даних у програмі.
Більше того, у таких полях забороняється вводити будь-які теги HTML або теги скриптів. Щоб спровокувати атаки XSS, програма повинна відкинути перенаправлення сценаріїв із невідомих або ненадійних програм.
Як тест SQL Injection та XSS: Тестер повинен забезпечити, щоб максимальна довжина всіх полів введення була визначена та реалізована. (S) Він також повинен переконатись, що визначена довжина полів введення не вміщує жодного введення сценарію, а також введення тегу. І те, і інше можна легко перевірити
Наприклад, Якщо 20 - це максимальна довжина, вказана для поля «Ім'я», а вхідний рядок «
thequickbrownfoxjumpsoverthelazydog 'може підтвердити обидва ці обмеження.
Також тестувальник повинен перевірити, що програма не підтримує анонімні методи доступу. У разі існування будь-якої з цих вразливих місць програмі загрожує небезпека.
В основному тестування ін’єкцій SQL можна здійснити за допомогою наступних п’яти способів:
- Методи виявлення
- Стандартні методики ін'єкції SQL
- Відбитки пальців у базі даних
- Технічна експлуатація
- Методи вторгнення підпису SQL-ін'єкцій
Клацніть тут детально прочитати про вищевказані способи перевірки введення SQL.
XSS - це також тип ін’єкції, який вводить шкідливий сценарій на веб-сайт. Клацніть тут глибше вивчити тестування на XSS.
# 5) Точки доступу до служби (закриті та безпечно відкриті)
Сьогодні підприємства залежать і співпрацюють один з одним, те саме добре для додатків, особливо веб-сайтів. У такому випадку обидва співавтори повинні визначити та опублікувати деякі точки доступу один для одного.
Поки що сценарій здається досить простим і зрозумілим, але для деяких веб-продуктів, таких як біржова торгівля, все не так просто і легко.
Коли існує велика кількість цільової аудиторії, точки доступу повинні бути достатньо відкритими, щоб полегшити всім користувачам, містити достатньо, щоб виконати всі запити користувачів, і достатньо захищені, щоб впоратися з будь-яким випробувальним процесом безпеки.
Як перевірити точки доступу до служби: Дозвольте пояснити це за допомогою приклад веб-додатку для біржової торгівлі; інвестор (який хоче придбати акції) повинен мати доступ до поточних та історичних даних про ціни акцій. Користувачеві слід надати можливість завантажити ці історичні дані. Це вимагає достатньої відкритості програми.
Підтримуючи та забезпечуючи безпеку, я маю на увазі, що заявка повинна сприяти інвесторам у вільній торгівлі (відповідно до законодавчих норм). Вони можуть купувати або продавати цілодобово та без вихідних, а дані транзакцій повинні бути захищені від будь-якої хакерської атаки.
Більше того, велика кількість користувачів буде взаємодіяти з додатком одночасно, тому додаток повинен забезпечувати достатньо точок доступу, щоб розважати всіх користувачів.
У деяких випадках це точки доступу можуть бути запечатані для небажаних програм або людей . Це залежить від бізнес-домену програми та її користувачів,
Наприклад, Спеціальна веб-система управління Office може розпізнавати своїх користувачів на основі IP-адрес і забороняє встановлювати зв’язок з усіма іншими системами (програмами), які не потрапляють в дійсний IP для цієї програми.
Тестер повинен переконатися, що всі міжмережний та внутрішньомережний доступ до програми - через надійні програми, машини (IP) та користувачів.
Для того, щоб перевірити, чи відкрита точка доступу є достатньо безпечною, тестувальник повинен спробувати отримати до неї доступ з різних машин, що мають як надійну, так і ненадійну IP-адресу. Різні види транзакцій у реальному часі слід випробовувати масово, щоб мати впевненість у роботі програми. Роблячи це, потужність точок доступу програми також буде чітко відстежуватися.
Тестувальник повинен переконатися, що програма розглядає всі запити на зв'язок від надійних IP-адрес та додатків лише тоді, коли всі інші запити відхиляються.
Подібним чином, якщо програма має якусь відкриту точку доступу, то тестер повинен переконатися, що вона дозволяє (якщо потрібно) завантажувати дані користувачами безпечним способом. Таким безпечним способом я маю на увазі обмеження розміру файлу, обмеження типу файлу та сканування завантаженого файлу на наявність вірусів чи інших загроз безпеці.
Це все, як тестер може перевірити безпеку програми щодо її точок доступу.
# 6) Управління сесіями
Веб-сесія - це послідовність транзакцій запиту та відповіді HTTP, пов’язаних з одним і тим же користувачем. Тести управління сеансами перевіряють, як керується сеансом у веб-програмі.
Ви можете перевірити закінчення сеансу через певний час простою, завершення сеансу після максимального терміну служби, завершення сеансу після виходу, перевірити обсяг та тривалість файлів cookie сеансу, перевірити, чи може один користувач мати кілька одночасних сеансів тощо.
# 7) Обробка помилок
Тестування на обробку помилок включає:
Перевірте наявність кодів помилок : Наприклад, тестуйте час очікування 408 запитів, 400 помилкових запитів, 404 не знайдено тощо. Щоб перевірити їх, вам потрібно зробити певні запити на сторінку, щоб ці коди помилок були повернуті.
Коди помилок повертаються з докладним повідомленням. Ці повідомлення не повинні містити жодної важливої інформації, яка може бути використана для злому
Перевірте наявність слідів стека : Це в основному включає надання деяких виняткових введень для програми, таких що повернуте повідомлення про помилку містить сліди стека, які мають цікаву інформацію для хакерів.
# 8) Специфічні ризикові функції
Головним чином є дві ризиковані функції платежі і завантаження файлів . Ці функціональні можливості слід перевірити дуже добре. Для завантаження файлів вам потрібно в першу чергу перевірити, чи не забороняється будь-яке небажане чи зловмисне завантаження файлів.
Для платежів вам потрібно в першу чергу протестувати на вразливість введення, небезпечне криптографічне сховище, переповнення буфера, вгадування пароля тощо.
=> Зв'яжіться з нами запропонувати список тут.Подальше читання:
- Тестування безпеки веб-додатків
- 30 найкращих запитань щодо інтерв’ю щодо тестування безпеки
- Різниця між SAST / DAST / IAST / RASP
- SANS Top 20 уразливостей безпеки
Рекомендована література
- Посібник із тестування безпеки веб-додатків
- Альфа-тестування та бета-тестування (повний посібник)
- Підручник з тестування сховища даних ETL (повний посібник)
- Тестування мережевої безпеки та найкращі інструменти мережевої безпеки
- Посібник для початківців для тестування на проникнення веб-додатків
- Повне керівництво з тестування перевірки складання (тестування BVT)
- Функціональне тестування проти нефункціонального тестування
- Повне керівництво з тестування на проникнення зі зразками тестових випадків