- Verschifft
- 26. August 2026 um 05:17 UTC
- Autor
- Kamo
- Ausschuss
- 6a6662a
Jeder Endpunkt, der ein VIEW_OWN_* richtig als OR-Alternative akzeptiert hat, lud sich Datensatz mit dem Primärschlüssel allein, nie überprüfen, wem es gehörte: benennenBeschreibung, erhalten Sie Abonnement-Events, getInvoice, getAbonnementvereinbarung und erhaltenSubscriptionAgreementHtml. orgId wurde für die 401 gelesen und nie verwendet wieder. Ein Anrufer, der nur das Recht des Kunden hält, konnte jedes Abonnement abrufen, bestellen, in Rechnung oder Vereinbarung auf der Plattform angesichts ihrer UUID. Endpunkte, die nur die VIEW_OWN_*-Allein akzeptieren (getMySubscriptions, getMySubscriptionOrders, getMyInvoices, getMyAgreements) bereits abgeleitet memberId von der Sitzung und wurden unberührt gelassen. akzeptierenVereinbarung bereits geht MitgliedId an den Dienst weiter und wurde aus dem gleichen Grund unberührt gelassen, obwohl der Dienst selbst nicht überprüft, der Akzeptär besitzt die zugrunde liegenden Abonnement -- diese Lücke lebt in SubscriptionService, aus dieser Datei erreichen, und ist für Follow-up und nicht fixiert hier. AbonnementRecordDTO, AbonnementauftragDTO und AbonnementInvoiceDTO aussetzen customerMemberId direkt, so dass diese vier Endpunkte-Filter nach dem Fetch von Vergleicht man es mit dem Sitzungsmitglied des Anrufers. AbonnementEinigungDTO entlarvt weder ein Mitglied noch ein direkter Eigentümer-Feld -- nur OrganisationId und die uid von das Abonnement gehört es zu -- so die beiden Vereinbarung Endpunkte zu lösen Eigentum durch Laden dieses Abonnements und Überprüfung seiner KundenMitgliedId statt. 404, nicht 403, bei einem Eigentumsungleichverhältnis: ein 403 würde die UUID-Namen bestätigen echte Aufzeichnung in einem anderen Mieter, die selbst eine Offenlegung ist. Benannt als Gegenbeispiel in der eigenen Invariante 6 des Programms.