- Spegnimento
- 23 settembre 2026 alle ore 01:16 UTC
- Autore
- Kamo
- Impegno
- 6488bd4
RagSearchController leggere orgId/memberId/memberType dal corpo JSON su ogni percorso, comprese le richieste autenticate da una *** sessione piuttosto che X-Internal-Auth. Un membro firmato con solo VIEW KB ARTICLES potrebbe mettere un diverso org's id, o un membro diverso id, nel corpo e cercare che la base di conoscenza di Org o le note private di quel membro direttamente attraverso Qdrant filtri — la sessione ha dimostrato chi chiedeva, ma non ha mai ostacolato ciò potrebbe chiedere. /reindex/{orgId} e /status/{orgId} avevano la stessa forma livello su: il percorso orgId è stato fidato una volta che il chiamante ha tenuto MANAGE KB SETTINGS in *some* org, senza controllare che fosse loro. Rendendolo peggiore, SessionHelper.hasRight ha reso vero per una sessione con una lista dei diritti vuoti e di nuovo per uno senza campo di diritti affatto, quindi il diritto i controlli di guardia di tutti e tre i punti finali sono stati sciolti dallo stesso campo mancante. La regola ora: sul percorso di sessione, org/member/memberType sono derivati dal **************************** aggiunto a SessionHelper) e reindex/status richiedono inoltre il percorso orgId per uguale la sessione org. hasRight fallisce chiuso, corrispondente a KBService. Il percorso X-Internal-Auth è — AIService non ha sessione propria e deve ancora nominare chi è cercando nel corpo. Inoltre ha cambiato il confronto segreto X-Internal-Auth da String.equals a MessageDigest.isEqual così una differenza di tempismo non può trapelare il byte segreto alla volta. Test: SessionHelperRights Perni di prova i casi chiusi (mirrors KBService's suite). RagSearchControllerAuthzTest pins il bug di fiducia del corpo e il reindex/status org check, e dimostra separatamente il percorso interno-auth ancora si fida del corpo (l'unico modo per chiamare questo). Ognuno è stato verificato rosso contro il codice prefisso prima di questo commit.