Sicurezza degli schemi di autenticazione REST

Sfondo:

Sto progettando lo schema di autenticazione per un servizio web REST. Non è necessario "realmente" essere sicuri (è più un progetto personale) ma voglio renderlo il più sicuro possibile come un'esperienza di esercizio / apprendimento. Non voglio usare SSL poiché non voglio la seccatura e, soprattutto, le spese per la sua configurazione.

Queste domande SO sono state particolarmente utili per iniziare:

• Autenticazione RESTful
• Best practice per la protezione di un'API / servizio Web REST
• Esempi delle migliori API Web SOAP / REST / RPC? E perché ti piacciono? E cosa c'è che non va in loro?

Sto pensando di utilizzare una versione semplificata dell'autenticazione di Amazon S3 (mi piace OAuth ma sembra troppo complicato per le mie esigenze). Sto aggiungendo un nonce generato casualmente , fornito dal server, alla richiesta, per evitare attacchi di riproduzione.

Per arrivare alla domanda:

Sia S3 che OAuth si basano sulla firma dell'URL della richiesta insieme ad alcune intestazioni selezionate. Nessuno dei due firma il corpo della richiesta per le richieste POST o PUT. Questo non è vulnerabile a un attacco man-in-the-middle, che mantiene l'URL e le intestazioni e sostituisce il corpo della richiesta con tutti i dati desiderati dall'attaccante?

Mi sembra di poterlo evitare includendo un hash del corpo della richiesta nella stringa che viene firmata. È sicuro?

Una risposta precedente menzionava solo SSL nel contesto del trasferimento di dati e in realtà non riguardava l'autenticazione.

Stai davvero chiedendo l'autenticazione sicura dei client API REST. A meno che non si stia utilizzando l'autenticazione client TLS, SSL da solo NON è un meccanismo di autenticazione praticabile per un'API REST. SSL senza autenticazione client autentica solo il server , il che è irrilevante per la maggior parte delle API REST perché si desidera veramente autenticare il client .

Se non usi l'autenticazione client TLS, dovrai utilizzare qualcosa come uno schema di autenticazione basato su digest (come lo schema personalizzato di Amazon Web Service) o OAuth 1.0a o persino l'autenticazione HTTP di base (ma solo su SSL).

Questi schemi autenticano che la richiesta è stata inviata da qualcuno previsto. TLS (SSL) (senza autenticazione client) garantisce che i dati inviati tramite il filo rimangano non manomessi. Sono preoccupazioni separate ma complementari.

Per chi fosse interessato, ho ampliato una domanda SO sugli schemi di autenticazione HTTP e su come funzionano .

REST significa lavorare con gli standard del web e lo standard per il trasferimento "sicuro" sul web è SSL. Qualsiasi altra cosa sarà un po 'funky e richiederà uno sforzo di implementazione extra per i client, che dovranno disporre di librerie di crittografia.

Una volta che ti impegni a SSL, in linea di principio non è necessario nulla di speciale per l'autenticazione. Puoi di nuovo andare con gli standard web e utilizzare l'autenticazione HTTP di base (nome utente e token segreto inviati insieme ad ogni richiesta) in quanto è molto più semplice di un protocollo di firma elaborato e comunque efficace nel contesto di una connessione sicura. Devi solo assicurarti che la password non superi mai il testo normale; quindi se la password viene mai ricevuta tramite una connessione in testo normale, potresti persino disabilitare la password e spedire allo sviluppatore. Dovresti anche assicurarti che le credenziali non siano registrate da nessuna parte al momento della ricezione, così come non registreresti una password normale.

HTTP Digest è un approccio più sicuro in quanto impedisce il passaggio del token segreto; invece, è un hash che il server può verificare dall'altra parte. Sebbene possa essere eccessivo per le applicazioni meno sensibili se hai preso le precauzioni di cui sopra. Dopotutto, la password dell'utente viene già trasmessa in testo normale quando accede (a meno che tu non stia eseguendo una crittografia JavaScript sofisticata nel browser) e allo stesso modo i loro cookie su ogni richiesta.

Tieni presente che con le API è meglio che il client passi token - stringhe generate casualmente - invece della password con cui lo sviluppatore accede al sito web. Quindi lo sviluppatore dovrebbe essere in grado di accedere al tuo sito e generare nuovi token che possono essere utilizzati per la verifica API.

Il motivo principale per utilizzare un token è che può essere sostituito se è compromesso, mentre se la password è compromessa, il proprietario potrebbe accedere all'account dello sviluppatore e fare tutto ciò che desidera. Un ulteriore vantaggio dei token è che è possibile emettere più token agli stessi sviluppatori. Forse perché hanno più app o perché vogliono token con diversi livelli di accesso.

(Aggiornato per comprendere le implicazioni del rendere solo la connessione SSL.)

In alternativa, è possibile utilizzare la soluzione nota a questo problema e utilizzare SSL. I certificati autofirmati sono gratuiti ed è un progetto personale giusto?

Se richiedi l'hash del corpo come uno dei parametri nell'URL e tale URL è firmato tramite una chiave privata, un attacco man-in-the-middle sarebbe in grado di sostituire il corpo solo con contenuti che genererebbero il stesso hash. Facile da fare con i valori di hash MD5 ora almeno e quando SHA-1 è rotto, beh, ottieni l'immagine.

Per proteggere il corpo da manomissioni, è necessario richiedere una firma del corpo, che un attacco man-in-the-middle avrebbe meno probabilità di riuscire a rompere poiché non conoscono la chiave privata che genera la firma .

In realtà, l'auth originale S3 non consentono per il contenuto da firmare, anche se con una firma MD5 debole. Puoi semplicemente applicare la loro pratica opzionale di includere un'intestazione Content-MD5 nell'HMAC (stringa da firmare).

http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

Il loro nuovo schema di autenticazione v4 è più sicuro.

http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html

Ricorda che i tuoi suggerimenti rendono difficile per i client comunicare con il server. Devono comprendere la tua soluzione innovativa e crittografare i dati di conseguenza, questo modello non è così buono per le API pubbliche (a meno che tu non sia amazon \ yahoo \ google ..).

Ad ogni modo, se devi crittografare il contenuto del corpo, ti suggerirei di verificare gli standard e le soluzioni esistenti come:

Crittografia XML (standard W3C)

Sicurezza XML