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?