Запланированное и реализованное: анализ разрыва

Цель

Линтер сканирует код в отрыве от контекста. Он может сказать вам, что код внутренне согласован; он не может сказать вам, что код делает то, что вы имели в виду, потому что у него нет модели вашего замысла. Самые опасные ошибки, связанные с безопасностью и корректностью, скрываются именно в этом разрыве — разрешение, задокументированное, но никогда не применяемое; конечная точка, доступная только через cron, к которой может обратиться любой; поле, помеченное как public-only, из которого утекают частные данные.

Этот навык — метод выявления этого разрыва. В нём заключается отличительная особенность: он работает только в том случае, если замысел был сначала зафиксирован в письменной форме (см. навык «артефакты выпуска»), и именно поэтому стандартные инструменты не могут его воспроизвести.

Контекст

Используйте этот навык, когда задокументированные намерения существуют — permissions.md, architecture.md, variables.mdи т. д. Если такая документация отсутствует или устарела, само это отсутствие уже является первым обнаружением: невозможно провести аудит намерения, которое никогда не было зафиксировано. Рекомендуется сначала составить документацию, а затем проводить аудит.

Метод

1. Определите намерения. Воспринимайте /documentation/*.md набор документов в качестве достоверного источника информации о том, что должно быть: кто может получить доступ к чему, какие границы считаются надежными, какие данные являются общедоступными. Рассматривайте документы как утверждения, подлежащие проверке, а не как доказательства.

2. Соберите доказательства реализации. Прочитайте код, который обеспечивает (или не обеспечивает) соблюдение каждого утверждения. Доказательством является указанный файл и строка — фактическая проверка авторизации, фактический фильтр запроса, фактический санитайзер. «Вероятно, это обрабатывается на верхнем уровне» — это не доказательство; доказательством является путь кода.

3. Сравнивайте утверждения с кодом, по одному уровню доступа за раз. Для каждого задокументированного правила задавайте вопрос: действительно ли точка проверки его реализует — на сервере, по каждому пути? Не доверяйте комментариям вроде «только для внутреннего использования», «только для администраторов» или «проверяется в другом месте» — проверяйте их в коде.

4. Классифицируйте каждое несоответствие в зависимости от его значимости. Несоответствие имеет значение, если его преодоление позволяет реальному злоумышленнику получить доступ к данным, деньгам, инфраструктуре или другому клиенту, к которым он не должен иметь доступа. Оно не имеет значения, если единственным затронутым лицом является сам злоумышленник, действующий в отношении собственных данных. Игнорируйте косметические отклонения; фиксируйте отклонения, связанные с пересечением границ.

5. Избегайте неопределённых выводов. Каждый вывод должен содержать: задокументированное намерение (процитируйте документацию), реализованную реальность (ссылайтесь на код), злоумышленника и жертву, а также конкретное исправление. Если вы не можете сослаться на обе стороны несоответствия, это вопрос, требующий расследования, а не вывод, о котором следует сообщать.

Что имеет значение

• Намерение: задокументированное правило, граница, область действия или классификация «публичный/частный».
• Доказательство реализации: указанная точка проверки (или её доказуемое отсутствие) в коде.
• Существенное несоответствие: в документации сказано одно, а в коде реализовано другое, и это несоответствие затрагивает границы доверия, затрат, данных или арендаторов.

Примечания

• «Задокументировано, но не соблюдается» — это отдельный вывод; оценивайте его в зависимости от того, что выявляет данное несоответствие.
• «Недокументировано, но соблюдается» — обычно допустимо, но следует отметить это: документация устарела, что ослабляет результаты следующего аудита.
• Этот метод служит основой для аудитов безопасности и производительности; он не заменяет их анализ на уровне «приемников» — он добавляет ось «намерения», которой им не хватает.
• Никогда не выдумывайте намерения с целью создания пробела. Если в документации об этом ничего не сказано, просто укажите, что в документации об этом ничего не сказано.