Secure code review: ручное ревью кода и поиск уязвимостей в веб-приложении

Сначала карта, потом чтение

Первые дни уходят на то, чтобы понять, что в приложении ценно: деньги, персональные данные, документы, административные действия. С вашим разработчиком помечаем участки, где ошибка стоит дороже всего, и читаем с них.

От ввода к опасному месту

Основной приём: берём данные, пришедшие снаружи, и идём по коду до места, где они что-то делают: попадают в запрос, в путь к файлу, в страницу, в решение о доступе. Если по дороге данные проверены, дальше не идём. Если нет, строим сценарий и воспроизводим его на тестовом стенде или локальной копии. Находка без воспроизведения помечается как «вероятная», и в отчёте это видно.

Программа и человек

Анализаторы кода, проверка зависимостей и поиск секретов запускаются в первые дни: они дёшевы и находят шаблонные ошибки. Каждое срабатывание читает человек: часть окажется ложной, часть относится к коду, который не выполняется. Серьёзность определяется после чтения, а не по метке сканера. Часть замечаний снимает короткий ответ разработчика на вопрос «зачем здесь так»: тогда это пояснение, и оно попадает в отчёт.

• Место. Файл, функция, строка на конкретной ревизии репозитория: через месяц код изменится, а замечание должно остаться понятным.
• Сценарий. Что делает пользователь и что получает; для воспроизведённых находок приложены шаги.
• Серьёзность. По двум вопросам: насколько легко добраться и что будет потеряно.
• Правка. Не «исправьте проверку прав», а способ для вашего стека с примером изменения.
• Как убедиться, что закрыто. Тест или шаги, которые разработчик повторит после правки. Без них находка вернётся при следующем релизе.

Условный пример. В обработчике скачивания счёта документ берётся по номеру из адреса, принадлежность организации не проверяется. Сценарий: клиент меняет номер на соседний и получает чужой счёт. Серьёзность высокая. Правка: добавить условие по организации в выборку и вернуть одинаковый отказ на чужой и на несуществующий номер. Проверка: тест, где клиент А запрашивает документ клиента Б и ожидает отказ.

Разовое ревью отвечает на вопрос «что сейчас». Через несколько релизов ответ устаревает: добавился обработчик, кто-то поправил проверку «временно». Поэтому ревью встраивают в процесс команды, и брать эти уровни можно по очереди:

• Чек-лист к запросу на слияние. Пять-семь вопросов под ваш стек и ваши роли: проверены ли права, не попадает ли ввод в запрос, нет ли секретов в коде.
• Обязательный проверяющий для чувствительных мест. Изменения в коде входа, прав, платежей и загрузки файлов не сливаются без отдельного согласующего. В GitLab и GitHub для этого есть файл владельцев кода.
• Автоматические проверки в сборке. Анализатор кода, проверка зависимостей и поиск секретов на каждое изменение. Правила подбираем под проект, чтобы ложные срабатывания не приучили команду нажимать «пропустить».

Перед крупным релизом мы читаем изменённые рискованные участки и отвечаем письменно. Это входит в сопровождение пакетами часов.

Ревью кода на уязвимости отвечает на вопрос «что не так в коде»: читаем исходники и конфигурацию, воспроизводим находки на вашем стенде, объясняем, как исправить.

Аудит безопасности веб-приложения шире: все категории OWASP Top 10, проверки на стенде, разбор окружения. Для одного сервиса и вопроса про код хватит ревью, для подтверждения клиентам по всему приложению берите аудит. Аудит кода и архитектуры отвечает на другой вопрос: можно ли систему развивать и сопровождать.

Пентест — попытка взлома боевой системы по согласованным правилам. Мы его не проводим, аттестацию не проводим, лицензии ФСТЭК у нас нет. Если нужно именно это, нужна другая организация, и мы скажем об этом на первом созвоне.

Вход сотрудников и единый вход разобраны на странице SSO и MFA, защита программного интерфейса от перебора и обхода прав — в статье «Как защитить API от взлома».