Безопасность веб-приложения — тема, которую заказчики часто целиком делегируют подрядчику: «вы же профессионалы, сделайте надёжно». Это понятная позиция, но рискованная. Безопасность не возникает сама по себе — её нужно заложить в требования, бюджет и сроки. Если в техническом задании о ней ни слова, а сроки сжаты, именно защитные механизмы первыми попадут под сокращение.
Утечка клиентской базы, взлом административной панели, потеря данных без резервной копии — любой из этих сценариев обходится бизнесу гораздо дороже, чем профилактика. Эта статья — не руководство для специалистов по защите информации, а практический чек-лист для заказчика. С ним можно прийти к подрядчику и задать правильные вопросы.
Почему это касается каждого проекта
Распространённое заблуждение: «мы небольшая компания, кому мы интересны». На практике большинство атак автоматизированы. Боты круглосуточно сканируют интернет в поисках известных уязвимостей, открытых административных панелей, слабых паролей. Им неважно, крупная у вас компания или нет — важно, есть ли у вас дыра.
Кроме того, если приложение обрабатывает персональные данные клиентов, компания несёт юридическую ответственность за их защиту. Утечка грозит не только репутационными потерями, но и штрафами.
Аутентификация и управление доступом
Начнём с того, кто и как входит в систему.
- Пароли хранятся в виде стойких хешей. Ни при каких условиях — в открытом виде или с обратимым шифрованием. Спросите подрядчика, какой алгоритм хеширования используется.
- Есть защита от подбора. Ограничение количества попыток входа, временная блокировка, капча после нескольких неудач.
- Двухфакторная аутентификация для администраторов. Для учётных записей с расширенными правами это обязательно.
- Сессии имеют ограниченный срок жизни и корректно завершаются при выходе.
- Восстановление пароля безопасно. Ссылка одноразовая, с ограниченным временем действия, не раскрывает, существует ли учётная запись с таким адресом.
- Права проверяются на сервере. Скрыть кнопку в интерфейсе недостаточно — сервер должен проверять, имеет ли пользователь право на каждое действие.
Последний пункт — источник одной из самых частых уязвимостей. Классический пример: пользователь меняет номер заказа в адресной строке и видит чужой заказ, потому что сервер не проверил, кому этот заказ принадлежит.
Защита данных
Шифрование при передаче
Всё приложение работает только по HTTPS, включая административную панель и API. Незащищённые соединения перенаправляются на защищённые. Сертификаты обновляются автоматически, чтобы не было ситуации, когда сайт внезапно перестал открываться из-за истёкшего сертификата.
Шифрование при хранении
Особо чувствительные данные — паспортные данные, медицинская информация, платёжные реквизиты — дополнительно шифруются в базе данных. Ключи шифрования хранятся отдельно от самих данных.
Минимизация данных
Лучший способ защитить данные — не хранить их без необходимости. Если для работы сервиса не нужны полные данные банковской карты, их не нужно сохранять — эту задачу берёт на себя платёжный провайдер.
Секреты вне кода
Пароли к базам данных, ключи API, токены доступа к внешним сервисам не должны лежать в исходном коде и попадать в систему контроля версий. Для них используются переменные окружения или специальные хранилища секретов.
Защита от типовых уязвимостей
Существует общепризнанный перечень наиболее распространённых уязвимостей веб-приложений. Заказчику не обязательно разбираться в деталях, но полезно знать основные категории и спросить подрядчика, как от них защищено приложение.
- Внедрение SQL-кода. Злоумышленник передаёт в форму специальную строку и получает доступ к базе данных. Защита — параметризованные запросы и использование ORM.
- Межсайтовый скриптинг (XSS). Вредоносный скрипт внедряется на страницу и выполняется в браузере других пользователей. Защита — экранирование выводимых данных и политика безопасности контента.
- Подделка межсайтовых запросов (CSRF). Пользователя заставляют выполнить действие в приложении без его ведома. Защита — специальные токены и правильные настройки cookie.
- Небезопасная загрузка файлов. Под видом изображения загружается исполняемый скрипт. Защита — проверка типа файла, хранение вне исполняемых директорий, ограничение размера.
- Уязвимые зависимости. Приложение использует сторонние библиотеки с известными дырами. Защита — регулярное обновление и автоматическое сканирование зависимостей.
- Ошибки конфигурации. Отладочный режим на боевом сервере, открытые служебные порты, стандартные пароли. Защита — чек-лист развёртывания и автоматизация инфраструктуры.
- Раскрытие информации в ошибках. Подробные сообщения об ошибках показывают пользователю структуру базы и пути на сервере. Защита — общие сообщения для пользователя, подробности только в журналах.
Административная панель
Административная панель — самая привлекательная цель для атак. Через неё можно получить доступ ко всем данным сразу.
- Панель не должна находиться по очевидному адресу.
- По возможности доступ к ней ограничивается по IP-адресам или через VPN.
- Каждый сотрудник имеет собственную учётную запись — никаких общих логинов.
- Права выдаются по принципу минимальной необходимости: менеджер по контенту не должен иметь доступ к выгрузке клиентской базы.
- Учётные записи уволенных сотрудников блокируются в день увольнения.
- Важные действия журналируются: кто, когда и что изменил.
Резервное копирование и восстановление
Безопасность — это не только защита от взлома, но и способность пережить сбой. Ошибка разработчика, отказ диска, действия злоумышленника, шифровальщик — данные могут быть потеряны по множеству причин.
Минимальные требования:
- Автоматическое резервное копирование базы данных и загруженных файлов по расписанию.
- Хранение копий отдельно от основного сервера — в другом дата-центре или облачном хранилище.
- Несколько точек восстановления — не только вчерашняя копия, но и недельной, и месячной давности.
- Регулярная проверка восстановления. Резервная копия, которую ни разу не пробовали восстановить, — это надежда, а не гарантия.
- Понятный план действий при инциденте: кто отвечает, сколько времени займёт восстановление, какой объём данных допустимо потерять.
Мониторинг и реагирование
Даже хорошо защищённое приложение нужно наблюдать.
- Журналы входов, ошибок и подозрительной активности собираются централизованно.
- Настроены оповещения об аномалиях: всплеск неудачных входов, необычный объём запросов, массовая выгрузка данных.
- Отслеживаются ошибки в работе приложения в реальном времени.
- Определено, кто и в какие сроки реагирует на инцидент.
Процесс разработки
Безопасность закладывается не в конце, а на протяжении всей разработки.
- Требования безопасности описаны в техническом задании.
- Код проходит ревью, в том числе с точки зрения безопасности.
- Используются автоматические анализаторы кода и зависимостей.
- Тестовые и боевые среды разделены, реальные персональные данные не используются в тестировании.
- Перед запуском проводится проверка на уязвимости — внутренняя или с привлечением внешних специалистов.
- После запуска приложение регулярно обновляется.
Безопасность — это не разовая галочка перед релизом, а постоянный процесс. Приложение, которое не обновлялось год, почти наверняка содержит известные уязвимости в своих зависимостях.
Вопросы, которые стоит задать подрядчику
- Как хранятся пароли пользователей?
- Как проверяются права доступа на сервере?
- Где хранятся ключи и пароли к внешним сервисам?
- Как часто делаются резервные копии и когда последний раз проверялось восстановление?
- Как отслеживаются уязвимости в используемых библиотеках?
- Проводится ли тестирование на проникновение перед запуском?
- Что входит в поддержку с точки зрения обновлений безопасности?
Уверенные и конкретные ответы на эти вопросы — хороший признак. Расплывчатые формулировки вроде «у нас всё защищено» — повод насторожиться.
Вывод
Базовая безопасность веб-приложения строится на нескольких опорах: надёжная аутентификация и проверка прав на сервере, шифрование данных, защита от типовых уязвимостей, ограниченный доступ к административной панели, проверенное резервное копирование и постоянный мониторинг. Заказчику не нужно реализовывать это самому, но важно включить требования в задание и проверить, что подрядчик их выполняет.
Если вы хотите разработать защищённое приложение или проверить безопасность существующего, посмотрите наш подход к разработке веб-приложений и к поддержке и развитию работающих систем.