Protezione di un'API Web in MVC

1

Ho una semplice ASP MVC 6 WebAPI a cui sto lavorando attualmente in cui gli utenti registrati possono chiamare i dati della richiesta utilizzando un campione dell'URL sottostante:

http://localhost:7988/api/b8pE5Qodiw/elections/Prop1/Prop2/Prop3

b8pE5Qodiw fa riferimento al codice API univoco per un utente confermato. Questo viene generato dall'applicazione e l'utente non è in grado di utilizzarlo fino a quando non conferma la sua email.

Sto generando il codice seguendo la risposta su questa domanda SO

Da un punto di vista della sicurezza, i potenziali problemi con il codice API dell'utente nell'URL e in che modo sto generando il codice API?

Esiste una best practice su come i servizi di RESTful generano l'URL dell'API

    
posta hello 07.12.2016 - 17:44
fonte

1 risposta

2

C'è un problema piuttosto importante che è immediatamente evidente, ma potrebbe essere un artefatto del tuo ambiente di sviluppo: la richiesta viene trasmessa su plain 'http, il che significa che la chiave API è disponibile per chiunque esegua un man-in-the-middle attacco.

La soluzione per questo, ovviamente, è di fare sempre solo questo tipo di richieste su https. Non puoi controllare ciò che fanno i tuoi utenti (dopotutto, potrebbero semplicemente pubblicare la loro chiave sul web), ma puoi strongmente incoraggiare questo comportamento. I modi possibili per farlo includono:

  • assicurandoti che tutti i tuoi esempi utilizzino https
  • avvertimenti importanti nella documentazione
  • restituire una pagina di errore, piuttosto che un reindirizzamento, quando una richiesta API viene inviata su http
  • abilitare le funzioni per il tuo dominio (anche se non penso che questo avrà alcun effetto sui programmi basati su arricciatura personalizzata)

Come menzionato nei commenti, lo spostamento della chiave nel corpo della richiesta impedirà la visualizzazione nei registri di accesso, che potrebbero essere trattati con meno rigore di sicurezza rispetto al database.

Personalmente, le tue chiavi mi sembrano troppo brevi. Sono usati dai programmi, non dagli umani, quindi non c'è motivo per non avere una lunghezza della chiave molto più lunga che va ben oltre ciò che si potrebbe immaginare per essere immaginabile (ricorda che un attaccante non ha bisogno di indovinare un specifico key, ma qualsiasi valore è valido)

    
risposta data 07.12.2016 - 18:10
fonte

Leggi altre domande sui tag