- Verschifft
- 23. September 2026 um 08:54 UTC
- Autor
- Kamo
- Ausschuss
- da4e9f3
Findet 2-6 aus dem Telefon-System-Audit, zusammen behoben, weil mehrere Dateien teilen. 2. HIGH - VoipInstanceController hatte keine richtige Kontrolle auf einen mutierenden Endpunkt **************** jedes angemeldete Mitglied der Org, nicht nur sein VOIP Administratoren, könnte erstellen, löschen oder neupointieren die Anmeldeinformationen eines Telefonservers. Jetzt erforderlich MANAGE_VOIP_SETTINGS, die gleichen rechten Einstellungen -- Features -- Telefon selbst ist gated auf. Außerdem: platformUrl/baseUrl waren nicht validiert, so dass ein Mitglied RingCentrals Token-Minze zeigen konnte (der den echten ClientId/clientSecret + JWT der org sendet) oder einen FreePBX GraphQL Client an einen Host ihrer Wahl und Erfassung Anmeldeinformationen, oder erreichen Sie das Pod-Netzwerk (Redis/MinIO/Yugabyte alle Antwort nicht authentifiziert, kein egress NetworkPolicy). Behoben mit PhoneServerUrlGuard: RingCentral ist jetzt auf die eigenen zwei Hosts beschränkt (Produktion/Sandkasten); FreePBX bekommt die allgemeine Öffentlichkeit-only SSRF-Check auf Kamo-Shared-Bibliothek PublicHostGuard (die gleichen primitiven SecurityServices gebaut SafeSiteFetcher und aiservice's OutboundUrlGuard verwenden). Sowohl RingCentralJwtTokenService's als auch FreePBXTokenCache's TokenCache's wurden ohne den Wirt beschlagnahmt, so dass ein lebender Träger-Token geprägt wurde gegen den echten Host würde nach einer PlatformUrl/baseUrl-Bearbeitung immer wieder an einen neuen gesendet -- beide Cache-Tasten jetzt enthalten. mergeConfig lässt nicht mehr ein maskiertes "***" geheim fahren entlang zu einem neu eingestellter Host (muss wieder eingegeben werden), nie vereint KamoPBX's server-assistented accountId/realm von ein Client, und Test Connection / manuelle Sync nicht mehr Echo eine rohe Ausnahme-Nachricht (die könnte den Zielhost oder ein Antwortfragment zurück zum Anrufer übertragen). Telnyx's apiKey hinzugefügt SECRET_FIELDS. 3. HIGH - MemberVoipConfigController's PUT überprüfte nur, ob sich das Zielmitglied im Caller befand org. Jedes angemeldete Mitglied könnte einen COLLEAGUE's ************ umstellen und SipController.getSipCredentials gibt jede Erweiterung zurück, die derzeit zugewiesen ist -- gleichorg-Konto-Übernahme primitiv, nicht nur eine IDOR. Jetzt erfordert MANAGE_EXTENSIONS oder MANAGE_VOIP_SETTINGS bedingungslos, passend zu den Einstellungen UI eigenen Kommentar, dass die Erweiterung Zuweisung wird admin-managed und nie self-service. instanceId wird nun auch mit der Caller org -- zuvor ein Telefon-Server von einer anderen Organisation genannt werden konnte und, wenn Eine seiner Erweiterungen sei zufällig nicht zugeordnet worden, behauptet. 4. HIGH - keine Rechte-Prüfungen an: ************ (Erstellung/Update/Löschen/auslöschen/ test/test-send/send), VoipDevicesController, VoipUsersController, VoipExtensionsController, VoipOrgAggregateController, OrgPhoneNumberController, MemberPhoneNumberController. Die meisten jetzt erforderlich, dass der entsprechende Kamo-interne Bildschirm selbst eingegeben wird (MANAGE_VOIP_SETTINGS für Telefon-Server Inventar/Zahlen-Bildschirme, ************ für Erweiterungszuweisungen). VoipOrgAggregateController's /org/Voicemails zusätzlich erforderlich VIEW_VOICEMAIL speziell (passend VoipVoicemailController, nicht der org-Aggregate Default) und gewann den gleichen PHI Transkript-Enthüllungs-Audit-Call. BulkTextInstanceController's /send gesendet beliebige SMS ohne Outbound-Ein-/Suppression-Güro -- es verweigert jetzt (409) eine Zahl, deren neueste TCPA_SMS ConsentRecord ist REVOKED, Lesen des WORM-Ledegers SmsKeywordService bereits schreibt auf jedem eingehenden STOP/START, also ein STOP zu einem anderen org blockiert eins. MemberPhoneNumberController ist die einzige Ausnahme von "Admin Recht erforderlich, Zeitraum": im Gegensatz zu VOIP Erweiterung/Instanzzuweisung (Ergebnis 3, überhaupt kein Self-Service-Pfad durch explizites Produkt Entscheidung -- die Einstellungen UI eigenen Kommentar sagt so), die Einstellungen / Mitglied Phone Registerkarte MemberTextNumbersCard bietet jedem Zuschauer volle Self-Service-Steuerungen (zustruieren/entfernen/make-primary) über ihre eigenen OWN-Nummern ohne eigenes Admin-only-Gate -- diese Seite ist auf ACCESS_VOIP erreichbar allein, per eigenen Kommentar: "ACCESS_* deckt den Benutzer ab, der seine eigenen Einstellungen verwaltet; MANAGE_* deckt Adminier, die im Auftrag eines Mitglieds konfigurieren". So bekam dieser Controller eine Selbst-oder-Admin-Regel statt (Spiegel ************ bestehende Form): ein Mitglied schafft ihre eigenen Zahlen ohne besonderes Recht; Handeln auf der eines Kollegen erfordert immer noch MANAGE_EXTENSIONS oder MANAGE_VOIP_SETTINGS. Eine Admin-only-Regel hier hätte 403'd jedes ACCESS_VOIP-only-Mitglied aus einer Karte, die heute funktioniert. 5. MEDIUM **************** der einzigartige Index auf ORG_PHONE_NUMBER ist (org_id, phone_canon), nicht (phone_canon) allein (absichtlich, so dass die Historie einer portierten Nummer kann existieren unter zwei Organisationen im Laufe der Zeit) -- aber nichts hielt eine ZWEITE org von der Schaffung seiner eigene Zeile für eine Zahl, die eine bereits aktiv aktive FIRST org gehalten hat, da get()/findByNumber() org-scoped und würde einfach nicht finden, die andere org-Reihe. save() weigert sich nun, eine neue Zeile zu erstellen, wenn eine andere oder org hat bereits einen aktiven Anspruch auf die gleiche Zahl; Entdeckung (die fragt den Anbieter sich, echte Beweise für Eigentum) ist unberührt. MemberPhoneNumberService's assign/unassign/ setPrimary/forMember validierte NummerId gegen die Org, aber überhaupt nie MitgliedId -- kombiniert mit assign()'s write-through zu MemberVoipConfig (von Mitglieds-ID allein aufgeschaut), ein Anrufer in einem org könnte eine REAL MEMBER OF A DIFFERENT ORG's Outbound Caller id auf ihr eigenes Telefon neu ausstellen Infrastruktur. requireMemberInOrg ist die Lösung. 6. LOW (perf) - InstanceSyncService hat jede zwischengedeckte Erweiterung/Benutzer/Devicice/Devicicemail-Reihe auf jeder Sweep mit einem gestoßenen DatumAktualisiert, auch wenn der Anbieter nichts anderes gemeldet -- 23k vermeidbare UPDATEs/Tag. Jede der vier Sync-Methoden vergleicht jetzt jedes Feld vor dem Schreiben es und spart nur, wenn sich tatsächlich etwas verändert hat. Tests: PhoneServerUrlGuardTest, **************************************** RingCentralJwtTokenServiceTest (neuer Fall), FreePBXTokenCacheTest, ************ ******************************************************** **************************** (Selbstbedienung erlaubt, Cross-Mitglied erfordert das Admin-Recht, beide Rechte akzeptiert), ************ Rechte nur Ergänzungen zu ************ wurden verifiziert durch Code Review und Full-Suite-Zusammenstellung statt eines dedizierten Tests pro Controller -- das Muster ist identisch und bereits abgedeckt von **************** und ******************** Jeder Wächter oben wurde mutation-geprüft (vor Ort umgedreht, bestätigt, dass der passende Test rot wird, restauriert). Drei bereits bestehende VoipInstanceController Tests ************ VoipInstanceJustCallIdTest, **************** vor der Suche 2 und baute ihre Sitzung ohne Rechte Liste überhaupt; sie enthalten jetzt MANAGE_VOIP_SETTINGS, so dass sie immer noch das Verhalten ausüben, für das sie geschrieben wurden (Provisioning Versuchen Sie, JustCall id Adoption, JWT-shape Validation) anstatt Stolpern der neuen rechten Überprüfung zuerst. ************ FreePBX Fall tauschte auch einen nicht auflösenden "pbx.example.com" Platzhalter für eine wörtliche IP, da PhoneServerUrlGuards baseUrl-Check jetzt eine echte DNS-Suche durchführt. Bericht für den Koordinator: keine Schema-Änderungen, keine Konfigurationsänderungen, keine Gateway-Änderungen für diese sechs Ergebnisse (nur der Feststellung 1 Bericht hat eine operative Follow-up). Bestätigt gegen apiservice: es leitet /api/voip/** Großhandel, so dass die Ergebnisse 2, 3, 5 und 6 dort nichts brauchen. BulkTextInstanceController (Ergebnis 4) sitzt bei /api/bulktext/instances/**, welche apiservice absichtlich NICHT Wildcard (nur /api/bulktext/inbound/** ist öffentlich, bewacht die interne X-Internal-Auth /api/bulktext/send aus dem Internet erreichbar) -- aber es nie benötigt, um: kamo-internal eigenen Server erreicht es direkt über **************** die Proxys zu VOIPSERVICE_URL, unter Umgehung der Öffentlichkeit Gateway ganz. Auf beiden Seiten kann sich nichts ändern.