Безопасность приложений: как защитить от взлома
Безопасность приложений — это не «поставил файрвол и забыл». Это постоянная работа: обновления, проверки, мониторинг, реакция на инциденты. Приложения атакуют постоянно: автоматические сканеры ищут уязвимости, боты подбирают пароли, хакеры используют ошибки в коде.
Последствия взлома серьёзные: утечка данных пользователей, потеря трафика, штрафы за нарушение 152-ФЗ, репутационные потери. Хорошая новость: большинство атак можно предотвратить базовыми мерами защиты. В этой статье — разбор безопасности приложений: типичные уязвимости, методы защиты, инструменты. Если нужно разместить защищённое приложение — поможем.
Почему это важно
Безопасность приложения — это не опция. Это обязательное требование, особенно если приложение работает с персональными данными.
Утечка данных
Злоумышленник получает доступ к базе: логины, пароли, персональные данные. Это катастрофа для бизнеса.
Штрафы
За нарушение 152-ФЗ штрафы достигают миллионов рублей. Плюс блокировка сайта.
Потеря трафика
Google и Яндекс блокируют заражённые сайты. Трафик падает в разы.
Потеря клиентов
После утечки клиенты уходят. Восстановить репутацию сложно.
Финансовые потери
Простой приложения, восстановление, репутационный ущерб — всё это деньги.
Использование для атак
Взломанный сервер используют для DDoS-атак, рассылки спама, майнинга. Это создаёт дополнительные проблемы.
OWASP Top 10
OWASP (Open Web Application Security Project) — это сообщество, которое изучает безопасность приложений. Их список Top 10 — это рейтинг самых распространённых уязвимостей.
| # | Уязвимость | Что это |
|---|---|---|
| 1 | Broken Access Control | Неправильные права доступа. Пользователь видит то, что не должен |
| 2 | Cryptographic Failures | Слабые алгоритмы шифрования, незашифрованные данные |
| 3 | Injection | SQL-, NoSQL-, командные инъекции |
| 4 | Insecure Design | Архитектурные ошибки в проектировании |
| 5 | Security Misconfiguration | Неправильные настройки сервера, фреймворка, приложения |
| 6 | Vulnerable Components | Устаревшие библиотеки и зависимости |
| 7 | Authentication Failures | Слабые пароли, отсутствие 2FA, ошибки в сессиях |
| 8 | Software and Data Integrity | Отсутствие проверки целостности обновлений |
| 9 | Logging Failures | Нет логирования, мониторинга, реакции на инциденты |
| 10 | SSRF | Server-Side Request Forgery. Запросы от имени сервера |
Этот список — не «теория». Большинство реальных взломов происходит именно по этим векторам. Проверьте своё приложение на каждую уязвимость.
Инъекции
Инъекции — это внедрение вредоносного кода через данные, которые вводит пользователь. Самая известная — SQL-инъекция.
Как работает SQL-инъекция
Приложение принимает данные от пользователя и вставляет их в SQL-запрос. Если данные не проверяются, злоумышленник может вставить SQL-код.
Пример: SELECT * FROM users WHERE name = '$name'. Если пользователь введёт ' OR '1'='1, запрос вернёт всех пользователей.
Как защититься
- Параметризованные запросы: используйте prepared statements. Данные передаются отдельно от SQL;
- ORM: используйте ORM (Doctrine, SQLAlchemy, Sequelize). Они делают параметризацию автоматически;
- Валидация: проверяйте типы данных. Если ожидаете число — проверьте, что это число;
- Экранирование: если нельзя параметризовать — экранируйте спецсимволы;
- Права БД: приложение не должно иметь прав на удаление таблиц.
Другие инъекции
- NoSQL-инъекции: похожи на SQL, но для MongoDB;
- Командные инъекции: внедрение команд ОС через пользовательские данные;
- LDAP-инъекции: в LDAP-запросах;
- XML-инъекции: XXE (XML External Entity).
XSS — Cross-Site Scripting
XSS — это внедрение JavaScript-кода через данные, которые видит другой пользователь. Когда пользователь открывает страницу, скрипт выполняется в его браузере.
Виды XSS
- Reflected: скрипт в URL. Пользователь кликает по ссылке — скрипт выполняется;
- Stored: скрипт сохраняется в БД. Каждый, кто открывает страницу, атакуется;
- DOM-based: скрипт выполняется на клиенте через изменение DOM.
Чем опасен
- Кража cookies и сессий;
- Кража данных форм (логины, пароли, карты);
- Перенаправление на фишинговые сайты;
- Манипуляции с интерфейсом.
Как защититься
- Экранирование вывода: HTML-экранирование всех данных, которые выводятся на страницу;
- CSP (Content Security Policy): заголовок, который запрещает выполнение сторонних скриптов;
- HttpOnly cookies: cookies недоступны для JS;
- Валидация ввода: проверяйте данные на входе;
- Современные фреймворки: React, Vue, Angular экранируют вывод автоматически.
CSRF — Cross-Site Request Forgery
CSRF — это атака, при которой злоумышленник заставляет пользователя выполнить действие на сайте, где он авторизован. Например, перевести деньги или изменить пароль.
Как работает
Пользователь авторизован на сайте банка. Злоумышленник отправляет ему письмо со ссылкой. Пользователь кликает — открывается страница с формой, которая автоматически отправляет запрос на сайт банка. Браузер отправляет cookies — банк думает, что это пользователь.
Как защититься
- CSRF-токены: в каждую форму добавляется уникальный токен. Без него запрос не принимается;
- SameSite cookies: cookies отправляются только с того же сайта;
- Проверка Referer: проверяйте, откуда пришёл запрос;
- Двойное подтверждение: для критичных действий (перевод денег, смена пароля).
Аутентификация
Аутентификация — это «вход в систему». Ошибки здесь критичны.
Пароли
- Хеширование: пароли хранятся только в виде хеша. Никогда — в открытом виде;
- Современные алгоритмы: bcrypt, argon2, scrypt. Не MD5, не SHA1;
- Соль: уникальная для каждого пароля. Защищает от радужных таблиц;
- Сложность: минимальная длина 8–12 символов;
- Проверка утечек: используйте Have I Been Pwned API.
Сессии
- HttpOnly: cookies недоступны для JS;
- Secure: cookies отправляются только по HTTPS;
- SameSite: защита от CSRF;
- Таймаут: сессия истекает через N минут бездействия;
- Обновление ID: при логине меняйте ID сессии;
- Выход: при выходе уничтожайте сессию на сервере.
Двухфакторная аутентификация (2FA)
- TOTP: Google Authenticator, Яндекс.Ключ;
- SMS-код: не самый надёжный, но лучше, чем ничего;
- Аппаратные ключи: YubiKey, FIDO2;
- Push-уведомления: в мобильном приложении.
Секреты и конфигурации
Секреты — это пароли, ключи, токены. Они должны быть защищены.
Правила
- Не в коде: никогда не коммитьте секреты в репозиторий. Даже в приватный;
- Переменные окружения: храните секреты в env-переменных;
- Vault: для больших команд используйте HashiCorp Vault, AWS Secrets Manager;
- Ротация: меняйте секреты регулярно. Особенно если кто-то ушёл из команды;
- Разные для окружений: секреты для dev, staging, prod — разные;
- Аудит: логируйте доступ к секретам.
Что часто утекает
- API-ключи сторонних сервисов;
- Пароли БД;
- JWT-секреты;
- Ключи шифрования;
- SMTP-пароли;
- Ключи платёжных систем.
Зависимости
Большинство современных приложений используют десятки и сотни библиотек. Каждая из них — потенциальная уязвимость.
Проблемы
- Устаревшие версии: содержат известные уязвимости;
- Неподдерживаемые библиотеки: автор забросил проект, обновлений нет;
- Зависимости зависимостей: вы не знаете, что внутри;
- Вредоносные пакеты: в npm, PyPI периодически появляются.
Как защититься
- Аудит: npm audit, pip-audit, snyk;
- Обновления: регулярно обновляйте зависимости;
- Lock-файлы: package-lock.json, Pipfile.lock фиксируют версии;
- Минимум зависимостей: каждая лишняя библиотека — риск;
- Проверка лицензий: не используйте библиотеки с неподходящими лицензиями.
Мониторинг безопасности
Даже лучшая защита может быть обойдена. Мониторинг помогает вовремя заметить проблему.
Что отслеживать
- Неудачные входы: много попыток — попытка брутфорса;
- Аномалии запросов: подозрительные URL, параметры;
- Ошибки 500: могут говорить о попытках эксплуатации;
- Необычная нагрузка: может быть атака;
- Изменения файлов: AIDE, Tripwire, filebeat;
- Новые пользователи: неожиданные регистрации.
Логирование
- Что логировать: вход, выход, критические действия, ошибки;
- Что НЕ логировать: пароли, токены, персональные данные;
- Хранение: отдельный сервер, защищённое хранилище;
- Ротация: старые логи архивируются, потом удаляются;
- Анализ: ELK, Graylog, Splunk.
Чек-лист безопасности приложения
Код
- Параметризованные запросы
- Экранирование вывода
- CSRF-токены
- Валидация входных данных
- Нет секретов в коде
Аутентификация
- Хеширование паролей (bcrypt)
- 2FA для админов
- HttpOnly, Secure cookies
- Таймаут сессий
- Лимит попыток входа
Инфраструктура
- HTTPS только
- Файрвол настроен
- Fail2ban
- Обновления ОС и зависимостей
- Бэкапы
Мониторинг
- Логирование
- Алерты о подозрительной активности
- Аудит изменений файлов
- Регулярные сканирования
- Реакция на инциденты
Наши рекомендации
📌 Что вы получаете, заказывая безопасность у нас
- Аудит — по OWASP Top 10
- Защиту от инъекций — параметризация, валидация
- Защиту от XSS и CSRF — экранирование, токены
- Усиление аутентификации — 2FA, хеширование
- Мониторинг — логи, алерты, реакция
- Реакцию на инциденты — помощь дежурным
🔹 Оставьте заявку на аудит безопасности
Хотите защитить приложение? Оставьте заявку на бесплатную консультацию.
📌 Итоговый вывод
Безопасность приложений — это постоянная работа, а не разовое мероприятие.
Что нужно знать:
- Почему важно — утечки, штрафы, потеря трафика и клиентов
- OWASP Top 10 — главные уязвимости веб-приложений
- Инъекции — параметризованные запросы, валидация
- XSS — экранирование вывода, CSP, HttpOnly cookies
- CSRF — CSRF-токены, SameSite cookies
- Аутентификация — bcrypt, 2FA, безопасные сессии
- Секреты — в env-переменных, не в коде
- Зависимости — аудит, обновления, минимум библиотек
- Мониторинг — логирование, алерты, реакция
Хотите защитить приложение? Закажите консультацию в Lead Hub.
Также рекомендуем: Docker, Kubernetes, CI/CD, масштабирование, мониторинг, хостинг для приложений.