L'HTTP 426 è accettabile per "La tua richiesta avrebbe dovuto essere HTTPS"

Question

L'HTTP 426 è accettabile per "La tua richiesta avrebbe dovuto essere HTTPS"

#1 da (7 voti)

4

Ho un HTTP che serve un'API che funziona in modo anonimo o con una chiave segreta in un'intestazione, in questo modo:

GET /profile?authenticationKey
Authorization: 1234567890

Voglio rifiutare qualsiasi richiesta proveniente da HTTP che utilizza un'intestazione Autorizzazione, poiché tali intestazioni verrebbero visualizzate in testo normale. Ma non sono sicuro di quale sia la risposta appropriata.

Ho preso in considerazione 400 Bad Request con una nota che spiega perché ciò che hanno fatto è stato stupido e suggerendo che hanno immediatamente invalidato la loro chiave.

Ma mi chiedo se l'aggiornamento 426 richiesto potrebbe essere migliore o peggiore. È un codice specifico per l'idea che una richiesta HTTP debba essere una richiesta HTTPS, ma leggere RFC 2817 mi fa pensare che sia stato progettato per passare a HTTPS dalla stessa porta. Posso usarlo anche in questo caso? In tal caso, devo includere anche un'intestazione Upgrade: TLS/1.0 ?

http https

posta Bob 27.10.2015 - 20:36

fonte

1 risposta

Leggi altre domande sui tag http https

In che modo le grandi aziende conservano le chiavi API? Quanto dovrebbero essere stretti i miei test unitari?

score 7 · Answer 1

La situazione che stai cercando di evitare qui è quella degli utenti API che inviano le loro credenziali sul filo in una forma facilmente annusata da terze parti.

Se esegui il reindirizzamento a HTTPS o servi qualsiasi errore HTTP, non eviti questa situazione; le credenziali sono già state inviate prima che tu abbia la possibilità di rispondere.

L'unica cosa veramente appropriata da fare è non servire l'API su HTTP affatto , nemmeno per le richieste anonime. Per il tuo server API, idealmente non dovrebbe esserci un server in ascolto sulla porta 80 del tutto. Se è necessario che l'indirizzo IP sia in ascolto sulla porta 80 (ad esempio perché non si hanno indirizzi IP di riserva), è necessario restituire 403 Forbidden o 404 Not Found per le richieste API. Opzionalmente è possibile acquisire e invalidare tali credenziali che sono state inviate erroneamente tramite HTTP, ma è meglio non ascoltare affatto su HTTP.