Сертификат HTTPS, сложный пароль администратора и резервная копия решают разные задачи. Ни один из этих механизмов не заменяет остальные. Можно шифровать соединение и при этом показывать чужие заказы, регулярно сохранять базу и не замечать утечку, проверять форму в браузере и доверять присланной сумме оплаты.
Разберём защиту условного магазина с личным кабинетом: покупатель входит, выбирает товар, прикладывает документ, оформляет заказ и оплачивает его. Сотрудники обрабатывают обращения, меняют каталог и выполняют разрешённые финансовые действия. Каждому шагу нужны собственные проверки.
Десять схем помогают увидеть эти связи и задать вопросы разработчику. Материал носит учебный характер: он не подтверждает безопасность DDRW или другого конкретного сайта и не заменяет проверку реализации. Здесь нет универсального обещания «защиты от всего» — есть понятные границы, решения и способы убедиться, что они работают.
1. Модель угроз: что защищаем и кому доверяем
Начинаем с активов: контактов покупателей, заказов, загруженных документов, учётных записей сотрудников и ключей интеграций. Для каждого определяем последствия чтения, изменения или потери. Публичная фотография товара и закрытый документ клиента требуют разных правил.
Затем обозначаем участников: посетителя, покупателя, сотрудника, администратора и платёжного провайдера. Перемещение данных между их зонами ответственности пересекает границу доверия. Запрос из браузера нельзя считать достоверным только потому, что его отправила наша форма.
Модель угроз описывает возможные нежелательные события и меры против них. Например, чужой заказ не должен открываться покупателю, редактор каталога не должен выполнять возвраты, сбой почты не должен терять оформленную покупку. Такой процесс нужно обновлять вместе с функциями сайта. Подход OWASP к моделированию угроз.
HTTPS защищает передачу между сторонами соединения, но не подтверждает корректность расчёта, качество хранения данных или полномочия пользователя. Шифрование транспорта не исправляет ошибку, при которой сервер сам отправляет закрытый документ неподходящему получателю.
Практический результат этого этапа — схема данных и список проверяемых требований с ответственными. Вместо фразы «нужна безопасная админка» фиксируем конкретное: кто видит документы, кто меняет доступ и как прекращаются полномочия уволенного сотрудника.
2. Вход: пароль, сессия и восстановление доступа
Вход подтверждает личность пользователя, но безопасность не заканчивается проверкой пароля. Нужны хранение паролей, дополнительный фактор, восстановление и управление уже выданными сессиями.
Пароль не следует хранить открытым текстом или в виде обратимо зашифрованного значения для обычной проверки входа. Используют специализированное хеширование паролей с солью и согласованными параметрами. Обычный быстрый хеш общего назначения не является равнозначной заменой.
В нашем магазине сотрудники получают индивидуальные аккаунты. Для чувствительных полномочий предусматривается MFA, а финансовые действия могут требовать повторного подтверждения. Второй фактор снижает определённые риски, но не отменяет необходимость защиты активной сессии и процедуры восстановления. Рекомендации OWASP по аутентификации.
Сессия имеет срок действия и возможность отзыва. Выход из интерфейса должен соответствовать реальному прекращению нужного доступа, а не только удалению имени пользователя из шапки. Изменение пароля и отключение сотрудника также требуют явно определённого поведения сессий.
Ограничения попыток применяют с учётом аккаунта и сетевого источника. Один адрес сети может обслуживать много покупателей, а чрезмерная блокировка способна помешать владельцу аккаунта. Поэтому заранее определяют задержки, уведомления и безопасный путь восстановления.
Ссылка сброса пароля должна быть ограничена по времени и использованию. Её токен не попадает в аналитику и журналы. Само письмо не должно содержать действующий пароль, а процедура восстановления — обходить второй фактор без предусмотренной проверки.
3. Права: проверять действие и конкретный объект
Аутентификация отвечает на вопрос «Кто это?», авторизация — «Что ему разрешено?». Покупатель может успешно войти в аккаунт и всё равно не иметь права читать определённый заказ.
Для каждого обращения сервер проверяет и действие, и объект. Доступ к списку собственных покупок не означает доступ ко всем заказам магазина. Разрешение редактировать товар не включает изменение ролей сотрудников или запуск возврата.
Рабочий принцип — запрет по умолчанию. Разрешение должно иметь понятное основание: владение записью, назначенная роль или другое подтверждённое условие. Проверка нужна независимо от обычной страницы, API или фонового выполнения. Рекомендации OWASP по авторизации.
Скрытая кнопка не обеспечивает запрет. Сложный идентификатор заказа также не заменяет проверку владельца: он лишь уменьшает предсказуемость адреса. Источник полномочий — серверное состояние, а не поля role или user_id, присланные браузером.
В условной админке полезно разделить чтение заказа, изменение обработки и финансовые операции. Сотрудник получает необходимый минимум. При смене роли проверяют не только новое меню, но и доступ по прямой ссылке, через API и к файлам.
Общие кеши, выгрузки и поиск тоже соблюдают границы доступа. Защита основной карточки не поможет, если те же контакты можно получить из экспорта или другого представления данных.
4. Ввод и вывод: валидация, SQL и XSS решают разные задачи
Валидация определяет, допустимы ли данные для операции: количество является целым положительным числом, выбранный вариант существует, длина комментария ограничена. Проверка в браузере помогает человеку, но сервер выполняет её самостоятельно.
Защита SQL требует отделения команды от значений. Для обычных значений используют параметризованные запросы, а не собирают SQL из строк пользовательского ввода. Даже корректно оформленная строка поиска остаётся данными, а не частью программы. Рекомендации OWASP по предотвращению SQL-инъекций.
Параметры не решают любой динамический SQL. Если интерфейс позволяет выбирать сортировку, приложение сопоставляет допустимые варианты с заранее известными столбцами и направлениями. Произвольный текст пользователя не должен выбирать структуру команды.
XSS относится к другому этапу: браузер не должен интерпретировать пользовательские данные как исполняемую разметку или код. Обычный комментарий показывают как текст с подходящим контексту кодированием. Если нужен форматированный HTML, требуется отдельная очистка разрешённой разметки. Рекомендации OWASP по безопасному выводу.
HTML, атрибут, URL и JavaScript — разные контексты. Универсальная замена нескольких символов не защищает все места использования. У ссылки отдельно проверяют допустимую схему; экранирование текста само по себе не делает любой адрес безопасным.
Данные из собственной базы тоже могут происходить из недоверенного источника. Комментарий покупателя, импортированный каталог и входящее письмо проходят соответствующие правила при отображении, даже если запись уже давно хранится на сервере.
5. Cookies и CSRF: защитить действие от чужой страницы
Браузер автоматически прикладывает подходящие cookies к запросу. Это удобно для сессии, но создаёт отдельный риск: посторонняя страница может попытаться инициировать действие с участием уже вошедшего пользователя.
CSRF-защита помогает серверу отличить допустимый изменяющий запрос от такого межсайтового обращения. В зависимости от архитектуры проверяют токен и происхождение запроса. Чтение публичной карточки и отмена заказа имеют разный смысл: изменяющие действия не следует выполнять обычным GET-переходом.
Secure ограничивает передачу cookie защищённым соединением. HttpOnly не позволяет обычному JavaScript читать её содержимое. SameSite регулирует отправку в межсайтовых сценариях. Эти свойства полезны вместе, но не являются общей гарантией от всех атак. Рекомендации OWASP по CSRF.
В частности, HttpOnly не мешает браузеру отправлять cookie, а SameSite не заменяет полноценную защиту для большинства приложений. Область домена, способ перехода и соседние поддомены имеют значение. Настройку нельзя выбирать только по принципу «самое строгое название» без проверки рабочих сценариев.
Для нашего магазина защита применяется к изменению корзины, оформлению, контактным данным и административным операциям. Серверные уведомления банка используют другой механизм подтверждения подлинности: они приходят не из пользовательской формы.
CSRF-защита не исправляет XSS и не подтверждает право на объект. Если запрос прошёл проверку происхождения, сервер всё равно проверяет владельца заказа и допустимость действия.
6. Загрузки: файл проверяется как содержимое
Покупатель может приложить документ к заказу, сотрудник — загрузить фотографию товара. Эти операции различаются правами и последующим доступом, даже если обе начинаются с кнопки выбора файла.
Имя и Content-Type присылает клиент. Они помогают интерфейсу, но не подтверждают содержимое. Приложение ограничивает допустимые форматы, размер и число файлов, проверяет фактический тип и пригодность для ожидаемой обработки. Одна сигнатура первых байтов также не доказывает безопасность всего файла. Рекомендации OWASP по загрузкам.
Для изображения можно предусмотреть разбор поддерживаемым декодером и создание подготовленной копии. Ограничения размеров и ресурсов обработки нужны отдельно: небольшой исходный файл не всегда означает небольшой расход памяти после распаковки.
Имя хранения генерирует приложение. Пользовательское название можно сохранить как отдельное отображаемое поле, но оно не должно самостоятельно выбирать путь на диске. Хранилище не должно исполнять загруженные материалы как код приложения.
Приватное вложение заказа нельзя сделать доступным только потому, что ссылка выглядит случайной. Выдача проходит проверку пользователя и объекта либо использует ограниченный по времени доступ по согласованной схеме. Фотография опубликованного товара и документ клиента не попадают в один общий публичный режим автоматически.
Антивирусная проверка или изоляция обработчика могут дополнять защиту. Они не отменяют ограничений и авторизации; использование внешнего сканера также требует оценки допустимости передачи клиентских документов.
7. Интеграции: секреты, исходящие запросы и уведомления
Ключи почты, банка и внешних API остаются в защищённой серверной конфигурации. Они не должны входить в клиентский пакет, публичный репозиторий или обычные журналы. Тестовая среда получает отдельные полномочия; доступ к рабочим секретам предоставляется по необходимости.
Интеграции различают по направлению. Если магазин сам загружает файл или обращается по введённой ссылке, возникает вопрос SSRF: пользователь не должен произвольно распоряжаться сетевыми возможностями сервера.
Ограничивают допустимые назначения, схемы и порты, учитывают фактический адрес соединения и перенаправления. Проверка только внешнего вида URL недостаточна. Если бизнес-процесс допускает известный перечень провайдеров, его лучше задать явно. Рекомендации OWASP по SSRF.
Входящий webhook, наоборот, сообщает о внешнем событии. Его подлинность проверяется по контракту поставщика: подписью, токеном или другим предусмотренным механизмом. Знакомое имя отправителя в теле запроса не является подтверждением, как и сам факт использования HTTPS.
Перед обработкой задают ограничения размера, допустимые типы событий и правила повтора. Старое или повторное уведомление не должно бесконтрольно менять состояние заказа. Ответ внешнего API также проходит проверку структуры и ожидаемого смысла: сторонняя система не становится полностью доверенной после успешного соединения.
Ротацию ключа планируют заранее: кто выполняет замену, как проверяется новая конфигурация и когда прекращается действие старой. При подозрении на утечку удаление файла с ключом не заменяет его отзыв у поставщика.
8. Оплата: защищать состояние, сумму и повторные действия
Перед оформлением сервер заново проверяет товар, вариант, количество и условия покупки. Сумма в браузере — предварительное отображение, а не разрешение списать именно столько денег. В заказе сохраняется снимок согласованного состава и стоимости.
Заказ и платёж имеют связанные, но отдельные состояния. Заказ может существовать до оплаты; банковская авторизация не всегда означает окончательное списание. Допустимые переходы определяют по конкретной платёжной схеме.
Возврат браузера на страницу успеха не доказывает оплату. Сервер получает подтверждённое уведомление либо запрашивает статус по защищённому API. Затем сопоставляет внутренний заказ, внешний платёж, сумму, валюту и нужный статус. Рекомендации OWASP по платёжным интеграциям.
Повторы проектируются отдельно. Двойное нажатие, потеря ответа и повторный webhook не должны повторно уменьшать остаток, создавать одинаковые задания или проводить финансовое действие. Для этого применяют идентификаторы операции, ограничения в базе и проверяемые переходы состояния. Идемпотентность не следует обещать на основании одной заблокированной кнопки.
Изменение локальной базы не откатывает внешнее списание. При неопределённом ответе сначала выясняют фактический статус, а не автоматически повторяют платёж или возврат.
В админке отмена обработки заказа и возврат средств имеют разные команды и разрешения. Для сотрудника показывают подтверждённое состояние, причину отказа и историю действия. Секретные реквизиты и платёжные данные при этом не становятся содержимым обычной карточки поддержки.
9. Зависимости и наблюдение: безопасность после выпуска
Безопасность меняется вместе с библиотеками, инфраструктурой и настройками. Нужен учёт зависимостей, включая косвенные, и процесс получения сведений об уязвимостях. Важны не только обновления приложения, но и поддержка образов, обработчиков файлов и средств администрирования.
Найденная уязвимость требует оценки применимости и приоритета исправления. Обновление проверяют на совместимость и критические сценарии, а решение отложить — фиксируют с ответственным и условиями пересмотра. Проверка зависимостей не является доказательством отсутствия других проблем. Рекомендации OWASP по управлению уязвимыми зависимостями.
Журналы помогают расследовать ошибки входа, отказы доступа, смену ролей и финансовые действия. Полезны время, идентификатор операции, исполнитель, объект и результат. Запись не обязана содержать полное содержимое заказа или документа.
Пароли, сессионные токены, ссылки восстановления и секреты интеграций в обычные логи не включают. Введённый пользователем текст нельзя безусловно записывать как структуру журнала. Доступ к самим журналам и сроки хранения также ограничиваются. Рекомендации OWASP по журналированию.
В условном магазине уведомление о массовых отказах входа полезно только при понятном порядке действий. Кто получает сигнал, как отличает сбой от подозрительной активности и где проверяет последствия? Наличие графика не заменяет этих договорённостей.
При мониторинге сохраняют баланс: достаточно данных для диагностики, но без создания ещё одной бесконтрольной копии персональной информации. Выгрузка журналов во внешний сервис требует такой же оценки доступа, как любая другая интеграция.
10. Инцидент: остановить доступ и восстановить управляемую систему
Порядок реагирования полезно определить до инцидента. Нужны ответственные, способы связи и полномочия на отключение проблемной функции. Реагирование включает обнаружение, разбор, ограничение последствий и восстановление; это часть управления риском. Рекомендации NIST SP 800-61r3.
При подозрении на компрометацию фиксируют доступные свидетельства и последовательность событий, ограничивают опасный доступ и выясняют затронутые компоненты. Неосторожная перезапись журналов или немедленное восстановление поверх рабочей системы способны уничтожить важные данные для расследования.
Скомпрометированную сессию отзывают, доступ сотрудника прекращают по предусмотренной процедуре, ключи интеграций заменяют у соответствующих поставщиков. Смена одного пароля не гарантирует прекращение всех уже выданных полномочий. Необходимо понимать, какие токены и подключения остаются действительными.
Резервная копия помогает вернуть доступность и данные, но не отменяет произошедшее раскрытие информации. Перед восстановлением определяют доверенную точку и устраняют причину. Возвращение старой базы с прежними ключами или уязвимой конфигурацией может вернуть проблему.
Копию проверяют в изолированной среде с отключёнными реальными отправками и финансовыми действиями. После восстановления сопоставляют состояния заказов с внешними системами: банк не обязан «вернуться в прошлое» вместе с базой магазина.
Чек-лист владельца сайта
- Понятно, какие данные приватные и кто отвечает за доступ.
- У сотрудников индивидуальные аккаунты и необходимые им полномочия.
- Восстановление входа и отзыв сессий имеют проверяемый порядок.
- Сервер проверяет каждый объект и финансовое действие независимо от интерфейса.
- Ввод, SQL, отображение и загрузки защищаются соответствующими механизмами.
- Интеграции ограничены, секреты не публичны, уведомления проверяются.
- Заказы и платежи выдерживают предусмотренные повторы и неопределённые ответы.
- Обновления, журналы, реагирование и восстановление имеют ответственных.
Частые вопросы
Достаточно ли HTTPS и MFA? Это важные меры для транспорта и входа. Они не заменяют проверку прав, защиту данных и корректную обработку бизнес-операций.
Можно ли один раз проверить сайт и больше не возвращаться к безопасности? Изменения функций, зависимостей и доступа меняют риски. Проверки повторяют по согласованному плану и после существенных изменений.
Что означает «безопасность проверена»? Нужны границы проверки, дата, метод и результаты. Чек-лист или отсутствие известных инцидентов не доказывают безопасность всех возможных сценариев.
Для начала полезно пройти один полный путь покупателя и сотрудника: кто получает данные, кто разрешает действие, что фиксируется и как прекращается доступ. Такой разбор даёт предметный план улучшений без обещаний абсолютной защиты.
