Será que um navegador da Web C # /. Net ser suscetíveis a ataques?

Question

É correto dizer que a plataforma .Net é mais seguro porque os guardas CLR contra ataques de estouro de buffer?

Assumindo que não era um navegador web rodando em um sistema operacional gerenciados (como Cosmos , SharpOS ou Singularity ), seria tecnicamente possível a um atacante para injetar código IL para o aplicativo?

Eu teria que se preocupar com ataques que não são possíveis em aplicativos não gerenciados?

Answer 1

Para a maior parte, você está correto. As aplicações com um sistema de tipo seguro (não apenas .NET ou Java) não permitem a aplicação de violar essas restrições.

buffer overflows e muitas outras façanhas de código remoto ocorrer porque as restrições nesses idiomas e tempos de execução não fornecem nenhuma verificação e não pode garantir que o programa não vai fazer algo como executar código arbitrário na memória. sistemas seguros verificar o código para ser livre de esses efeitos.

(Como uma nota lateral, C # pode ainda realizar ações inseguras e fixou-se para executar código arbitrário. É apenas bastante complicada e improvável de ser usado em uma aplicação real.)

As falhas de segurança que você veria em um navegador gerido seria se deixar de código arbitrário ser carregado, usando o CLR como um ambiente seguro. Enquanto o código gerado CLR (isto é, a JIT'd de sua aplicação) será seguro, o carregador e verificador-se geralmente são escritos em uma linguagem mais baixo. Tem havido alguns (eu acho que 2 para .NET?) Falhas de segurança onde um maliciosamente formados montagem poderia forçar o CLR real para executar código arbitrário. No entanto, estas são questões relativamente raros, e a área de superfície é muito menos do que seria de outra forma.

Então, sim, um, próprio navegador gerido totalmente segura seria não cedam a essas exploits específicos. Mas isso também significa que você teria que ter seus plugins escrito e executado de forma semelhante (Flash?). Finalmente, existem outras falhas de segurança que podem ser direcionados, mas geralmente eles vão ser menos grave do que você encontraria com um aplicativo não gerenciado. Cross-site scripting, por exemplo, ainda permaneceria um problema. Mas pelo menos você não teria "visualização de um documento pode executar código arbitrário" problemas tipo.

Answer 2

O CLR (eo JVM) guarda contra uma série de ataques comuns, mas que não elimina todas as ameaças. O CLR ou qualquer biblioteca pode conter bugs que permitem façanhas. erros de aplicação pode permitir exploits também. injecção SQL é um exemplo de um ataque que é possível devido à falta de validação de entrada na aplicação.