Riapro la serie .NET Security con un post, a mio modo di vedere, importante. Stiamo parlando della sicurezza di .NET ed il suo inevitabile scontro con la sicurezza del sistema operativo.

Come abbiamo avuto modo di vedere, .NET ha molto da offrire quando si parla di permessions e di sicurezza in generale, tuttavia questo non significa che .NET sia immune o superiore alle policy di sicurezza definite dal sistema operativo.

Ragionando per esempi, inviterei a verificare il funzionamento del seguente metodo.

[method: FileIOPermission(SecurityAction.Demand,Write = IMAGE_DIR)]
public void SalvaImmagine(string NomeImmagine)
{
     FileName = IMAGE_DIR + NomeImmagine 
     if(true == File.Exists(NomeImmagine))
     {
        File.Delete(NomeImmagine));
     }

     FileStream fs = File.Create(NomeImmagine));
     fs.Write(this.m_Image, 0, (int)this.m_Image.Length);
     fs.Close();
}


Lo scopo di questo metodo è semplice: archiviare una immagine all'interno di un percoso specificato in IMAGE_DIR. Il programmatore si è assicurato i permessi di scrittura nella cartella IMAGE_DIR specificando, tramite FileIOPermission, il permesso di scrittura. Eseguendo l'operazione si una macchina standard non si noterà alcun tipo di eccezione.  E da qui la frase principale del post :

"Poter fare quello che si vuole in .NET non significa poter fare quello che si vuole del SO".

Per dimostrare quanto sia errato pensare il contrario si esegua questo semplice test.

  1. Aprire nel gestore di finestre di Windows (Explorer) la cartella definita in IMAGE_DIR.
  2. Selezionare la voce Proprietà.
  3. Alla voce Sicurezza rimuovere i permessi di scrittura all'utente Everyone.
  4. Rilanciare il codice.


A questo punto non resta che godersi la vista della bellissima UnauthorizedAccessException e confermare quanto segue. 

  • .NET è, e deve essere considerato, una astrazione del sistema operativo, il quale rende possibile programmare applicativi di diverso genere e natura. Nulla di più, nulla di meno.
  • .NET è dipendente dal sistema operativo, sempre.
  • Pretendere di far girare le vostre applicazioni su server aggiornati e correttamente configurati è da considerarsi un investimento sullo sviluppo aziendale. Di sua natura sviluppare pensando alla sicurezza richiede un 40% in più rispetto ad un metodo di sviluppo alternativo. Non ha senso spendere questo tempo se il SO ed il server in generale non sono sicuri.