Вход в систему не даёт права на каждый объект
Аутентификация отвечает на вопрос, кто обращается к системе. Авторизация определяет, какие действия ему разрешены. В учебном приложении пользователь А владеет документом ДА, а пользователь Б — документом ДБ. Оба успешно вошли, но правило разрешает каждому читать только собственный документ. Если сервер выдаёт ДБ пользователю А только потому, что тот указал его идентификатор, нарушена проверка прав на объект. Сам идентификатор не должен считаться разрешением. Скрытая кнопка в интерфейсе тоже не заменяет серверную проверку соответствующего обращения.
Тестовые данные делают доказательство точнее
Для проверки полезно заранее знать владельцев объектов и разрешённые действия. Тогда не приходится угадывать настоящие чужие записи или накапливать содержимое, не нужное для доказательства. В согласованной тестовой среде используются подготовленные аккаунты и искусственные документы с узнаваемыми метками. Важно также различать операции: разрешение читать не обязательно включает изменение или удаление. Поэтому результат одного сценария нельзя автоматически распространять на все функции приложения. Границы проверки определяют заранее, включая среду, аккаунты и допустимые действия; неожиданная находка не расширяет их сама по себе.
Отчёт связывает правило, наблюдение и исправление
Полезный отчёт описывает исходные права, выполненное действие в пределах согласованного теста, ожидаемый ответ и фактически полученный результат. Для доказательства часто достаточно минимальных сведений о том, что выдан чужой тестовый объект. Не нужно включать пароли, токены или содержимое настоящих документов. Исправление оценивают по соблюдению правила на сервере, а затем повторно проверяют как разрешённый, так и запрещённый сценарий. Если после изменения никто не может открыть даже свой документ, утечка может исчезнуть, но нужная функция остаётся сломанной. Безопасность и работоспособность проверяют вместе.
Попробуйте на практике
Составьте матрицу прав и учебный отчёт без обращения к сайту. Используйте только условные аккаунты А, Б и документы ДА, ДБ.
- Запишите четыре сценария чтения: А открывает ДА, А открывает ДБ, Б открывает ДБ, Б открывает ДА. Отметьте два разрешённых и два запрещённых случая.
- Задайте вымышленное наблюдение: А получает содержимое ДБ. Сравните его с заранее установленным правилом, не меняя правило после результата.
- Составьте короткое описание ошибки: кто обращался, какой тестовый объект запрошен, что ожидалось и что произошло.
- Перечислите сведения, которые не нужны в отчёте: реальные личные данные, пароли и токены. Оставьте только условные метки для воспроизводимости.
- После условного исправления повторно оцените все четыре сценария. Проверьте, что собственные документы доступны, а чужие не раскрываются.
Как проверить результат. В матрице ровно два разрешённых случая. Отчёт доказывает нарушение авторизации на тестовом объекте, не раскрывая секретов. Проверка исправления сохраняет законную функциональность и не ограничивается исчезновением одного ответа.
Частые вопросы
Сложный случайный идентификатор устраняет такую ошибку?
Он может затруднить угадывание, но не заменяет проверку прав. Если идентификатор станет известен другим способом, сервер всё равно должен определить, разрешён ли доступ этому пользователю.
Можно ли проверить любой открытый сайт ради обучения?
Публичная доступность не означает разрешения на тестирование. Для практики используют собственную учебную среду или явно разрешённую площадку в её установленных границах. Бумажный пример позволяет понять логику без внешних действий.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.