Restituisce un errore 401 da una perdita di informazioni API?

Question

Restituisce un errore 401 da una perdita di informazioni API?

#1 da (7 voti)

5

Sto sviluppando un'API per un'applicazione a cui sto lavorando e ho trovato una domanda interessante:

Immagina un endpoint API come questo:

GET /customers/123456

che restituisce un singolo oggetto cliente. Ora, nella nostra organizzazione, i clienti possono appartenere a organizzazioni di vendita. Ogni utente API è associato a un'organizzazione e desidero limitare l'accesso di un utente ai clienti associati alla sua organizzazione.

Quindi, dato un utente che appartiene all'organizzazione ABC e cliente 123456 che appartiene all'organizzazione XYZ , cosa deve restituire la mia API quando questo utente tenta di ottenere quel cliente?

404 Not Found - se un utente interroga un cliente inesistente, restituisce un 404 poiché non è stata trovata alcuna risorsa in quell'URL.
401 Unauthorized - se interroghi una risorsa a cui non hai accesso, dovresti ottenere una risposta "non autorizzata".

Mi sembra che se l'API restituisce 401 Unauthorized o i clienti esistenti di altre organizzazioni e 404 Not Found per i clienti inesistenti, la mia API sta perdendo informazioni. Ad esempio, un utente dell'organizzazione ABC potrebbe interrogare l'API e determinare quali ID utente esistono e quali no.

Note aggiuntive:

Gli ID cliente sono generati in sequenza e non ci sono spazi vuoti, quindi il tipo di informazione che si perderebbe sarebbe:
- quale sarà il prossimo ID cliente?
- quanti clienti sono stati creati in un periodo di tempo?
Le organizzazioni di vendita sono generalmente limitate a particolari aree geografiche e non sono solitamente in concorrenza diretta. Ma alcuni territori si sovrappongono e ci sono delle regole in vigore per governare il "bracconaggio" i reciproci clienti. Quindi, tutto sommato, si tratta di un ambiente leggermente competitivo in cui non vogliamo davvero che le organizzazioni di vendita conoscano i rispettivi clienti.

api data-leakage appsec

posta Kryten 28.06.2018 - 18:35

fonte

1 risposta

Leggi altre domande sui tag api data-leakage appsec

Quale crittografia basata su password da utilizzare con Java 6 standard? Che cos'è il lavoro di CISO, esattamente?

score 7 · Accepted Answer

Prima di tutto, se questi ID utente sono effettivamente informazioni sensibili come dici tu, non metterli direttamente nell'URL. Perché non creare solo URL opachi e risolvere il problema prima che si verifichi? Se rimuovi la relazione tra l'URL e gli utenti, sarà quasi impossibile dedurre qualsiasi relazione da un codice di stato restituito.

Ad esempio, invece di:

GET somepath/customers/123456

implementa solo una sorta di piccolo sistema di hashing con una tabella di ricerca bidirezionale e puoi utilizzare un URL diverso come:

GET somepath/DC884298C70C41798ABE9052DC69CAEE

Certo, questo richiede un po 'più di lavoro, ma se sei legittimamente preoccupato per il problema, è davvero un'implementazione banale.

Tornando alla tua domanda attuale, il W3C afferma che se qualcuno tenta di accedere a una risorsa, ma non è autenticato correttamente, allora è OK restituire 404, anziché 403 (Proibito):

If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

Con la stessa logica, non vedo perché non sarebbe bene restituire 404 anziché 401 se il client è autenticato ma non autorizzato. Ma tieni a mente che, con questo approccio, qualcuno che sta effettivamente cercando di lavorare con la tua API può essere confuso e presumere che la risorsa non esiste e non si rende conto che semplicemente non hanno un'autorizzazione sufficiente. Alla fine spetta a te decidere. Dirò che, nella mia esperienza, ho visto entrambi i metodi implementati in precedenza. Se scegli di restituire un 404, assicurati di specificarlo da qualche parte nei documenti API in modo che altri sviluppatori lo sappiano.

Fonte: link