Аудит безпеки сайту
Ми щодня стикаємося з наслідками зламів: витік баз даних, дефейс сайту, крадіжка платіжних даних. SQL-ін'єкція в параметрі id, XSS через поле відгуку, підбір пароля до адмінки — це не теорія, а реальні прогалини, які ми закриваємо. За даними OWASP, 43% вразливостей у веб-додатках пов'язані з SQL-ін'єкціями, а 22% — з XSS. Наш аудит безпеки поєднує автоматичне сканування та ручний пентест. Результат — пріоритизований список вразливостей з конкретними кроками щодо їх усунення. Оцінюємо проєкт за 1 день — зв'яжіться для консультації. За понад 7 років роботи ми провели понад 50 аудитів, кожен з яких запобігав потенційним загрозам. Вартість аудиту — від 800$ для невеликих проектів.
OWASP Top 10 визначає 10 найкритичніших загроз для веб-додатків.
OWASP Top 10: що шукаємо
Кожен додаток ми перевіряємо за методологією OWASP. Основні категорії вразливостей:
- A01: Broken Access Control — чи можна отримати доступ до чужих даних? Підміна параметрів, обхід прав.
- A02: Cryptographic Failures — зберігання паролів у відкритому вигляді, відсутність HTTPS, слабкі алгоритми.
- A03: Injection — SQL, NoSQL, OS Command. Тестуємо всі вхідні точки додатку.
- A04: Insecure Design — логічні помилки в бізнес-процесах, наприклад, скидання пароля без підтвердження.
- A05: Security Misconfiguration — відкриті директорії, дефолтні обліковки, зайві сервіси.
- A07: Identification and Authentication Failures — слабка аутентифікація, відсутність rate limiting, передбачувані токени.
85% проєктів містять хоча б одну XSS-вразливість, а 70% — проблеми з аутентифікацією (за даними нашої статистики).
Чому автоматичні сканери пропускають 20% вразливостей?
Автоматичні інструменти, такі як OWASP ZAP, Nikto, Nuclei, чудово знаходять відомі CVE та типові ін'єкції. Але вони безсилі проти логічних помилок. Наприклад, IDOR — коли користувач отримує доступ до чужих даних, просто підмінивши ID в URL. Або бізнес-вразливість: чи можна оформити замовлення з від'ємною сумою? Сканер цього не зрозуміє. Тому ми завжди доповнюємо автоматику ручним тестуванням. Комбінований підхід у 2-3 рази ефективніший за простий автоматичний аудит.
Ось приклад швидкої автоматичної перевірки:
# Комплексне сканування OWASP ZAP, Nikto, Nuclei docker run -v $(pwd):/zap/wrk/:rw ghcr.io/zaproxy/zaproxy:stable zap-baseline.py -t https://mysite.com -r zap-report.html -a nikto -h https://mysite.com -output nikto-report.html -Format htm nuclei -u https://mysite.com -severity critical,high -o nuclei-results.txt Як ми шукаємо SQL-ін'єкції та XSS вручну?
Ручне тестування починається з аналізу всіх вхідних точок. Для SQL-ін'єкцій ми перевіряємо параметри запитів, POST-дані, заголовки. Використовуємо символ ' для провокації помилки, а потім намагаємося витягти дані. Приклад перевірки:
GET /users?id=1' # Якщо сервер повертає 500 — вразливість GET /search?q=1' OR '1'='1 Для XSS ми пробуємо впровадити скрипти в поля форм, URL-параметри та заголовки:
<script>alert(1)</script> "><img src=x onerror=alert(1)> javascript:alert(1) Кожна знахідка документується з PoC (proof of concept) та CVSS-оцінкою.
Як ми тестуємо аутентифікацію та управління сесіями?
Ми перевіряємо стійкість паролів, наявність rate limiting на login, валідність токенів та захист від перебору. Наприклад, якщо сервер не блокує акаунт після 5 невдалих спроб — це вразливість. Також тестуємо механізм скидання пароля: чи можна перехопити посилання або підмінити токен.
Що входить в аудит безпеки сайту
Процес аудиту включає 6 кроків:
- Аналіз архітектури — вивчаємо схему потоків даних, точки входу, стек.
- Автоматичне сканування — використовуємо ZAP, Nuclei, Nikto, sqlmap.
- Ручне тестування — SQLi, XSS, IDOR, аутентифікація, business logic.
- Перевірка Security Headers — CSP, HSTS, X-Frame-Options, Permissions-Policy.
- Підготовка звіту — пріоритизований список вразливостей.
- Повторна перевірка — після виправлень перевіряємо усунення.
Порівняння методів: ручний та автоматичний
| Метод | Покриття | Приклади знахідок | Час |
|---|---|---|---|
| Автоматичний | 80% відомих CVE | SQLi, XSS, відкриті порти | Години |
| Ручний | +15% унікальних вразливостей | IDOR, бізнес-логіка, bypass аутентифікації | Дні |
| Комбінований | 95% типових вразливостей | Повний спектр | 3–7 днів |
Security Headers: чеклист налаштувань
Неправильна конфігурація заголовків безпеки — одна з найпоширеніших проблем. Ось еталонні налаштування для Nginx:
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-{RANDOM}'; style-src 'self'; img-src 'self' data: https://cdn.mysite.com; frame-ancestors 'none';" always; add_header X-Frame-Options "DENY" always; add_header X-Content-Type-Options "nosniff" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; Ми перевіряємо заголовки за допомогою Mozilla Observatory, а також аналізуємо CSP на предмет можливих bypass-векторів.
Приклад звіту: критична вразливість
У фінальному звіті кожна знахідка має пріоритет. Приклад:
### CVE-001: SQL Injection в /api/search - CVSS: 9.8 (Critical) - Вектор: Параметр `q` не санітується, можливе вилучення всієї БД - PoC: `GET /api/search?q=1' UNION SELECT table_name FROM information_schema.tables--` - Виправлення: Параметризовані запити Типові помилки безпеки, які ми часто зустрічаємо
- Використання застарілих бібліотек з відомими CVE.
- Зберігання паролів у відкритому вигляді або з MD5.
- Відсутність CSP та HSTS.
- Надмірна довіра до користувацького вводу (SQLi, XSS).
- Відкриті панелі керування (PHPMyAdmin, Jenkins) з дефолтними обліковками.
Строки та як замовити
Стандартний аудит середнього веб-додатку займає 3–7 робочих днів. Для мікросервісних архітектур та highload-проєктів термін збільшується. Ми гарантуємо конфіденційність і підписуємо NDA. Оцінимо ваш проєкт безкоштовно за 1 день — зв'яжіться для консультації. Замовте аудит під ключ і отримайте детальний звіт із рекомендаціями щодо виправлення. Наші клієнти економлять до 40% на виправленні вразливостей завдяки ранньому виявленню.
При перевірці ми спираємося на OWASP Testing Guide та використовуємо Mozilla Observatory для оцінки заголовків. Отримайте консультацію вже сьогодні — зв'яжіться з нами для обговорення вашого проєкту.