Prevenzione di CSRF / XSS su API condivise mobile / web

0

Ho ereditato un code-base che include un dispositivo mobile e amp; app web che accedono entrambe alla stessa API e sono state incaricate di correggere alcuni dei buchi di sicurezza esistenti, sfortunatamente non sono esperto nell'argomento. Ora capisco che le vulnerabilità che sto osservando si applicano solo al web, ma vorrei minimizzare le modifiche richieste sul terminale mobile, e dal momento che questo servizio coinvolge entrambi, sto cercando consigli sulla situazione.

Sia web che amp; mobile riceve un token di accesso memorizzato in un cookie sicuro che utilizza per accedere all'API. Questo funziona perfettamente bene per il lato mobile, ma è aperto a CSRF sul web. Usando il SOP e la nostra politica CORS, siamo in grado di disabilitare altre origini dalla lettura dei dati, ma ovviamente possono ancora apportare modifiche al server (ad es. Cancellare, aggiornare).

Una soluzione che è stata creata è quella di passare alla memorizzazione del token di accesso nell'archivio Web in modo da non essere vulnerabili agli attacchi CSRF (perché sono protetti da domini). Questo naturalmente ci aprirà alle vulnerabilità XSS ma, per quanto a nostra conoscenza, l'app Web è sicura a tale riguardo (tutti gli input dell'utente sono disinfettati e convalidati e nessun input dell'utente viene emesso direttamente nel DOM). Ma, mi è stato detto (non riesco a trovare riferimenti) che i plug-in del browser possano iniettare il codice nel DOM e avere libero accesso a quei valori di archiviazione che rendono la nostra sicurezza sostanzialmente discutibile.

Un'altra soluzione sarebbe quella di utilizzare una delle soluzioni delineate nel foglio cheat CSRF ma richiederebbe uno stato extra sul server e riscrivere il modo in cui i client mobili gestiscono i loro cookie e richieste e non è l'ideale.

Quindi una soluzione migliore di cui sopra sarebbe quella di separare il web & API mobili per consentire le soluzioni di vulnerabilità CSRF senza dover apportare modifiche alle app mobili.

Quindi sono curioso che cosa suggerirei sarebbe la soluzione migliore a questo problema, o forse mi manca qualcosa che potrebbe essere una soluzione più semplice (ad esempio CSP, non sono sicuro che sarebbe in grado di prevenire certi XSS fori?).

    
posta Malcolm 04.04.2018 - 20:08
fonte

1 risposta

1

Penso che la soluzione migliore sarebbe spostare il token di accesso da un cookie all'archiviazione locale. È semplice ed efficiente.

Quindi, per quanto riguarda le preoccupazioni sollevate? Hai ragione che questo espone il token a XSS. Ma se si hanno vulnerabilità XSS, in ogni caso è effettivamente game over. La bandiera HttpOnly è un fastidio per un attaccante, non è una difesa solida. Non sceglierei un design più complicato solo per poter tenere il token lontano da JS. Invece, dedica il tuo tempo a risparmiare sulle attuali vulnerabilità XSS!

Per quanto riguarda i plug-in per browser dannosi, non è possibile difendersi da loro, indipendentemente da dove si memorizzano i token. Se il client è stato infettato da malware, hai già perso. Quindi, dal punto di vista di uno sviluppatore di API, non ha senso cercare di difendersi da questo scenario. I tuoi utenti devono mantenere pulite le loro macchine; se falliscono, non c'è nulla che tu possa fare per loro.

La suddivisione dell'API consente di svolgere più attività di manutenzione in futuro e nega l'intero vantaggio dell'utilizzo di un'API. Per me, puzza come una brutta soluzione di emergenza di cui starei lontano.

Infine, un CSP rigoroso è sempre una buona idea. Non è un proiettile d'argento, ma sicuramente aiuta molto.

    
risposta data 05.04.2018 - 15:04
fonte

Leggi altre domande sui tag