Polymorphism e potenziali problemi di sicurezza

In termini di accesso di classe / membro, direi che "sicurezza" riguarda più la sicurezza API . Quando pubblichi un codice che è abbastanza aperto, altri potrebbero finire per usare il tuo codice in modi che non intendevi, che rendono più difficile per te apportare cambiamenti interni e senza interruzione in futuro.

Mentre alcune delle scelte che fai in classe OOP / accesso ai membri possono influenzare la sicurezza complessiva del tuo sistema da attacchi esterni, quelle scelte non sono strettamente correlate alla sicurezza da quel tipo di attacchi. Una volta che si sta già condividendo lo spazio di esecuzione del programma, nella maggior parte dei casi l'altro programma può davvero fare quasi tutto ciò che vuole fare, in un modo o nell'altro. (Ad esempio, è possibile accedere ai membri private in Java tramite il reflection abbastanza facilmente tramite setAccessible .)

Quando si sviluppano API, questi tipi di hack non sono mai supportati dall'autore della libreria, quindi sono "usati a proprio rischio". Con una buona strategia di accesso in campo / classe, le API possono essere sottoposte a refactoring estensivo con poche interruzioni API esterne.

Ho rintracciato l'articolo a cui ti riferisci , e il contesto aiuta a chiarire questo problema.

Il punto tre è in realtà correlato alla mia risposta originale sopra:

3) Compatible. If in the future I discover that I should have sealed a class, I'm stuck. Sealing a class is a breaking change. If I discover that I should have left a class unsealed, unsealing in a future version is a non-breaking change. Sealing classes helps maintain compatibility.

Il prossimo punto elenco è la tua citazione originale:

4) Secure. the whole point of polymorphism is that you can pass around objects that look like Animals but are in fact Giraffes. There are potential security issues here.

Seguente aiuta a chiarire i problemi a cui Eric si riferisce:

Every time you implement a method which takes an instance of an unsealed type, you MUST write that method to be robust in the face of potentially hostile instances of that type. You cannot rely upon any invariants which you know to be true of YOUR implementations, because some hostile web page might subclass your implementation, override the virtual methods to do stuff that messes up your logic, and passes it in. Every time I seal a class, I can write methods that use that class with the confidence that I know what that class does.

In questo caso, Eric si riferisce chiaramente a casi in cui un sistema potenzialmente ostile è effettivamente in grado di interagire con il tuo sistema con codice . In questo caso, il polimorfismo diventa un problema, dal momento che, come dice Eric, quando fai chiamate sugli oggetti che vengono passati, l'oggetto potrebbe fare qualcosa che non avresti intenzione di fare.

Classi di suggellamento significa che l'oggetto che è passato non può essere sottoclassato in quel modo. Ovviamente non ci sarebbe bisogno di questo se il tuo sistema non ha intenzione di interagire con i chiamanti API potenzialmente ostili. Come diceva la mia risposta originale, spesso questo è un rischio di sicurezza così difficile da gestire in sé e per sé che è semplicemente del tutto respinto.

Supponiamo che tu crei una classe di convalida della sicurezza, che viene passata al tuo modulo principale da un IoC. Poiché si utilizza questa struttura per alcuni sistemi diversi, come un buon programmatore, si crea una classe base con la maggior parte della logica e si inserisce il codice specifico del sistema nelle classi derivate.

Un utente malintenzionato dà un'occhiata e trova questo modello di metodo del modello. Vede anche che una parte chiave del puzzle, una proprietà "SecurityDBConnString", è astratta (perché è usata dalla logica della classe base ma non può essere specificata lì come specifica per il sistema), e quando la si sovrascrive per il sistema è interessato, non lo hai sigillato. L'attaccante spara alla sua copia VS incrinata, ricava la sua classe dalla tua, oltrepassando SecurityDBConnString per puntare a un sistema che controlla, quindi modifica le registrazioni IoC da passare nella sua nuova classe. Ora è dentro e sei nei guai.

Questo sarebbe stato molto più difficile se avessi semplicemente sigillato la tua classe derivata o la proprietà soggetta a modifiche al suo interno. Sarebbe ancora più difficile se tu avessi offuscato la tua libreria di sicurezza, ma sto divagando; se non vuoi che qualcuno tragga la tua classe, sigilla. Ti risparmierai molti mal di testa.