Separazione di preoccupazioni e sicurezza

Question

Separazione di preoccupazioni e sicurezza

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

3

Il sistema che sto sviluppando è progettato per avere più organizzazioni, con utenti e ruoli per ciascuna organizzazione. Alcune organizzazioni possono interagire, altre no, e in generale le organizzazioni non sono autorizzate a vedere o modificare gli altri dati con alcune eccezioni.

Ho una classe modello A che manipola l'archiviazione dei dati in un contenitore di memorizzazione permanente di qualche tipo. Ho una classe di controller B che convalida l'input (compresa la verifica dei diritti di accesso) agli oggetti di classe A.

Le classi controller sono in una libreria separata dalle classi del modello.

Tutte le interazioni dell'utente vengono eseguite dalle classi di vista che sono di nuovo in una libreria separata (in questo caso esposta come servizi Web).

Tuttavia, sembra vi sia un possibile rischio per la sicurezza nel mantenere la logica di controllo degli accessi separata dal modello, poiché non verranno eseguiti controlli di sicurezza se il modello non ha accesso al controllore associato e vi si accede invece da qualche altro codice dovuto a qualche malintenzionato o errore del programmatore.

Devo inserire la logica di sicurezza nelle stesse classi del modello che intreccia queste preoccupazioni o devo mantenere la separazione come ho ora?

security separation-of-concerns

posta Peter Smith 17.07.2012 - 18:40

fonte

2 risposte

Leggi altre domande sui tag security separation-of-concerns

Posso distribuire software che utilizza Microsoft Visual Basic 2010 Express Edition? Sistemi di autenticazione - Separati per la gestione?

score 5 · Answer 1

Preferirei vedere questi due concetti in due classi separate. Il motivo è che è un design più semplice e pulito, che di solito significa che avrà meno bug (inclusi bug di sicurezza). Il design di alcuni è più semplice, di solito presenta anche meno problemi (inclusi problemi basati sulla sicurezza).

L'attacco che stai proteggendo può avvenire solo attraverso l'errore del programmatore. Non vedo come un utente malintenzionato possa eludere il controller e colpire direttamente il modello, a meno che non si stia facendo qualcosa di molto strano nel proprio sistema. L'errore di programmazione in questione sta utilizzando il modello direttamente e non tramite un controllo. Penso che questa sia chiaramente la cosa "sbagliata" da fare e la maggior parte degli sviluppatori non farebbe qualcosa del genere. Tuttavia, dovresti eseguire revisioni del codice per il codice di sicurezza e questo è il posto migliore per cogliere questo tipo di problemi.

Ricorda che uno sviluppatore può distruggere i controlli di sicurezza in molti modi diversi. Hanno accesso completo al codice e ci sono innumerevoli modi per rovinare qualcosa. La soluzione migliore è scrivere il codice nel modo più pulito possibile e applicare pratiche come le revisioni del codice.

score 0 · Answer 2

IMO, il tuo istinto è buono. Per me è fondamentale, duh OOP, mettere un qualche tipo di controllo di accesso sulla classe / oggetto che controlla i dati. Quella unità di controllo dei dati potrebbe fare qualcosa di semplice come dire al richiedente di andare a validarsi da qualche altra parte e fornire credenziali valide se si ritiene che la logica di validazione debba essere scissa ma IMO, è molto più sicuro nel lungo periodo che il controllo dell'accesso è almeno avviato dall'oggetto che distribuisce i dati potenzialmente sensibili prima di farlo.

Se lo dividi, c'è un rischio maggiore che qualcuno riutilizzi il codice o apporti modifiche e semplicemente ipotizzi che venga gestito in qualche altro modo con cui potrebbero essere utilizzati. Oppure potrebbero semplicemente non interessarsene. Mettendo quel call per la convalida su quell'oggetto di gestione dei dati, li costringe a dimostrare almeno che non gliene importa disabilitando la convalida per la convalida e lasciandone la prova nel controllo del codice sorgente.

Va bene che le classi diventino un po 'grandi finchè servono lo scopo della classe. Ho visto troppe codebust arrestate in 10.000 1 o 2 classi di metodi che non sono in realtà diverse da 10.000 funzioni nel codice procedurale mal progettato dalla vecchia scuola, che l'OOP ha lo scopo di aiutare le persone a migliorare. Il conteggio delle righe non importa se si stanno isolando le responsabilità in base alla progettazione in modo da non avere potenzialmente migliaia di mani sugli stessi dati persistenti (un vero divertimento per il debug) o un numero infinito di modi per esporre alcuni outfit scaduti in outsourcing dati confidenziali per errore molto tempo dopo aver lasciato il codice base indietro.