Экспертный аудит безопасности Joomla: полный анализ и устранение

Сайт на Joomla может внезапно перестать работать из-за уязвимости. Или вы собираетесь запустить проект и хотите убедиться, что он защищен от взлома? Joomla — одна из самых популярных CMS, но её расширения и кастомные компоненты часто содержат уязвимости. По данным OWASP, около 70% уязвимостей приходится на сторонние расширения. Недавно клиент обратился с жалобой на медленную работу сайта — оказалось, что кастомный компонент имел SQL-инъекцию, через которую злоумышленники выгружали базу данных. После аудита мы закрыли 12 уязвимостей, и сайт стал работать в 3 раза быстрее. Наш аудит безопасности выявляет проблемы до того, как ими воспользуются злоумышленники. За годы работы мы проверили более 50 проектов, и типичные проблемы повторяются: SQL-инъекции в кастомных запросах, XSS в формах, устаревшие версии PHP (например, 5.x), права доступа 777 и отсутствие заголовков безопасности. Мы сочетаем автоматические сканеры и ручной анализ кода, чтобы не пропустить ни одной уязвимости. В среднем каждый проект содержит 5–10 уязвимостей, половина из которых критического уровня. Предотвращение одной утечки данных может сэкономить миллионы рублей на восстановлении репутации и штрафах.

Типичные уязвимости

Чаще всего мы находим SQL-инъекции в кастомных компонентах, XSS в расширениях, устаревшие версии ядра, неправильные права доступа, слабую конфигурацию сервера и отсутствие двухфакторной аутентификации. Каждая из этих проблем может привести к полной компрометации сайта. Например, в одном проекте мы обнаружили уязвимость, которая позволяла злоумышленникам получить доступ к базе данных пользователей всего за 2 часа. После закрытия риска клиент избежал утечки персональных данных.

Как мы проводим аудит?

Мы сочетаем инструментальную проверку и экспертный анализ. Автоматические сканеры дают базу, а ручная проверка кода находит логические ошибки, которые не ловит ни один сканер.

Автоматизированное сканирование

# Joomscan — специализированный сканер
perl joomscan.pl -u https://target.example

# OWASP ZAP пассивное сканирование
zap-cli quick-scan --self-contained --spider https://target.example

Эти инструменты проверяют известные уязвимости ядра и популярных расширений, тестируют заголовки безопасности и выявляют слабые места в конфигурации.

Проверка конфигурации

// configuration.php — обязательные параметры
public $debug = '0';
public $error_reporting = 'none';
public $force_ssl = '2';
public $cookie_httponly = '1';
public $cookie_secure = '1';
public $lifetime = '15';
public $session_handler = 'database';

Также проверяем права доступа:

find /var/www/html -type f -name "*.php" -perm /o+w
find /var/www/html/images -name "*.php"

Наличие PHP-файлов в папке загрузок — явный признак взлома.

Анализ HTTP-заголовков

add_header X-Content-Type-Options "nosniff";
add_header X-Frame-Options "SAMEORIGIN";
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'";
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

Эти заголовки обязательны для защиты от XSS, кликджекинга и перехвата трафика.

Проверка кастомного кода

# SQL Injection в кастомных компонентах
grep -r "\$_GET\|\$_POST\|\$_REQUEST" administrator/components/com_custom/
grep -r "->query\|->loadResult" administrator/components/com_custom/ | grep -v "quoteName\|quote("

Почему важен ручной анализ кода?

Автоматические сканеры отлично находят известные уязвимости, но часто пропускают бизнес-логические ошибки. Например, недостаточную проверку прав доступа в кастомных компонентах или некорректную обработку сессий. Ручной анализ кода позволяет выявить в 2–3 раза больше проблем, что делает наш аудит значительно глубже стандартного сканирования. Только так можно гарантировать, что ваш сайт защищен от всех современных угроз.

Как часто нужно проводить аудит безопасности?

Рекомендуем проводить полный аудит не реже одного раза в полгода, а также после каждого крупного обновления ядра или установки нового расширения. Если сайт обрабатывает чувствительные данные (например, платежную информацию), частота может увеличиваться до ежеквартальной проверки. Регулярный аудит позволяет выявить уязвимости на ранней стадии и избежать дорогостоящих инцидентов.

Что делать после получения отчёта?

После завершения аудита вы получаете детальный документ с описанием каждой уязвимости, её критичностью и пошаговыми инструкциями по устранению. Мы также предлагаем услугу «под ключ» — наши инженеры исправят все проблемы в течение 1–3 дней. После устранения мы проводим повторное сканирование для подтверждения безопасности.

Процесс работы

1. Анализ — сбор информации о сайте, версиях, расширениях.
2. Сканирование — автоматические инструменты и ручная проверка.
3. Проверка кода — поиск уязвимостей в кастомных компонентах и шаблонах.
4. Конфигурация сервера — проверка PHP, веб-сервера, базы данных.
5. Отчет — описание уязвимостей и рекомендации.
6. Устранение — мы можем исправить найденные проблемы под ключ.

Сводка проверок

Сравнение методов

Сроки и стоимость

Аудит занимает от 1 до 3 дней в зависимости от сложности проекта. Стоимость рассчитывается индивидуально. Вы получаете детальный отчет с пошаговыми инструкциями по устранению каждой уязвимости.

Что вы получаете

• Гарантию качества: мы уверены в своих методах, поэтому даем гарантию на исправление всех критических уязвимостей.
• Оперативную поддержку после аудита.
• Рекомендации по постоянному мониторингу безопасности.

Свяжитесь с нами, чтобы заказать аудит и защитить ваш проект. Получите консультацию эксперта уже сегодня.

Безопасность веб-приложений: HTTPS, CSP, XSS, CSRF, WAF, защита от DDoS

Взлом сайта редко выглядит как в кино. Чаще это: бот нашёл endpoint /admin/export без авторизации, скачал базу клиентов, закрыл соединение. Или: через устаревший плагин WordPress залил веб-шелл, теперь сервер рассылает спам. Или тише: XSS в поле комментария позволяет красть session cookies администраторов, и никто не замечает месяцами. Мы такие случаи разбирали десятками — каждый раз уязвимость можно было закрыть на этапе разработки или аудита.

Безопасность веб-приложений — не одна настройка. Это слои защиты, каждый из которых закрывает отдельный класс атак. Закажите аудит — оценим проект и дадим план работ под ключ за 2–4 недели.

HTTPS и правильная конфигурация TLS

HTTPS — минимальный обязательный уровень. Но «есть SSL-сертификат» и «правильно настроен TLS» — разные вещи.

В конфигурации Nginx/Apache проверяем:

• Протоколы: только TLS 1.2 и TLS 1.3, SSLv3 и TLS 1.0/1.1 — отключены
• Cipher suites: предпочитать ECDHE (Forward Secrecy), убрать NULL, RC4, DES, 3DES
• HSTS (Strict-Transport-Security: max-age=31536000; includeSubDomains; preload) — браузер больше не делает незащищённых запросов
• OCSP Stapling — ускоряет проверку отзыва сертификата
• Redirect 301 с HTTP на HTTPS — и в конфиге сервера, и в коде (двойной редирект = потеря SEO-веса)

Проверка: SSL Labs (ssllabs.com/ssltest) должен показывать A или A+. Если B — конфигурация слабая.

Let's Encrypt + Certbot для продакшена — стандарт. Автоматическое обновление через certbot renew в cron. Wildcard-сертификат для поддоменов через DNS-01 challenge.

Content Security Policy: самая мощная и самая сложная защита

CSP — HTTP-заголовок, который говорит браузеру, откуда разрешено загружать ресурсы. Правильно настроенный CSP полностью блокирует большинство XSS-атак, даже если уязвимость есть в коде.

Проблема: сломать сайт неправильным CSP проще простого. default-src 'none' — и перестают работать шрифты, картинки, JS. Поэтому начинаем с Content-Security-Policy-Report-Only — CSP логирует нарушения, но ничего не блокирует. Смотрим репорты 2–4 недели, дорабатываем политику, потом переключаем на боевой режим.

Пример реальной политики для сайта с Google Analytics, Google Fonts и Stripe:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{random}';
  style-src 'self' https://fonts.googleapis.com 'unsafe-inline';
  font-src 'self' https://fonts.gstatic.com;
  frame-src https://js.stripe.com;
  img-src 'self' data: https://www.google-analytics.com;
  connect-src 'self' https://api.stripe.com https://www.google-analytics.com;
  report-uri /csp-report;

nonce — случайная строка, генерируется на сервере для каждого запроса. Inline-скрипты с правильным nonce разрешены, без nonce — заблокированы. Это ломает XSS через <script>alert(1)</script> полностью.

'unsafe-inline' в style-src — компромисс для inline-стилей. Лучше убрать, перенеся все стили в CSS-файлы, но это требует рефакторинга.

Почему XSS остаётся самой частой уязвимостью?

XSS (Cross-Site Scripting) — инъекция JS-кода через пользовательский ввод. По статистике OWASP, XSS входит в топ-3 уязвимостей веб-приложений. Три типа:

Защита: никогда не вставлять пользовательский ввод в HTML без эскейпинга. В PHP — htmlspecialchars() с ENT_QUOTES. В Blade-шаблонах Laravel — {{ $var }} безопасен, {!! $var !!} — опасен. В React — {variable} безопасен, dangerouslySetInnerHTML — опасен. Для Rich Text — htmlpurifier на PHP или DOMPurify в браузере.

CSRF: защита форм и API

CSRF (Cross-Site Request Forgery) — злоумышленник заставляет браузер жертвы отправить запрос от её имени. Пример: пользователь авторизован в банке, открывает вредоносную страницу, она делает fetch('https://bank.ru/transfer?to=evil&amount=50000') — если банк не защищён, деньги уходят.

CSRF-токены — стандартная защита для форм: сервер генерирует случайный токен, хранит в сессии, вставляет в форму как hidden field. При POST-запросе токен сверяется. Злоумышленник не знает токен. Laravel делает это автоматически через @csrf.

SameSite cookies — современная защита: SameSite=Strict или SameSite=Lax запрещает браузеру отправлять cookie в cross-site запросах. Работает во всех современных браузерах.

API без сессий (JWT, Bearer tokens) — CSRF неактуален, если токен не хранится в cookie (а в Authorization header или localStorage). Но localStorage уязвим к XSS — поэтому для чувствительных данных предпочтительны HttpOnly cookies с SameSite.

WAF и защита от DDoS

WAF (Web Application Firewall) — фильтрует HTTP-трафик на предмет атак: SQL injection, XSS, path traversal, известные exploit patterns. Варианты:

• Cloudflare WAF — облачный, правила OWASP Top 10 из коробки, кастомные правила через выражения. Managed Rules автоматически блокируют новые угрозы.
• ModSecurity (Nginx/Apache) — self-hosted, OWASP Core Rule Set (CRS). Гибко, но требует настройки и мониторинга ложных срабатываний.
• AWS WAF — для инфраструктуры на AWS, интегрируется с CloudFront и ALB.

DDoS-защита. Cloudflare на уровне L3/L4/L7 — де-факто стандарт для большинства сайтов. Автоматическое смягчение volumetric атак, Under Attack Mode при активной атаке. Для критичной инфраструктуры — Cloudflare Magic Transit или специализированные решения (Qrator, StormWall для российского рынка).

Rate Limiting на уровне приложения — дополнительный слой. Laravel ThrottleRequests middleware: 60 запросов в минуту на IP для общих endpoint, 5 — для /login и /password/reset. Redis как хранилище счётчиков — обязательно для горизонтально масштабируемых систем (иначе лимиты не синхронизируются между серверами).

Другие обязательные меры

Заголовки безопасности. Помимо CSP: X-Frame-Options: DENY (защита от clickjacking), X-Content-Type-Options: nosniff (MIME sniffing), Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (ограничение доступа к API браузера: камера, микрофон, геолокация).

SQL injection. Prepared statements везде. Никаких конкатенаций пользовательского ввода в SQL-строки. ORM (Eloquent, Doctrine) защищает по умолчанию. $wpdb->prepare() в WordPress — обязательно.

Обновления зависимостей. composer audit и npm audit — в CI/CD пайплайн. Dependabot или Renovate для автоматических PR с обновлениями. Критичные CVE — патчить в течение 24 часов.

Секреты и конфигурация. .env — никогда в Git. Секреты в production — через переменные окружения CI/CD (GitHub Secrets, GitLab CI Variables) или HashiCorp Vault. Проверка на утечки: git-secrets, truffleHog в pre-commit hooks.

Как мы работаем

1. Аудит — сканирование кода, конфигураций, зависимостей, ручная проверка бизнес-логики.
2. Проектирование — план устранения уязвимостей, подбор стека (CSP, WAF, rate limiting).
3. Реализация — настройка TLS, CSP, заголовков, внедрение Rate Limiting, WAF.
4. Тестирование — повторный пентест, нагрузочное тестирование, проверка ложных срабатываний.
5. Деплой и мониторинг — включение боевого CSP, настройка алертов, обучение команды.

Что входит в работу

• Отчёт с найденными уязвимостями и рекомендациями (PDF + code snippets)
• Готовая конфигурация TLS (Nginx/Apache)
• Политика CSP с режимом Report-Only и боевой версией
• Настройка WAF и Rate Limiting
• План обновлений зависимостей
• Доступы к инструментам мониторинга (Sentry, Datadog)
• 30 дней постаудит-поддержки (консультации, правки)

Сроки и стоимость

Бюджет рассчитывается индивидуально — напишите нам, чтобы оценить проект.