Gestione delle eccezioni nelle applicazioni multilivello

0

La gestione degli errori e delle eccezioni nelle applicazioni Web può introdurre problemi di sicurezza, spesso sotto forma di denial of service (ad esempio, quando un servizio si blocca a causa della scarsa gestione degli errori) e divulgazione di informazioni (ad esempio, quando un'eccezione contiene dettagli sensibili il sistema viene propagato all'utente / utente malintenzionato).

Per combattere questo, il sistema deve fallire con grazia, rivelando piccoli dettagli sull'errore e recuperando il più possibile. Quando si tratta di eccezioni, i linguaggi gestiti dispongono di meccanismi semplici e ben compresi per la gestione delle eccezioni. Tuttavia, durante la mia ricerca non sono riuscito a trovare consigli su come costruire un meccanismo di gestione delle eccezioni appropriato nelle moderne applicazioni Web che includa diversi livelli di logica tra il database e le applicazioni client.

Ad esempio, il framework Spring ha il controller (che fornisce le API e gestisce le richieste HTTP), il servizio (che contiene la maggior parte della logica aziendale) e i repository (che gestiscono le comunicazioni tra l'applicazione e il database). Inoltre, il servizio può interfacciarsi con componenti e moduli di utilità che offrono varie funzionalità (ad es. Accesso ai file, calcolo degli algoritmi). Il seguente diagramma di flusso di dati illustra questa architettura.

Esaminandol'originedelleeccezioni,possiamovederecheilmotoredicalcolo,ilrepositoryel'utilitàdiaccessoaifilepossono(potenzialmente)rivelarealcunidettaglisulsistema,nelcasoincuiun'eccezionevengalanciatadurantel'interfacciamentoconidiversidatastore(es.suldatabaseSQL,sulloschemadellaknowledgebase,ecc.)

Ledomandediventanoquindi,doveglisviluppatoridevonogestirequesteeccezionieridurreilrischiosiadidivulgazionedelleinformazionichedidenialofservice?

Unapprocciochemisembraadattoègestireleeccezioninonappenasipresentanoeincluderleineccezionispecifichedell'applicazione.Lepartidell'applicazionechehannoflussididaticheattraversanounlimiteditrust(adesempio,alfilesystem,aInternet)dovrebberodisinfettaretutteleeccezioniincludendoleineccezionipersonalizzate"più amichevoli" (create dagli sviluppatori) per impedire qualsiasi rischio divulgazione di informazioni propagate ulteriormente, nonché per localizzare eventuali guasti di componenti. I componenti interni dovrebbero quindi sapere come gestire le eccezioni delle applicazioni in modo più appropriato.

Lo svantaggio principale di questo approccio è che il meccanismo di gestione delle eccezioni è più complesso, in quanto richiede l'introduzione di eccezioni specifiche per ogni categoria di eccezioni native (e applicabili).

Questo approccio ha altri pro e contro, e c'è un design alternativo che gestisca meglio l'equilibrio tra sicurezza e carico di lavoro?

    
posta Nikola Luburić 29.11.2018 - 19:48
fonte

1 risposta

0

Hai menzionato

where should developers handle these exceptions, and reduce the risk to both information disclosure and denial of service?

Le eccezioni dei tuoi servizi o programmi dovrebbero essere gestite dal programma / servizio come regola generale. Se il servizio non gestisce le eccezioni generate, potrebbe trattarsi di un problema di sicurezza a seconda dell'errore.

L'approccio corretto sarà verificare l'uso corretto dell'API, ad esempio se il tuo servizio utilizza la funzione HTTPPost che può generare ConnectionError o BadURI, è responsabilità del programma gestirlo correttamente per evitare percorsi sconosciuti nell'esecuzione di esso .

Ti do una buona pratica per il software che gira su backend come esempio, normalmente il servizio ha un metodo che gestisce la richiesta HTTP, SMTP o qualsiasi altra cosa e questo metodo è sempre su un blocco try e cattura tutte le eccezioni. Una volta installato, puoi iniziare a approfondire il tuo codice e fare di più specificare il blocco delle eccezioni e verificare che il tuo sistema sia stabile, speriamo che questo ti aiuti un po '.

    
risposta data 29.11.2018 - 20:58
fonte

Leggi altre domande sui tag