- Порезанный
- 23 сентября 2026 г. в 01:16 UTC
- Автор
- Kamo
- Обещать
- 6488bd4
RagSearchController читает orgId/memberId/memberType с тела JSON на каждом Путь, включая запросы, заверенные сессией ***, а не X-Internal-Auth. Зарегистрированный участник, имеющий только VIEW KB ARTICLES, может Идентификатор другой организации или идентификатор другого члена в теле и искать, что База знаний организации или личные заметки этого члена прямо через Qdrant's Фильтры — сеанс доказал, кто спрашивал, но никогда не ограничивал то, что они спрашивали. Можно попросить. /reindex/{orgId} и /status/{orgId} имели одинаковую форму Уровень вверх: путь orgId был доверен, когда абонент держал MANAGE KB SETTINGS в *некоторых* организациях, не проверяя их. Усугубляя ситуацию, SessionHelper.hasRight вернулся к истинной для сессии. пустой список прав и снова для тех, у кого нет поля прав вообще, поэтому право Проверки, охраняющие все три конечные точки, пропускались одним и тем же недостающим полем. Правило сейчас: на пути сеанса org/member/memberType являются производными от только ******************* Добавлено в SessionHelper переиндекс/статус дополнительно требуют, чтобы путь orgId был равен самому сеансу Org. hasRight проваливается, совпадая с KBService. Путь X-Internal-Auth AIService не имеет собственной сессии и все равно должен назвать, кто это Поиск в теле. Также переключается секретное сравнение X-Internal-Auth с String.equals на MessageDigest.isEqual, так что разница во времени не может утечь секретный байт В свое время. Тесты: SessionHelperRights Тест показывает закрытые случаи (зеркала KBService) люкс. RagSearchControllerAuthzTest прикрепляет баг доверия к телу и проверка реиндекса/статуса и отдельно доказывает, что путь внутреннего аудита все еще Доверяет телу (единственный способ AIService назвать это). Каждый был проверен красным. против префиксного кода перед этим обязательством.