La convalida delle richieste all'API proviene da una fonte valida

0

Attualmente sto lavorando a un progetto in cui sto sviluppando una libreria che eseguirà i POST HTTP su un servizio di backend sul mio server. I dati ricevuti dal servizio di backend vengono elaborati e archiviati in un database e consentono all'utente di utilizzare la libreria per visualizzare i dati.

Voglio assicurarmi che il servizio di backend elabori solo le richieste dalla libreria, se qualcos'altro tenta, come bot, ecc., la richiesta viene respinta.

Stavo pensando che avrei potuto ottenere questo risultato dalla libreria inviando una stringa crittografata in un'intestazione nella richiesta HTTP, quindi quando i servizi di backend ricevono la richiesta, controlla se l'intestazione esiste e se non rifiuta la richiesta, se lo fa , decrittografa l'intestazione e quindi verifica se la stringa decrittografata corrisponde a ciò che il servizio back-end si aspetta, in caso affermativo, continua l'elaborazione, altrimenti la rifiuta.

Stavo pensando che la libreria potrebbe avere il token di validazione codificato nella libreria (la libreria non sarà open source) tuttavia, stavo pensando che questo potrebbe essere problematico se il token di validazione fosse mai compromesso, avrei bisogno per rilasciare una nuova versione di libreria con il nuovo token e chiunque usi la libreria, dovrebbe quindi aggiornare le proprie app per utilizzare la nuova libreria.

Stavo pensando che il token potrebbe essere memorizzato sul server e la libreria richiede quale sia il token e quindi invia il token al servizio di backend, ma poi ho lo stesso problema che sto cercando di evitare, come faccio assicurati che solo la libreria recuperi il token e non chiunque altro.

Esiste una best practice raccomandata per fare ciò che sto cercando di ottenere.

Grazie per l'aiuto che puoi fornire.

    
posta Boardy 30.09.2017 - 13:21
fonte

2 risposte

2

Non puoi farlo, non in alcun modo che fornisca sicurezza. Se qualcuno ha la tua libreria client, hanno la chiave crittografata. Chiunque desideri trascorrere del tempo ed estrarre la chiave dalla libreria e quindi effettuare chiamate al servizio.

L'approccio normale è quello di consentire agli utenti della tua biblioteca di creare un account sul tuo sistema e quindi di rilasciare loro un token. Il token è autenticato su ogni chiamata al tuo servizio. Se vuoi impedire a qualcuno di chiamare il tuo servizio, puoi rimuovere l'autorizzazione del token e forse il loro intero account. Questo è l'autenticazione OAuth2, quindi non hai nemmeno bisogno di creare il tuo schema.

Non c'è nulla tecnologicamente che potresti fare, tuttavia, che impedirebbe alle persone di creare il proprio client al tuo servizio. Se possono chiamarlo con la libreria del cliente, possono decodificarlo e crearne uno proprio.

    
risposta data 30.09.2017 - 17:15
fonte
1

Come notato, questo è impossibile. Tuttavia, ci sono una serie di passaggi che è possibile intraprendere per avvicinarsi a una soluzione.

  1. impone ai singoli utenti l'accesso e il limite tariffario o li carica per l'utilizzo del servizio.

  2. Aggiorna frequentemente il protocollo e il client. costringendo gli hacker a dare continuamente ripetizioni ai loro hack.

  3. Utilizza i dongle crittografici hardware che richiedono l'inserimento manuale. Per impedire l'automazione.

  4. Tentativo di verificare il client tramite messaggi segreti usati raramente e degradare invece di bloccare completamente i client non validi. Rendere più difficile agli hacker il debug / test / verifica del loro client compromesso.

risposta data 30.09.2017 - 19:29
fonte

Leggi altre domande sui tag