Perché abbiamo bisogno della sicurezza del servizio REST se disponiamo di HTTPS

13

Mi riferisco a questo eccellente articolo http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ che parla di Amazon come la sicurezza per il servizio web. Tuttavia, nel team mi è stata posta una domanda sul perché ne abbiamo bisogno se utilizziamo già HTTPS. Non sono stato in grado di rispondere in quanto sembra davvero che abbiano ragione, anche se budello mi dice il contrario.

Inoltre ci sono posti in cui fornire servizi REST in cui HTTPS potrebbe non funzionare? Ti piacciono i siti Web di terzi?

Se qualcuno ha esperienza nella protezione dei servizi Web sugli interweb pubblici, fare luce con la propria esperienza.

Grazie in anticipo.

EDIT: Per chiarire non sto parlando di autenticazione dell'utente ma più di autenticazione client. L'autenticazione dell'utente può essere considerata come testo normale su HTTPS + REST.

La mia preoccupazione è che ciò permetta ancora a chiunque di utilizzare il servizio Web senza che il mio client possa accedervi poiché tutto è semplice, anche se su HTTPS l'endpoint client può ancora utilizzare il mio servizio web senza l'applicazione client.

rest

— Abhishek Dujari
fonte

3

Più adatto per security.stackexchange.com ?

— jweyrich,

1

forse hai ragione ma la mia domanda è mor deve correlata.

13

Perché dobbiamo fornire a Gmail - o a qualsiasi altro sito con account utente - il nostro nome utente e password se utilizza già HTTPS? La risposta è uguale alla risposta alla tua domanda.

HTTPS fornisce innanzitutto una connessione crittografata tra il server e il client.

La fiducia inerente a HTTPS si basa sulle principali autorità di certificazione preinstallate nel software del browser (ciò equivale a dire "Mi fido dell'autorità di certificazione (ad esempio VeriSign / Microsoft / ecc.) Per dirmi di chi dovrei fidarmi").

A meno che il server fornisca a ciascun utente un certificato , il server non può fidarsi del client senza qualche altro metodo di autenticazione.

— Matt Ball
fonte

scusa se hai frainteso o non sono stato chiaro. I documenti di Amazon APi affermano che dovremmo usare HTTPS ma se non lo facciamo allora firmiamo la richiesta. La password del nome utente è irrilevante a questo punto.

3

A un livello elevato, è necessario dimostrare la propria identità al server affinché accetti i comandi da parte dell'utente. L'autenticazione client può essere eseguita tramite HTTPS e può anche essere eseguita utilizzando la firma dei messaggi.

— Matt Ball,

1

Se si desidera utilizzare HTTPS per l'autenticazione client, è necessario emettere a ciascun utente un certificato di chiave pubblica, come descritto nell'ultimo collegamento nella mia risposta. Pensa a questi certificati come alla versione elettronica di un passaporto.

— Matt Ball,

1

Link per "dare a ciascun utente un certificato", una risposta alle mie domande. Immagino che l'intera chiave pubblica privata e la firma siano ancora necessarie per proteggere correttamente entrambe le estremità in un servizio Web, quindi un SSL sul server non è sufficiente. La tua risposta è la più vicina finora. Grazie mille.

— Abhishek Dujari,

1

+1 È fantastico menzionare i certificati client, ma non è necessario che il server emetta i certificati. Devono solo essere firmati da un'autorità di certificazione attendibile; sostanzialmente uguale a come funzionano i server certs.

— JimmyJames

3

HTTPS è molto bravo a prevenire attacchi di intercettazioni e "man in the middle". Poiché crittografa tutto il traffico per una sessione.

Ma poiché la maggior parte delle persone utilizza i certificati predefiniti forniti con il proprio browser e non ha idea di come creare il proprio certificato personale o configurare il browser per utilizzarlo.

Ciò rende HTTPS abbastanza inutile per l'autenticazione dell'utente oltre a proteggere una finestra di autenticazione da intercettazioni ecc.

— James Anderson
fonte

Penso che tu sia molto vicino a quello che ti sto chiedendo. Quindi suggerisci che dovremmo comunque firmare la richiesta sul lato client anche se utilizziamo HTTPS?

2

HTTPS consiste nel proteggere il canale, non nel dimostrare chi è il chiamante o nelle molte altre cose che devi considerare. Autenticazione, autorizzazione e crittografia del livello di trasporto sono solo una piccola parte di ciò che è necessario considerare. Molte delle vulnerabilità note relative alle applicazioni Web si applicano molto alle API REST. Devi considerare la convalida dell'input, il cracking della sessione, i messaggi di errore inappropriati, le vulnerabilità interne dei dipendenti e così via. È un argomento importante.

Roberto

— Robert Morschel
fonte

0

È possibile adottare l'approccio dei certificati SSL client e separare la sicurezza da api. Il grande svantaggio di questo approccio è il sovraccarico dell'operazione che diventerà costoso man mano che sempre più clienti consumano la tua API.

Ad ogni modo, l'autenticazione di base HTTP va bene per la stragrande maggioranza dei servizi consumati pubblicamente.

— CodeToGlory
fonte