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

13

Mi riferisco a questo eccellente articolo link che parla di Amazon come sicurezza per il servizio web. Tuttavia mi è stata fatta una domanda nel team del perché ne abbiamo bisogno se già usiamo HTTPS. Non sono stato in grado di rispondere in quanto mi sembra che abbiano ragione anche se l'istinto mi dice il contrario.

Ci sono anche posti quando si forniscono servizi REST in cui HTTPS potrebbe non funzionare? Ti piacciono i siti web di terze parti?

Se qualcuno ha esperienza nella protezione dei Web Services sugli interwebs pubblici, per favore fai un po 'di luce con la tua esperienza.

Grazie in anticipo.

EDIT: per chiarire non sto parlando dell'autenticazione dell'utente ma di più dell'autenticazione del client. Si può presumere che l'autenticazione dell'utente sia di testo normale su HTTPS + REST.

La mia preoccupazione è che questo permetta comunque a chiunque di utilizzare il servizio web senza che il mio client acceda, dal momento che tutto è in chiaro, sebbene su HTTPS l'endpoint del client possa ancora utilizzare il mio servizio web senza l'applicazione client.

    
posta Abhishek Dujari 13.06.2011 - 03:56
fonte

4 risposte

13

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

HTTPS fornisce, prima di tutto, una connessione crittografata tra il server e il client.

The trust inherent in HTTPS is based on major certificate authorities that come pre-installed in browser software (this is equivalent to saying "I trust certificate authority (e.g. VeriSign/Microsoft/etc.) to tell me whom I should trust").

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

    
risposta data 13.06.2011 - 04:48
fonte
3

HTTPS è molto bravo nel prevenire attacchi di intercettazione e "man in the middle". Come crittografa tutto il traffico per una sessione.

Ma 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.

Questo rende HTTPS piuttosto inutile per l'autenticazione dell'utente diverso dalla protezione di una finestra di autenticazione da intercettazioni ecc.

    
risposta data 13.06.2011 - 04:55
fonte
2

HTTPS riguarda la protezione del canale, la mancata dimostrazione di chi è il chiamante o le molte altre cose che è necessario prendere in considerazione. L'autenticazione, l'autorizzazione e la crittografia dei livelli di trasporto sono solo una piccola parte di ciò che devi considerare. Molte delle vulnerabilità note relative alle applicazioni Web si applicano molto alle API di REST. È necessario considerare la convalida dell'input, il cracking della sessione, i messaggi di errore inappropriati, le vulnerabilità interne dei dipendenti e così via. È un grande argomento.

Robert

    
risposta data 12.10.2012 - 10:27
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.

In ogni caso, l'autenticazione di base HTTP va bene per la stragrande maggioranza dei servizi pubblici.

    
risposta data 13.06.2011 - 05:27
fonte

Leggi altre domande sui tag