From 0b109948427ce5ba8d39c7de8f2ea3e98d5c0160 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=9C=D0=B0=D0=BA=D1=81=D0=B8=D0=BC=D0=B5=D0=BD=D0=BA?= =?UTF-8?q?=D0=BE=20=D0=9D=D0=B8=D0=BA=D0=B8=D1=82=D0=B0=20=D0=92=D0=BB?= =?UTF-8?q?=D0=B0=D0=B4=D0=B8=D0=BC=D0=B8=D1=80=D0=BE=D0=B2=D0=B8=D1=87?= Date: Tue, 22 Sep 2026 00:29:43 +0300 Subject: [PATCH] docs: note the fail-open PD leak risk in ProcessResource Co-Authored-By: Claude Sonnet 5 --- todo.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 todo.md diff --git a/todo.md b/todo.md new file mode 100644 index 0000000..063b735 --- /dev/null +++ b/todo.md @@ -0,0 +1,26 @@ +# TODO + +## Утечка ПД в fail-open ветке ProcessResource + +`src/main/java/ru/pdguard/api/ProcessResource.java:104-109` — если `pipeline.process` +кидает `RuntimeException`, сервис отвечает `200 {"result": }`. + +Если сбой случился на прямом (маскирующем) шаге, наружу уходит необработанный +исходный ПД вместо маски — прямая утечка, которую весь сервис существует, чтобы +предотвращать. + +Почему не 5xx: по правилам НТ (Приложение B ТЗ) 5 подряд невалидных ответов +останавливают весь прогон, поэтому `200` был выбран сознательно, чтобы не срывать +проверку. Но текущий фолбэк меняет одну проблему (сорванный прогон) на другую +(утечка ПД) — само по себе решение не устраняет риск, а сдвигает его. + +Пробовал фикс — затирать буквы/цифры в payload перед возвратом (без утечки, +но и без осмысленного контента). Отклонён как сомнительный, отменён. + +Нужно придумать более осмысленный вариант: что именно возвращать при внутренней +ошибке так, чтобы одновременно (а) не утекал ни один символ исходных ПД и +(б) ответ не выглядел как случайная порча данных. Возможные направления для +обсуждения: частичное маскирование тем, что успело определиться до сбоя; +консервативный ответ вида "обработка недоступна" с фиксированным содержимым; +пересмотр самой стратегии (может, лучше редкий 5xx, чем гарантия небольшой +утечки).