- Se descapó
- 26 de agosto de 2026 a las 5:17 UTC
- Autor
- Kamo
- Compromit
- 6a6662a
Cada endpoint que aceptaba un derecho de VERDEW* como una alternativa de quirófano cargaba su registro por clave primaria por sí solo, nunca comprobar a quién pertenecía: getSubscription, getSubscriptionOrder, getSubscriptionEventos, getInvoice, getSubscriptionAgreement y getSubscriptionAgreementHtml. orgId se leyó para el 401 y nunca se utilizó otra vez. Una persona que tenga solo el cliente puede leer cualquier suscripción, orden, factura o acuerdo en la plataforma dada su UUID. Puntos finales que sólo aceptan el VERDE-W-W* right alone (getMySubscriptions, getMySubscriptionOrders, getMyInvoices, getMyAgreements) ya se deriva miembro de la sesión y se quedó intacto. pasa miembroId al servicio y quedó intacto por la misma razón, aunque el servicio en sí no verifica el aceptador posee el subyacente suscripción... esa brecha vive en SuscripciónServicio, fuera de este archivo el alcance, y se observa para el seguimiento en lugar de arreglado aquí. SubscriptionRecordDTO, SubscriptionOrderDTO y SubscriptionInvoiceDTO exponer clienteMemberId directamente, por lo que esos cuatro endpoints se filtran después de la venta por Compararlo con el miembro de la sesión del que llamóId. SuscripciónAcuerdoDTO expone ni un miembro ni un campo de propietarios directos - sólo organizaciónId y el uid de la suscripción a la que pertenece, por lo que los dos endpoints de acuerdo resuelven propiedad cargando esa suscripción y comprobando su clienteMemberId En vez de eso. 404, no 403, en un desajuste de propiedad: un 403 confirmaría los nombres de UUID a registro real en otro inquilino, que es a sí mismo una revelación. Nombrado como el contraejemplo en la propia invarita del diseño del programa 6.