Sfondo

Sto progettando un widget Web per un nuovo SaaS per l'incorporamento in un CMS protetto da password. Ciò consentirebbe al cliente di aggiungere qualcosa come il seguente a tutte le pagine del proprio CMS per visualizzare alcune informazioni dal mio sistema SaaS:

<script src="https://www.awesome-saas.com/widget.js?userToken=xyz"id="widget"/>

Quando un utente si registra con il sito Web del mio cliente, il mio cliente chiama la mia API per recuperare un UUID per il nuovo utente nel mio sistema SaaS. Questo è il token dell'utente. L'ID univoco utilizzato nel CMS del mio cliente non viene passato nella chiamata API. Il CMS del cliente memorizza l'associazione tra l'ID univoco dell'utente e il token fornito dal mio sistema. Nessuna informazione personale è memorizzata nel mio sistema (nessun nome, DoB, dettagli della carta di credito, ecc.). Questo approccio di generazione di token garantisce l'anonimato dei dati memorizzati nel mio sistema e garantisce la conformità dei dati sulla mia piattaforma.

Il CMS fornisce il token utente al mio widget javascript e il widget effettua una richiesta alla mia API passando il token dell'utente per recuperare uno snippet JSON da eseguire sulla pagina.

https://www.awesome-saas.com/getInfo?userToken=xyz

Lo snippet JSON che viene restituito non contiene alcuna informazione personale al suo interno.

Tutte le comunicazioni tra il CMS, il browser dell'utente e la mia API avvengono tramite SSL. Non c'è condivisione della sessione utente tra il CMS e il mio sistema SaaS.

Problema

How can I secure the requests to my API originating from the javascript widget whilst making it as easy possible for my customer to integrate my service with their CMS?

Alcune opzioni che ho considerato:

Opzione 1

Il passaggio del token UUID alla mia API SaaS è sufficiente. Sarebbe estremamente difficile da indovinare e anche se qualcuno fosse riuscito a farlo non saprebbe a chi sono i dati recuperati correlati.

Pro

• semplifica l'integrazione
• le risposte alla mia API possono essere facilmente memorizzate nella cache

Contro

• potrebbe essere una vendita difficile a clienti, auditor o regolatori
• è la sicurezza attraverso l'oscurità che non va bene

Vettori di attacco

• la cronologia del browser compromessa rivelerebbe il token utente
• l'ipotesi della forza bruta potrebbe essere fortunata

Opzione 2

Ottieni il CMS del cliente per crittografare tutti i token generati e condividere la loro chiave pubblica con noi. Il token crittografato viene passato alla mia API, lo decritto utilizzando la chiave pubblica del cliente.

Pro

• assicura che il token sia originato dal CMS del cliente piuttosto che da un forger bruto
• il brutto forcer ora deve cercare di indovinare una versione crittografata di un numero incredibilmente difficile da indovinare

Contro

• non può memorizzare nella cache le richieste alla mia API perché la crittografia sul token deve essere controllata ogni volta
• più lavoro per il cliente da integrare con me, ovvero cambio di codice

Vettori di attacco

• la cronologia del browser compromessa rivelerebbe un token utente crittografato