Perché abbiamo bisogno della sicurezza a livello di metodo?

Nel mondo reale, perché dobbiamo implementare la sicurezza a livello di metodo?

Abbiamo un'applicazione web o un'applicazione desktop, in cui l'utente accede all'interfaccia utente (e quindi direttamente non può accedere al metodo).

Quindi da dove vengono qui direttamente i metodi di accesso?

modifica: faccio questa domanda perché sto sperimentando la sicurezza primaverile e vedo autorizzare gli utenti ad accedere ai metodi.

qualcosa di simile a :

 @ROLE_ADMIN
public void update() {
      //update
}

In un'applicazione progettata correttamente, il backend e il frontend sono disconnessi. Il sistema di sicurezza del back-end non può presumere che uno specifico frontend gestisca correttamente la sicurezza, quindi deve gestirla da sola.

Presumo che tu stia parlando dell'accesso basato sui ruoli alle azioni in un controller. Vale a dire in un'architettura MVC ogni metodo su una Controllerclasse è un'azione separata. La maggior parte dei framework MVC che ho usato mi consente 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 un controllo più fine per l'accesso basato sui ruoli, considerare questo:

• È conveniente raggruppare tutte le azioni attorno a una risorsa. Vale a dire le tue azioni Crea / Leggi / Aggiorna / Elimina (CRUD) per articoli, account, ecc. Ciò semplifica la scrittura e la gestione delle API in stile REST.
• Molti sistemi hanno credenziali / ruoli diversi richiesti per le azioni Crea / Aggiorna / Elimina rispetto alle azioni Leggi.
• Se tutte le azioni relative agli account utente si trovano in un controller, si desidera consentire a chiunque di accedere, ma solo determinate persone possono creare nuovi account o assegnare ruoli.

Piaccia o no, quando Ruby on Rails ha colpito le onde radio alcuni anni fa, quasi ogni framework MVC ha copiato il suo approccio progettuale fondamentale. In passato le azioni erano classi separate, ma la logica delle azioni tende a essere piccola e focalizzata, quindi un sovraccarico di classe completo è eccessivo. Mappare un metodo su un controller all'azione per una pagina in realtà aveva molto senso. Sappi solo che molte persone hanno bisogno di un controllo approfondito su quali ruoli possono svolgere 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, prendere in considerazione un caso in cui diversi utenti possono eseguire le stesse azioni "dirette" (quindi la sicurezza del client non è pertinente). ma in alcuni casi la loro azione può innescare un comportamento che si desidera limitare - in questo caso la sicurezza a livello di metodo può essere una soluzione pertinente.

Mike Wiesner ha ricordato in questa presentazione di SpringSource, Introduzione a Spring Security 3 / 3.1 , fornito l'esempio che Tomcat e molti altri contenitori Servlet avevano un bug che non riusciva a riconoscere correttamente "../", quando codificato in Unicode, in un modo che un semplice test di uguaglianza fallirebbe in Java, ma si tradurrebbe 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 il controllo di sicurezza prima.

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

In tal caso, non esistono ai fini della sicurezza. Esistono allo scopo di semplificare o garantire che il software sia correttamente modulare. (Se riescono in questo è un dibattito, lo lascerò per gli altri. Questa è, comunque, la visione di ciò che sono.)

Supponiamo che io consegni una biblioteca, quindi sono libero di consegnare in seguito una versione diversa della biblioteca e cambiare le cose contrassegnate come private quanto voglio. Al contrario, se non avessi contrassegnato quelle cose come private, non sarei in grado di cambiare alcun interno del mio software perché qualcuno, da qualche parte, probabilmente sta accedendo direttamente ad esso. Certo, in teoria è colpa loro se non hanno usato l'API documentata. Ma il cliente lo percepirà come colpa mia se il mio aggiornamento del software ha rotto il loro software. Non vogliono scuse, lo vogliono riparato. 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 è evitato.

La seconda cosa più probabile di cui potresti parlare è il modello di sicurezza di Java. Se ne stai parlando, la ragione per cui esiste è che la visione originale per Java prevedeva che le persone inviassero applet probabilmente non attendibili per lavorare in modo interattivo all'interno di programmi di terze parti (ad esempio browser). Pertanto, il modello di sicurezza doveva fornire agli utenti una protezione contro le applet dannose. Pertanto, la minaccia alla sicurezza di cui preoccuparsi e da cui proteggere è l'applet non attendibile che tenta di interagire con altri software che potrebbero essere caricati.