preoccupazioni riguardo a chiamare l'API REST da più server

3

Esiste un'applicazione web master che deve chiamare le API REST dai server di altre applicazioni. Posso pensare a due modi per raggiungerlo:

a). chiamate le API sul front-end dell'applicazione principale (javascript)

// javascript code of master application
$.ajax(api_server1_url,{
  ...
})

b). chiamate le API sul server dell'applicazione principale

// backend code of master application
call_api(api_server1_url)

Sia a che b restituiscono il risultato json per un ulteriore utente nell'applicazione master.

Se ho l'accesso al codice e ai server di tutte le applicazioni menzionate sopra, l'opzione a o l'opzione b sono migliori per la sicurezza?

molto nuovo per la sicurezza, ma elencherò quello che so (non molto ..): a ha una vulnerabilità di cross-site-scripting. Penso che sia possibile eliminarlo o limitarlo modificando il codice sulle applicazioni API, ma ci vorrà uno sforzo.

Ecco perché preferisco l'opzione b. Anche se il codice sui server API deve ancora essere aggiornato per prevenire l'attacco, ma dovrebbe essere più semplice dell'opzione a. Dovrebbe essere sufficiente solo l'IP dell'applicazione master per accedere ai server API.

Quindi la mia domanda è:

La mia ipotesi su b è migliore di un diritto? In caso contrario, quali misure di sicurezza devo implementare sui server API?

Grazie per qualsiasi input.

    
posta odieatla 19.02.2016 - 02:36
fonte

2 risposte

1

Restatement delle domande:

Nell'architettura delle applicazioni, qual è il modo più sicuro per delegare le chiamate tra le API Javascript:

  1. Per consentire al client finale di chiamare direttamente l'API di hosting; o
  2. Per delegare la chiamata del client finale attraverso un front-end server.

Possibile contesto: questa preoccupazione potrebbe essere più applicabile a Node.js in cui la logica dell'applicazione è implementata tramite Javascript - altrimenti, non sono ancora sicuro di aver compreso correttamente la domanda ...:

Risposte rapide:

Ecco alcuni link sulla protezione delle API REST, si spera di aiutare a focalizzare la domanda un po '- ma non sono sicuro se questa è la domanda:

Risposte - L'architettura multilivello non è sicura:

L'architettura dell'applicazione è molto diversa da " Sviluppo sicuro delle applicazioni ".

Indipendentemente dal modo in cui tu architetti / strutturi / partiziona la funzionalità - non proteggerà l'applicazione - ma permetti solo il framework di base così puoi proteggerlo .

Nella tua domanda, stai effettivamente discutendo di " Architettura multilivello ".

E, se non architettato correttamente, ti precludi di essere in grado di proteggere l'applicazione.

Questi sono i principi fondamentali dell'architettura di applicazioni multilivello, che penso tu stia facendo riferimento a:

  1. Accompagna in modo flessibile la logica del cliente e della presentazione alla logica aziendale e di integrazione sottostante - Disaccoppiamento completo da tutta la logica dei dati.
  2. Abbina liberamente la logica di integrazione, (interfacce B2B, ecc.) a Business Logic, completamente disaccoppiata da Data Logic.
  3. Accoppia la logica aziendale alla logica dei dati.
  4. Non consentire mai l'accesso da un livello, al livello superiore - solo su UN piano, (Presentazione per business e Business accesso ai dati, ma non Presentazione direttamente ai dati, né integrazione direttamente ai dati, ma Integrazione al business è multa.

Tuttavia, anche se correttamente implementato, devi proteggere le interfacce tra ogni livello, altrimenti è vulnerabile come se tutto fosse in esecuzione sul client.

    
risposta data 19.02.2016 - 03:31
fonte
1

Direi che B è oggettivamente più sicuro dato un certo contesto. In particolare, se l'API di terze parti richiede un login o una chiave API, il client (browser) non dovrebbe avere accesso a tali informazioni.

    
risposta data 13.02.2017 - 19:59
fonte

Leggi altre domande sui tag