Sono 500 le risposte oi codici di errore specifici più sicuri per i servizi REST?

Question

Sono 500 le risposte oi codici di errore specifici più sicuri per i servizi REST?

#1 da (4 voti)
#2 da (2 voti)
#3 da (1 voti)

9

Sto creando un'API REST per archiviare dati sensibili per la sicurezza sia per il mio cliente che per i partner di terze parti.

Ogni richiesta viene convalidata utilizzando un HMAC di determinati dati che viene inserito in una chiave temporanea assegnata per un breve periodo dopo l'accesso dell'utente. Ovviamente tutto viene eseguito su TLS. Ogni richiesta viene registrata, insieme alle chiavi dei dati restituiti, nonché le chiavi di tutti i dati che sarebbero stati restituiti se la richiesta non fosse stata bloccata per qualche motivo.

Se i dati non sono presenti, o se i dati in una posizione possono essere letti da un particolare utente, ma non aggiornati, o se la richiesta di aggiornamento non è corretta, il server dovrebbe restituire un messaggio di errore significativo oppure no?

Se l'utente non ha le autorizzazioni per eseguire un'azione, è necessario restituire una risposta 401 o 403, indicando che la richiesta non è riuscita a causa della mancanza di autorizzazioni per eseguire l'azione. Altri codici di risposta possono essere utilizzati nel caso in cui i dati non siano corretti, oppure i tipi di dati previsti non corrispondono (invio di una stringa a un campo int, ecc.). Fondamentalmente, seguire le buone pratiche REST / HTTP e registrare tutto, ma non fornire alcuna informazione all'utente oltre un suggerimento di base su cosa è andato storto.
Non dare mai a nessuno alcuna informazione, nel caso in cui possa essere utilizzata contro il sistema in qualche modo. Solo sempre restituire un errore di 500, senza descrizione di alcun tipo. Esiste un certo livello di disaccordo in merito alla possibilità o meno di restituire un 404 o, in alternativa, restituire una risposta vuota o un errore 500. Se uno sviluppatore di terze parti incontra queste risposte e non capisce il perché, deve contattare la nostra azienda, chiedere a qualcuno di controllare i log e spiegare come eseguire correttamente le richieste.

Qualcuno ha esperienza "dalle trincee" su quale metodologia abbia più senso? Di particolare interesse è come bilanciare la sicurezza con le richieste di usabilità e supporto.

rest http

posta drz 18.07.2013 - 15:31

fonte

3 risposte

2

Eviterei l'errore 401 in quanto attiva il browser per mostrare una casella di login di autenticazione HTTP. Questo è fastidioso e confonde i tuoi utenti.

Oltre a questo, restituisci qualsiasi codice di errore che desideri, ma ricorda che alcuni client faranno determinate cose dato il tuo codice di risposta.

Ad esempio, un 500 o 403 può impedire che la tua risposta venga indicizzata dai motori di ricerca, mentre un 200 no. Il codice di errore di per sé non rivela nulla di sicurezza. Qualunque cosa nella gamma 4xx dice "il client ha fatto qualcosa di sbagliato" mentre qualcosa nell'intervallo 5xx dice "il server ha fatto qualcosa di sbagliato".

risposta data 19.07.2013 - 01:50

fonte

1

In caso di un servizio riposante combinerei entrambe le opzioni. Ma vorrei solo restituire 401 o 403 (non distinguere tra loro) e semplicemente fare un errore generico per 404 e 500, userei 200 invece con un messaggio personalizzato piuttosto che 404 o 500.

risposta data 18.07.2013 - 15:48

fonte

Leggi altre domande sui tag rest http

In che modo i sistemi proteggono da un certificato di firma del codice rubato dopo la scadenza del certificato? Come disabilitare cipher RC4 in ubuntu 12.04

score 4 · Accepted Answer

Versione breve:

Sii sufficientemente informativo per supportare utenti legittimi della tua applicazione, ma non di più.

Versione lunga:

Prima di tutto, non c'è una risposta unica per questo, perché dipende dal contesto dell'applicazione. Se stai pubblicando un'API open-source per il tuo prodotto per consentire alle persone di scrivere client, allora ti consigliamo di fornire un feedback utile in modo che possano eseguire il debug del codice e scrivere utili gestori degli errori. Se stai rilasciando software client closed-source per interagire con il tuo server closed-source, puoi essere un po 'più restrittivo, perché ti stai solo interessando.

In secondo luogo, il modello RESTful implica in parte che restituirai i codici HTTP con significato semantico (ad es. 404 per "Non trovato", non solo 500 per tutto). Ovviamente, il REST è solo un modo di fare le cose, quindi non è come se l'auditor di REST ti violentasse le nocche, ma se stai usando un modello, dovresti considerare che ha delle ragioni per essere progettato è.

In terzo luogo, l'aspetto più importante della sicurezza che si può avere riguarda il contenuto dei messaggi di errore, non il significante. Restituire un 404, 403, 405, 502 o 503 è buono in quanto aiuta l'endpoint a determinare - approssimativamente - cosa è andato storto. Restituire una traccia dello stack dal tuo server Tomcat, d'altra parte, è molto oltre la linea - ed è probabilmente l'impostazione predefinita, quindi fai attenzione!

Infine, la mia esperienza "dalle trincee" è stata quella che ho descritto: restituire il codice di errore HTTP corretto, ma non è una cosa poetica, "503" dice "Servizio non disponibile" e il gioco è fatto. Per cose che non sono problemi a livello HTTP, restituiamo un 200 con un breve codice di errore a livello di applicazione. I codici sono numerici e possono essere trovati nell'API, e quindi forniscono "un utente malintenzionato" con alcune informazioni - qui avevano la password sbagliata, qui avevano troppe connessioni simultanee, qui avevano "contenuti discutibili". Sì, questo fornisce a un utente malintenzionato un modo per mappare il sistema. Il valore di disporre di un sistema che può essere sottoposto a debug da e per utenti legittimi ha superato il vantaggio di sicurezza ottenuto nascondendo gli errori con un valore di ritorno generico. Per esempio, sono disposto a scommettere che un attaccante intelligente potrebbe distinguere tra errore di autenticazione e violazione di WAF prestando molta attenzione alla latenza di andata e ritorno, quindi non sto perdendo tutto questo dandogli lui in un codice di errore.