È importante che il livello intermedio di un'applicazione Web utilizzi un protocollo di comunicazione diverso?

Question

È importante che il livello intermedio di un'applicazione Web utilizzi un protocollo di comunicazione diverso?

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

2

Quando si costruisce un'applicazione web a più livelli / livelli in cui ogni livello è fisicamente separato dagli altri, è importante che uno stack di comunicazione diverso venga utilizzato dai livelli di back-end, che non sono esposti a Internet- rispetto al livello web che è?

Essendo consapevoli della sicurezza nella creazione di un'applicazione Web, sto creando un livello intermedio (server di back-end, server delle applicazioni) che gestisce l'accesso ai dati per l'applicazione Web in modo che il server Web non abbia mai accesso diretto al database.

Ho pensato che dovevo fare in modo che il server delle applicazioni usasse un protocollo di comunicazione diverso da quello esposto sul server web. Se il mio livello intermedio espone i servizi web HTTP / REST utilizzando lo stesso stack tecnologico del server web, il livello intermedio non sarebbe altrettanto facilmente compromesso?

Come tale, ho fatto comunicare al middle-tier un protocollo TCP binario mentre il server web espone i servizi web HTTP / REST. Il lato negativo di questo è tutto il sovraccarico. Ho bisogno di definire entrambe le interfacce due volte (una volta per l'application server e una volta per il web server) e ho bisogno di gestire due librerie / protocolli di comunicazione e le loro stranezze.

Questa è la complessità richiesta dallo sviluppo di applicazioni web sicure? Ho ragione di aver bisogno di utilizzare protocolli / librerie diversi su Application Server e Web Server?

Modificato per aggiungere: Questo riguarda la mitigazione nel caso in cui il server Web sia compromesso. Il server web può fare molto meno del middle-tier (in particolare, non accedere al database). Un utente malintenzionato che compromette il server Web sarebbe nocivo; ma ottenere un accesso illimitato al database sarebbe molto peggio.

web-application

posta vossad01 29.01.2015 - 16:57

fonte

3 risposte

Leggi altre domande sui tag web-application

HMAC e non ripudio È ragionevole utilizzare la password dell'applicazione bypassando l'autenticazione a due fattori? [duplicare]

score 2 · Answer 1

L'uso di un diverso stack / protocollo di trasporto non riduce significativamente molto il rischio.

client - ([1] http) - > frontend - ([2] binary) - > backend - ([3] mssql / odbc /?) - > banca dati

Tre protocolli etichettati [1], [2] e [3]. Se un utente malintenzionato compromette il server front-end, non importa quale protocollo viene utilizzato per [2]. L'autore dell'attacco avrà le stesse autorizzazioni di qualsiasi processo in esecuzione sul front-end, indipendentemente dal protocollo utilizzato per [2].

Metterei meno energia nello scambio di protocolli e più energia nel monitorare il traffico dal frontend al backend. È più probabile che il traffico mostri anomalie perché il frontend al traffico back-end è in genere chiaramente definito. Il traffico client-front-end non è così facile da rilevare le anomalie perché ogni browser, ogni scanner, ogni hacker sta cercando di infrangere tutto il tempo. Ma se sei in grado di rilevare che un compromesso è già avvenuto, sarai in grado di mitigare i danni.

Torna alla tua domanda sul protocollo. Perché HTTP è testo chiaro, è più facile da monitorare. Puoi rilevare richieste insolite e avvisare la tua risposta agli incidenti.

Solo i miei 2 cent.

score 1 · Answer 2

No, non è importante. Stai suggerendo o la sicurezza attraverso l'oscurità, o alzando la barra per scoprire il difetto.

L'importante è che modelliate correttamente tutte le risorse nel regno per esposizioni e vulnerabilità di sicurezza.

Dovresti fare un passo indietro e ricominciare implementando un ciclo di sviluppo della sicurezza ben progettato. Tale processo includerà Formazione, Requisiti, Progettazione, Implementazione, Verifica, Rilascio e Risposta.

Ci sono molti buoni materiali di riferimento per aiutarti nel processo. Ma alcuni bei punti per iniziare:

"The Security Development Lifecycle" (Michael Howard)
"Modellazione delle minacce: progettazione per la sicurezza" (Adam Shostack)
"Costruire software sicuro" (John Viega)

score 0 · Answer 3

Se la valutazione / i requisiti del progetto hanno determinato che è necessario un livello intermedio, la tua logica è corretta.

Supponendo che la stessa suite di prodotti debba essere utilizzata per i livelli esterno e intermedio, a condizione che il protocollo di livello intermedio utilizzi diversi componenti software / stack tecnologico per il protocollo di livello esterno, quindi in teoria una vulnerabilità sfruttabile nel servizio di livello esterno sarà non portare a un compromesso diretto in avanti del livello intermedio basato sulla stessa vulnerabilità / exploit.

A seconda di cosa stai cercando di ottenere, potrebbe valere la pena di dare un'occhiata in giro per vedere se esiste un'opzione di proxy di applicazione più affidabile disponibile per l'uso nel livello intermedio.

Ovviamente ci saranno altri rischi nella soluzione, che richiederà controlli per impedire l'accesso non autorizzato con conseguente traffico apparentemente autorizzato inviato dal livello esterno al livello intermedio.