Проверка безопасности перед выпуском
Мы последовательно ограничили ввод, вывод, SQL, сессию, доступ к объекту и вспомогательные возможности. Теперь нужно убедиться, что эти механизмы работают вместе. Правильный отдельный helper не гарантирует, что новый маршрут действительно его вызывает.
Результат последнего урока — матрица требований и полный учебный исходник security-lab. Он сохранён для самостоятельной практики. При подготовке курса приложение, зависимости и контрольные сценарии не запускались; ниже указаны ожидаемые эффекты.
Согласованное состояние
В финальной папке находятся app.py, шаблоны, отдельные helper обработки PNG, limiter и клиент фиксированной справки. Base.py сохраняет начальную версию для сравнения. Локальная база и изображения создаются только при самостоятельном использовании.
Папка instance исключена из Git и остаётся вне static. Исходники не содержат действующих паролей или LAB_SECRET. Подготовка базы просит два учебных значения и отказывается перезаписывать уже созданных пользователей.
Архив исходников security-lab содержит файлы стенда и README с последовательностью самостоятельного запуска. Распакуйте архив, прочитайте README и подготовьте отдельное окружение. Затем создайте случайный секрет и базу и только после этого обращайтесь к локальному порту 4270.
Финальная версия остаётся учебной. Политика многопроцессной нагрузки, промышленное WSGI-обслуживание, публичное восстановление пароля и другие функции требуют отдельной подготовки. Список ограничений нужен для оценки результата, а не для того, чтобы объявить пример непригодным для изучения.
Проверять требование
Один контрольный сценарий имеет исходное состояние, запрос и наблюдение. Например, «Boris не читает заметку Alice» задаёт пользователя boris, объект 1 и отсутствие содержимого. Если отправитель не вошёл, мы проверим другой механизм и не подтвердим правило владельца.
| Требование | Исходное состояние | Ожидаемое наблюдение |
|---|---|---|
| Вход нужен | Нет сессии, GET /notes | 401 без личного списка |
| Владелец читает | Alice, GET /notes/1 | 200 с её заметкой |
| Чужой объект закрыт | Boris, GET /notes/1 | 404 без текста Alice |
| Изменение требует токен | Alice, POST без токена | 403, текст не изменился |
| API сохраняет право | Boris, PATCH заметки 1 с его токеном | Отказ, текст не изменился |
| Текст остаётся текстом | Название с тегом b | Буквальные символы, без нового элемента |
| Вложение личное | Boris, ID изображения Alice | Отказ без байтов изображения |
| Отзыв действует | Повышена версия Alice | Прежний вход не разрешает чтение |
Таблица является частью спецификации. После фактического запуска рядом появятся дата, версия, запрос и полученный результат. Не заменяйте это зелёной отметкой только потому, что код похож на рассмотренный.
Положительный и отрицательный путь
Каждая защита проверяется вместе с нормальным действием. Если все формы получают 403, приложение может быть закрытым, но функция редактирования не работает. Поэтому сначала установите успешный сценарий владельца с текущим токеном, затем изменяйте одно условие.
Для XSS начните с обычного русского названия, затем используйте безобидную строку с угловыми скобками. Для SQL сравните точное название и кавычку. Для изображения сначала подготовьте допустимый маленький PNG, затем текстовый файл с тем же окончанием.
Такая последовательность помогает локализовать причину. Ошибка базы не должна выдаваться за успешную авторизацию, а отсутствие Pillow — за проверку неизвестного формата. Отказ имеет значение только в известном работающем окружении.
Все маршруты одной операции
У заметки есть список, HTML-страница, форма и API. Правило владельца проходит через каждый путь. Новая «служебная» выдача полного словаря способна обойти правильный обработчик чтения.
Аналогично изображение имеет загрузку и чтение. Проверка MIME при загрузке не ограничивает прямой публичный файл. Поэтому просмотрите доступные корни внешнего сервера и убедитесь, что instance не обслуживается другим маршрутом.
Изменяющие операции должны оставаться POST или PATCH с CSRF-проверкой. Выход в финальном примере завершает все учебные сессии владельца; соответствующая подпись формы объясняет этот эффект. GET не выполняет административное изменение.
Внутреннее состояние после отказа
Ответ 400, 403 или 404 нужно сопоставить с состоянием данных. Если запрос сначала записал новую заметку, а затем сформировал отказ, требование нарушено. Проверяется сохранённый текст и отсутствие лишнего файла.
В SQLite можно прочитать выбранные записи на отдельном контролируемом стенде. Не публикуйте дамп паролей ради отчёта. Для нашей проверки достаточно ID, названия и сравнения вымышленных значений.
При ограничении попыток проверяется, что дорогая работа не выполнялась после отказа. Сам счётчик на странице не доказывает это. Условия окна, адрес и число процессов записываются вместе с наблюдением.
Конфигурация и зависимости
Фактическая безопасность относится к запущенному составу. Сохраните Python, разрешённые версии библиотек и настройки cookie. Номер исходного файла без окружения не описывает весь результат.
Затем рассмотрите публичное дерево, ключ подписи, доверенные хосты и proxy middleware. Локальная конфигурация с HTTP отличается от внешнего HTTPS. Перенос должен сохранять модель, а не только маршруты.
Проверка известных зависимостей и контроль собственных требований дополняют друг друга. Отчёт инструмента не оценивает наш owner_id, а ручная проверка заметки не анализирует все опубликованные проблемы декодера. Их области полезно обозначить явно.
Новое изменение
Представим, что продукт добавляет обмен заметкой по ссылке. Это новый вид полномочия. Прежнее требование «только владелец» больше не описывает весь доступ; нужны условия приглашения, срока и отзыва.
Не отключайте helper для одной страницы без обновления модели. Сначала задайте актив и действие, затем новый запрос и наблюдение. Так цикл первого урока возвращается при каждом расширении функции.
Для общей системы требований можно обратиться к OWASP ASVS. В этой серии мы выбрали небольшую применимую часть и связали её с конкретными объектами. Наличие курса не является сертификацией или выполненным аудитом настоящего сервиса.
Теперь путь данных и полномочий можно объяснить от браузера до базы, файла и журнала. Следующие улучшения должны сохранять эту объяснимость: известное требование, ограниченная возможность и фактически проверяемый результат.