Confuso sul modo più pertinente per proteggere le mie API

1

Possiedo un'applicazione JavaScript (Single Page Application) che colpisce alcuni apis dal mio backend RESTful.

Quello che mi aspetto per il mio meccanismo di autenticazione / (autorizzazione) è tre cose:

  • Prevenzione di tutti i modi maligni conosciuti di rubare o agire sui dati dell'utente: CSRF, XSS, ecc.
  • Consentendo solo al mio client ufficiale Javascript di raggiungere l'API protetta del mio back-end.
  • Crittografia di tutti i messaggi scambiati.

Non sono esperto in sicurezza ma ho letto alcuni buoni articoli su una linea guida da seguire:

  • Evita un modo di autenticazione basato SOLO sul meccanismo dei cookie, come questo l'articolo spiega bene.
  • HTTPS non è sufficiente, tuttavia è davvero consigliabile garantire almeno la crittografia dei messaggi.
  • Considera il client Javascript completamente non protetto poiché il suo codice è visibile a chiunque.

Certo, sono d'accordo con questi principi ma ... sono confuso dal numero di modi simili per ottenere un buon meccanismo di autenticazione:

  • Qual è la differenza tra l'articolo che ho inserito nel link appena sopra e il flusso di credenziali della password del proprietario delle risorse di OAuth 2.0?
    In effetti, entrambi usano questi passaggi: scambiare nome utente e password per un token di accesso che è a sua volta inviato lungo la navigazione dell'utente utilizzando l'intestazione di autorizzazione HTTP.
    Quale aspetto di sicurezza aggiuntivo offre questo flusso di lavoro OAuth 2.0 rispetto alla soluzione token basata su cookie?

  • La soluzione del token basato sui cookie come presentato nell'articolo è davvero sufficiente per proteggere la mia infrastruttura? Come afferma l'autore ..

  • Mi sono imbattuto in questa un'altra grande soluzione, che giudico anche simile ad altri, con la differenza che non ha realmente bisogno di https poiché basato sulla chiave segreta condivisa: meccanismo HMAC.

Cosa mi consiglierebbe un esperto di sicurezza? Non cambio dati veramente sensibili come conti in denaro ecc. Ma abbastanza dati da infastidire gli utenti se succede qualcosa di inaspettato ..

Sarei felice di essere più chiaro (nei commenti), ma spero di esserlo.

Mi sono imbattuto in così tanti forum, articoli, video, ecc ... ma sono ancora confuso su questi diversi modi di realizzare la cosa.

Grazie

    
posta Mik378 17.04.2014 - 17:32
fonte

1 risposta

2

La differenza è: OAuth 2.0 è un protocollo standardizzato, e ci sono molte implementazioni in diverse lingue (JAVA , Python, PHP, JavaScript ... ecc.) Per lato client e server. Quindi non è necessario seguire questo articolo per implementare qualcosa che "sembra" simile al protocollo OAuth 2.0 e probabilmente non protetto.

Per la soluzione token basata su cookie: un utente malintenzionato può forse ancora un cookie da un utente registrato (autorizzato).

Quindi, penso che la soluzione migliore sia usare il protocollo OAuth 2.0 che è già utilizzato da molte aziende (facebook, twitter) per le loro API

    
risposta data 18.04.2014 - 13:13
fonte

Leggi altre domande sui tag