Lavoro per un'università, dove faccio parte del team responsabile dell'integrazione di un sistema di gestione dell'apprendimento SaaS (ad esempio: Moodle, Canvas) con il resto dei sistemi dell'università.
Due mesi fa, ho identificato un attacco CSRF, disponibile a tutti coloro che possono aggiungere materiale didattico al sistema (per lo più docenti, ma anche altro personale accademico e tutor). Il problema è che i materiali del corso possono contenere javascript e qualsiasi utente amministratore che visualizza i materiali del corso (ad esempio: in risposta a una richiesta di supporto) eseguirà il javascript. Poiché il sistema ora dispone di un'API REST (documentata pubblicamente!), È possibile che detto javascript, tra le altre cose, elevi qualsiasi utente come amministratore di sistema. In particolare, il sito Web stesso utilizza l'API REST in tutto, il che significa che javascript deve essere in grado di effettuare chiamate API. Ho sviluppato demo di exploit funzionali, quindi so per certo che funziona e quanto sia facile da fare.
L'ho riferito al venditore, e la loro risposta immediata è stata "I docenti sono utenti fidati, funziona come progettato". Al che la mia risposta irata era "Non mi fido dei docenti di essere amministratori di sistema". Secondo una semplice query DB, nel sistema sono presenti circa 4000 utenti che possono caricare materiali javascript, al di fuori di ~ 50000 utenti totali. Due mesi dopo, continuano ad attenersi alla loro risposta originale.
Sono un po 'preoccupato per il sistema della mia istituzione: ho implementato alcuni script di monitoraggio esterni per dirmi se appaiono degli amministratori inattesi, e abbiamo dei backup offline, il che è tutto ciò che posso pensare di fare. Tuttavia, mi preoccupo anche che questo exploit abbia effetto su tutte queste installazioni in tutto il mondo, ed è un sistema a esecuzione corrente (probabilmente 1000 istanze).
Poiché questo è SaaS, non abbiamo abbastanza accesso al sistema per poterlo bloccare da soli.
Quindi ho un gruppo di domande correlate:
- Questo attacco è accettabile o almeno comune tra i sistemi aziendali di grandi dimensioni?
- Credo che il wrapping del contenuto generato dall'utente in un iframe con l'attributo sandbox bloccherebbe questo attacco (ammesso che gli amministratori utilizzino browser aggiornati), utilizzando CORS per impedire richieste all'API REST. È sicuro? È altrimenti possibile rendere javascript caricato dagli utenti sicuro?
- Se il venditore si rifiuta di ripararlo, quali sono le mie prossime mosse? Si raccomanda la divulgazione pubblica, dato che è abbastanza facile sfruttarlo una volta noto?
EDIT : per rispondere ai commenti:
Ammetto di essere un po 'confuso sulla differenza tra csrf e xss, nonostante la lettura di articoli su di esso. Con questa definizione è XSS in quanto "esegue in qualche modo uno script" , ma è CSRF in quanto deve "utilizzare cookie / sessione già registrati di una vittima". Inoltre, il token che è la chiave per l'exploit è chiamato token csrf dal fornitore.
Ecco alcuni dettagli su come funziona l'exploit / mitigation, per (2). Anche se hai ragione; questa dovrebbe essere davvero una domanda a parte.
L'attacco deve includere una richiesta di fetch nel javascript fornito che esegue una richiesta di PATCH REST contro l'API appropriata, nel qual caso il cookie della vittima viene utilizzato come autenticazione per l'API. Le richieste non GET richiedono un'intestazione personalizzata (un token 'xsrf'), ma è possibile che il javascript in dotazione scriva quel token da un'altra pagina.
Per quanto riguarda la mitigazione proposta: i contenuti del corso, incluso tutto il javascript fornito dall'utente, sono attualmente racchiusi in un singolo div . Propongo di sostituire div con iframe che recupera separatamente i contenuti dell'utente (o utilizza srcdoc ) e ha un attributo sandbox senza il flag allow-same-origin . Ciò significherebbe che lo script non avrebbe accesso al cookie di autenticazione e non sarebbe comunque in grado di inviare richieste di recupero all'API a causa di CORS.