Eventuali difetti in questo modello di sicurezza per un servizio Web REST?

Question

Eventuali difetti in questo modello di sicurezza per un servizio Web REST?

#1 da (8 voti)
#2 da (6 voti)
#3 da (1 voti)

9

Ho progettato un servizio web REST che richiede l'autenticazione. Gestisce l'autenticazione in modo simile ai servizi Web Amazon, ovvero: l'utente ha un ACCESS_KEY (ad esempio, 'abcd') e un SECRET_KEY (ad esempio 'aabbcc'). Il SECRET_KEY viene utilizzato per creare un TOKEN : un SHA-1 che utilizza le informazioni sulla richiesta, ad esempio:

GET path HTTP/1.1
Date: Mon, 23 May 2005 22:38:34 GMT
ACCESS_KEY: abcd
TOKEN: SHA1(SECRET_KEY + ACCESS_KEY + Date + path)

Posso controllare TOKEN nel server e autenticare la richiesta. Fino a questo punto, non penso che ci sia qualcosa di sbagliato nel modello di sicurezza.

La mia unica domanda è come fornire SECRET_KEY quando si utilizza il servizio da una pagina web. Ho pensato di poterlo inviare come variabile JavaScript (la connessione è HTTPS) e utilizzare semplicemente tale variabile in una funzione JavaScript che aggiunge l'intestazione appropriata a ogni HTTPRequest . L'autenticazione iniziale può essere eseguita utilizzando approcci basati su cookie standard (ad esempio, affidandosi a Django per gestire una sessione).

Quindi l'architettura ha il seguente aspetto:

Sessione del sito Web: gestita da Django utilizzando la sicurezza standard basata sulle sessioni ( example.com )
La sessione del sito Web riceve tramite HTTPS SECRET_KEY come variabile globale JavaScript, che viene utilizzata per aggiungere gli header appropriati a ogni HTTPRequest .
Il HTTPRequests è fatto a api.example.com , che è ignaro della sessione di Django: si preoccupa solo di avere le intestazioni appropriate.

Credo che questo approccio sia sicuro, pur mantenendo un'API REST completamente stateless. Non uso l'autenticazione HTTP standard (base o digest) perché non voglio hackerare il problema "non puoi disconnetterti" e voglio mantenere l'API rigorosamente REST.

Hai commenti riguardo questo approccio? Se è difettoso, come realizzeresti i miei obiettivi?

Grazie!

rest authentication appsec web-service

posta Escualo 19.09.2011 - 17:50

fonte

3 risposte

Leggi altre domande sui tag rest authentication appsec web-service

Reimposta password - dovrei impedire di abusarne? Email SSL security?

score 8 · Answer 1

Non vedo difetti, ma penso che tu stia esagerando. Mi sembra che mi manchi qualcosa, che usi un token perché pensi che dovresti, non perché ci sia una ragione legittima.

L'approccio migliore sarebbe identificare prima i requisiti (di sicurezza) e quindi cercare le soluzioni.

Una delle cose che dovresti pensare con le API senza stato sono gli attacchi di replay. Nel modo in cui lo descrivi, il tuo protocollo sembra vulnerabile a un attacco di replay. Inoltre, può essere abusato per CSRF poiché non c'è casualità in ogni richiesta. Non sono sicuro se questo è qualcosa che l'API REST può risolvere, perché è un problema inerente alla webapp, ma vale la pena pensarci.

In conclusione, nessuno può valutare se la sicurezza è accettabile se non si hanno requisiti di sicurezza (e una panoramica delle minacce).

score 6 · Answer 2

Penso che dovresti limitarti a https. Se le parti principali sono generate in javascript lato client (ad esempio, lo sha1 del token), quanto sarebbe difficile per un attacco MITM, in cui un utente malintenzionato conduce le persone a una versione contraffatta del tuo sito, dove il javascript è alterato per rivelare la chiave segreta del server? (Ad esempio, altera il DNS e altera il sito su un hotspot Wi-Fi pubblico.)

Inoltre chi sta generando la data (client o server)? Quanto dura un token valido? Un token generato / convalidato due minuti fa è ancora valido? Un MITM potrebbe intercettare un token valido per eseguire una richiesta specifica e riprodurlo (e fare qualcosa di malvagio riproducendolo)?

score 1 · Answer 3

Puoi confermare che segue il caso d'uso per il tuo servizio web RESTful

Altri servizi / richiesta di invio di applicazioni al tuo servizio. Non è necessario mantenere lo stato di sessione
Richiesta dai browser.

Per il primo caso d'uso, penso che il tuo approccio sia buono. Puoi prendere in considerazione le seguenti modifiche per renderlo ancora migliore 1. Usa SHA256 invece di SHA1 (dicono che SHA1 non è considerato troppo strong ora un giorno) 2. Assicurati che tutte le chiavi segrete emesse seguano le appropriate regole di complessità

Spero tu stia parlando solo del modello di autenticazione qui e non di altre cose. Se stai parlando anche di altre cose, SSL dovrebbe essere incluso nell'elenco delle priorità (per una serie di motivi).

Per il secondo caso utente, i consigli sarebbero diversi a seconda che si voglia mantenere uno stato di sessione (non proprio REST;)) o si va bene con richieste individuali non correlate dal browser

Posso provare a dare qualche suggerimento basato su quale sia il caso d'uso (sessione o nessuna sessione)