Qual è la risposta HTTP corretta da inviare per richieste che richiedono SSL/TLS

Sto progettando un'API RESTful in cui alcune chiamate sono pubbliche su HTTP e alcune richiedono una chiave API e la crittografia su HTTPS. Sto deliberando su quale codice di risposta dovrebbe essere inviato se una richiesta HTTP viene inviata a una delle risorse private. Finora l'unico che mi salta addosso è 412 - Precondizione non riuscita, ma lo standard indica che la condizione preliminare è imposta dal richiedente e non dal server.Qual è la risposta HTTP corretta da inviare per richieste che richiedono SSL/TLS

Esiste un codice di risposta appropriato per questa condizione o devo semplicemente arrendermi e fare ?

fonte

2010-03-31 gtd

Il modo più sicuro per forzare client HTTP per usare HTTPS è HTTP Strict Transport Security.

In precedenza un suggerimento comune era quello di eliminare la connessione, ma questo practice has been removed in favor of HSTS (sito Web OWASP).

fonte

2014-01-31 17:03:52

Grazie per l'aggiornamento. – gtd

1. La bozza HSTS è stata [spostata su IETF] (http://tools.ietf.org/id/draft-ietf-websec-strict-transport-sec). 2. leggerlo in realtà non dà una buona risposta alla domanda dell'OP. –

HSTS applica HTTPS sul sito intero. Il poster sopra voleva che alcune risorse fossero disponibili su HTTP mentre altre solo su HTTPS. Quindi HSTS non può essere utilizzato poiché si applica a tutte le risorse. – Fred

Il codice di errore appropriato da restituire sarebbe simile a 403.4 - SSL required.

Anche se non esplicitamente documentata nel RFC for HTTP 1.1, questo comportamento non corrisponde ai requisiti delineati c'è:

Il server capito la richiesta, ma si rifiuta di compierla. L'autorizzazione non aiuterà e la richiesta NON DEVE essere ripetuta. Se il metodo di richiesta non era HEAD e il server desidera rendere pubblico perché la richiesta non è stata soddisfatta, DOVREBBE descrivere il motivo del rifiuto nell'entità. Se il server non desidera rendere queste informazioni disponibili al client, è possibile utilizzare il codice di stato 404 (non trovato).

Aggiungere il proprio sottocodice (come con l'esempio SSL) potrebbe essere utile in alcuni casi, ma poiché questo sottocodice non sarebbe significativo per terze parti, raccomanderei di non farlo.

Quindi, il messaggio di errore finale sarebbe qualcosa come "403 - Risorsa privata". Si noti che, anche nel caso di una chiave API mancante, "401 - Non autorizzato" non dovrebbe essere utilizzato, a meno che la chiave API non possa essere effettivamente trasmessa in un campo di intestazione Autenticazione WWW.

fonte

2010-03-31 16:53:41 mdb

Si noti che i codici di stato IIS sono falsi. I codici di stato HTTP sono composti solo da numeri (esattamente 3). Vedere http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1 Si noti inoltre che la frase di motivazione per 403 è "Proibita" e che questa non è soggetta a modifiche. Ogni ulteriore spiegazione dovrebbe andare nella risposta * corpo *. –

Sì, per quanto attraente come questo sottocodice, non riesco a sostenere la natura non standardizzata di questo. – gtd

Sono d'accordo con altri commentatori che un sottocodice non dovrebbe essere usato, ma un caso potrebbe essere fatto per un semplice 403. Ad esempio, questo è ciò che sta usando Twitter per la loro API. Vedi https://dev.twitter.com/docs/security/using-ssl –

Non posso dire se questo è ampiamente accettato dai client HTTP, ma parlando rigorosamente RFC, il server dovrebbe rispondere con:

HTTP/1.1 426 Upgrade Required 
Upgrade: TLS/1.0, HTTP/1.1 
Connection: Upgrade

Fonte:
http://tools.ietf.org/html/rfc2817#section-4.2

fonte

2010-03-31 20:06:54 MicE

Interessante. RFC e OWASP differiscono nelle loro raccomandazioni. Preferisco la versione di OWASP - non rispondere alla richiesta e lasciare semplicemente il pacchetto. Con l'approccio RFC, un man-in-the-middle potrebbe intercettare la risposta (poiché non è ancora https) e reindirizzare a un sito Web contraffatto. –

Sì, sono d'accordo: è sicuramente una vulnerabilità. Anche se l'interruzione della connessione potrebbe essere fonte di confusione, i problemi di sicurezza dovrebbero avere la precedenza qui. Inoltre, si noti che la RFC menzionata ora ha quasi 10 anni (in quei tempi la sicurezza poteva non essere stata un aspetto così importante come lo è oggi). – MicE

Sai, dopo averlo osservato più da vicino ho capito che si tratta di un aggiornamento a TLS, presumibilmente da una versione precedente di SSL. Non sto facendo TLS, quindi non posso usare quell'intestazione, e poiché la specifica è specifica per TLS, non penso che sia appropriato. Purtroppo anche io non ho un modo per rilasciare la connessione ... – gtd

Basta inviare un redirect al corrispondente https: URI.

UPDATE

La è una risposta sbagliata - vedi commenti qui sotto

fonte

2010-03-31 21:21:48

C'è un rischio per la sicurezza. "Un utente malintenzionato che esegue un attacco intermedio potrebbe intercettare la risposta di reindirizzamento HTTP e inviare l'utente a una pagina alternativa" - dalle migliori pratiche SSL OWASP –

Ciò non impedisce agli utenti di fare ancora riferimento all'URL http, in realtà, con la maggior parte i client http non vedranno nemmeno che un reindirizzamento http abbia avuto luogo. Spazzare il problema sotto il tappeto non è probabilmente l'approccio che si vuole prendere. –

Sì, mi dispiace. Ragazzi, avete ragione L'invio di un reindirizzamento è la cosa sbagliata da fare. Grazie per la segnalazione. –

Tornando un con la ragione frase "HTTPS Required" sembra come una soluzione pratica e quello che uso.

vedere https://en.wikipedia.org/wiki/HTTP_403

reindirizzando un'API REST non è una buona idea soprattutto perché si può avere alcuna idea di come o che cosa sta consumando il vostro servizio.

fonte

2016-01-20 11:57:23 NER1808

Qual è la risposta HTTP corretta da inviare per richieste che richiedono SSL/TLS

risposta

Problemi correlati