Perché abbiamo bisogno della sicurezza a livello di metodo?

In un'applicazione progettata correttamente, il backend e il front-end sono disconnessi. Il sistema di sicurezza del backend non può supporre che qualsiasi frontend specifico gestisca correttamente la sicurezza, quindi deve gestirlo da solo.

Presumo che tu stia parlando dell'accesso basato sui ruoli alle azioni in un controller. Cioè in un'architettura MVC ogni metodo su una classe Controller è un'azione separata. La maggior parte dei framework MVC che ho usato mi consentono di assegnare privilegi sia a livello di metodo che a livello di classe. Ciò significherebbe che posso applicare un attributo / annotazione a livello di classe e il ruolo corrispondente sarebbe richiesto per ogni azione in quel controller.

Per quanto riguarda il controllo a grana fine per l'accesso basato sui ruoli, considera questo:

• È conveniente raggruppare tutte le azioni attorno a una risorsa. Cioè le tue azioni Create / Read / Update / Delete (CRUD) per articoli, account, ecc. Questo rende più facili da scrivere e mantenere le API di stile REST.
• Molti sistemi hanno credenziali / ruoli diversi richiesti per le azioni Crea / Aggiorna / Elimina di quanto non facciano per le azioni di lettura.
• Se tutte le azioni dell'account utente si trovano in un controller, devi consentire a chiunque di accedere, ma solo alcune persone possono creare nuovi account o assegnare ruoli.

Piaccia o no, quando Ruby on Rails ha colpito l'etere qualche anno fa, quasi ogni framework MVC ha copiato il suo approccio progettuale fondamentale. Un tempo le azioni erano classi separate, ma la logica di azione tende ad essere piccola e focalizzata, quindi un overhead di classe completo è eccessivo. Mappare un metodo su un controller per l'azione per una pagina ha davvero molto senso. Sappi solo che molte persone hanno bisogno di un controllo preciso su quali ruoli possono eseguire quali funzioni.

La sicurezza a livello di metodo è utile per due motivi principali:

• come un altro livello di sicurezza (oltre ad altri livelli)

• nei casi in cui è più conveniente o logico disporre delle autorizzazioni a livello di metodo considera un caso in cui diversi utenti possono eseguire le stesse azioni "dirette" (quindi la sicurezza del client non è rilevante). ma in alcuni casi la loro azione può innescare un comportamento che desideri limitare - in questo caso la sicurezza a livello di metodo può essere una soluzione pertinente.

Mike Wiesner ha ricordato in questa presentazione SpringSource, Introduzione a Spring Security 3 / 3.1 , ha portato l'esempio che Tomcat e molti altri contenitori di Servlet avevano un errore che non riusciva a riconoscere correttamente "../", quando codificati in unicode, in modo che un semplice test di uguaglianza fallisse in Java, ma si traducesse nella directory superiore nel filesystem .

La sicurezza è difficile, più livelli di sicurezza, miglioreranno le possibilità di bloccare i tentativi di elusione. Poiché la sicurezza a livello di metodo è codificata direttamente all'interno della classe, dopo l'aumento AOP, quando si chiama il metodo, si chiamerà sempre prima il controllo di sicurezza.

Suppongo che tu stia parlando di metodi pubblici, privati e protetti qui?

Se è così, allora non esistono allo scopo di sicurezza. Esistono allo scopo di semplificare o garantire una corretta modularizzazione del software. (Sia che ci riescano, è un dibattito che lascerò agli altri, ma è la visione di quello che sono.)

Supponiamo che io fornisca una libreria, quindi sono libero di consegnare in seguito una versione diversa della libreria e di cambiare le cose contrassegnate come private quanto voglio. Al contrario, se non avessi contrassegnato quella roba privata, non sarei in grado di modificare alcun interno del mio software perché qualcuno, da qualche parte, probabilmente lo sta accedendo direttamente. Certo, in teoria è colpa loro se non si utilizza l'API documentata. Ma il cliente percepirà come colpa mia se il mio aggiornamento software ha rotto il loro software. Non vogliono scuse, lo vogliono sistemare. Ma se non permetto loro di avere accesso all'inizio, allora la mia API è esattamente i metodi pubblici che intendevo essere la mia API e il problema è stato evitato.

La seconda cosa più probabile di cui si potrebbe parlare è il modello di sicurezza di Java. Se stai parlando di questo, la ragione per cui esiste è che la visione originale di Java ha coinvolto persone che inviavano eventualmente applet non affidabili a lavorare in modo interattivo all'interno di programmi di terze parti (ad esempio i browser). Pertanto, il modello di sicurezza aveva lo scopo di offrire agli utenti una certa protezione contro le applet dannose. Pertanto, la minaccia alla sicurezza di cui preoccuparsi e proteggerli è rappresentata da applet non affidabili che tentano di interagire con altri software che potrebbero essere caricati.