- Порезанный
- 26 августа 2026 г. в 05:17 UTC
- Автор
- Kamo
- Обещать
- 6a6662a
Каждая конечная точка, принявшая право VIEW OWN * в качестве OR-альтернативы, загружала свое Запись только по первичному ключу, никогда не проверяя, кому она принадлежала: получить Подписку, getSubscriptionOrder, getSubscriptionEvents, getInvoice, getSubscription Соглашение Соглашение HTML. orgId было прочитано для 401 и никогда не использовалось. Опять. Абонент, имеющий право только на клиента, может прочитать любую подписку. заказ, счет или соглашение на платформе с учетом его UUID. Конечные точки, которые принимают только VIEW OWN * (получить MySubscriptions). getMySubscriptionOrders, getMyInvoices, getMyAgreements Член вышел из сессии и остался нетронутым. Принять соглашение уже передает участника на службу и оставлен нетронутым по той же причине, несмотря на то, что сама услуга не проверяет, владеет ли принимающая сторона базовым Подписка - этот разрыв живет в SubscriptionService, из этого файла В этом случае он должен быть выполнен, а не закреплен. SubscriptionRecordDTO, SubscriptionOrderDTO и SubscriptionInvoiceDTO CustomerMemberId напрямую, так что эти четыре конечные точки фильтруются после получения Сравнение с членом сеанса абонента. ПодпискаСоглашениеDTO разоблачает не является ни членом, ни непосредственным владельцем — только организация и руководство подписка, к которой он принадлежит, так что две конечные точки соглашения решают право собственности путем загрузки этой подписки и проверки ее клиента Вместо этого. 404, а не 403, на несоответствие собственности: 403 подтвердит имена UUID реальной записи у другого арендатора, что само по себе является раскрытием. Назван в качестве контрпримера в собственном инварианте 6 дизайна программы.