Práticas recomendadas de segurança em que o SDK do Visual Studio
Parceiros VSIP devem reconhecer que eles têm a responsabilidade de compreender as vulnerabilidades de segurança para que eles possam criar os melhores produtos possíveis.
Um produto seguro ajuda a proteger o seguinte:
Confidencialidade, integridade e disponibilidade das informações do cliente.
Integridade e disponibilidade dos recursos de processamento sob o controle do proprietário do sistema ou do administrador.
Vulnerabilidade de segurança
Uma vulnerabilidade de segurança é um ponto fraco em um produto que torna impossível impedir atividades mal-intencionadas do invasor, mesmo quando o produto é usado corretamente. Aqui estão alguns possíveis atividades mal-intencionadas:
Como obter as permissões em um computador que são maiores que as do usuário.
Assumir a operação do computador do usuário.
Comprometer dados em um computador do usuário.
Importante
Nunca suponha que seu aplicativo será executado somente em ambientes específicos.Seu aplicativo pode ser usado nas configurações que você não esperava, especialmente quando o aplicativo ficar popular.Em vez disso, suponha que seu código será executado em ambientes hostis e projetar, gravar e testar seu código de maneira adequada.
Produtos e sistemas projetada e construída com a segurança como um recurso excelente são mais robustos do que aqueles criados com segurança em segundo plano. Produtos seguros também são mais imune a crítica de mídia mais atraente para os usuários e mais barato e suporte e upgrade.
APIs perigosas
Muitas pessoas vendem determinadas APIs como perigosos. Embora chamadas para algumas funções podem produzir a vulnerabilidades de segurança indesejadas se forem usadas incorretamente, proibir seu uso não necessariamente produzem código seguro. No entanto, alguns projetos de software tem obtido ganhos significativos em segurança por proibir funções que são difíceis de usar com segurança, como uma das muitas práticas de desenvolvimento seguro. Para obter mais informações, consulte o Apêndice A do livro Microsoft Press, "Writing Secure Code" de Michael Howard e David LeBlanc.
O mais importante para compreender em qualquer discussão de APIs perigosas é que a maioria dos problemas de segurança resultam de confiar em entrada sem verificá-lo de forma adequada. Certifique-se de que você deseja rastrear os dados como se apresentarem em seu código e questionar as implicações das operações de dados. Você pode escrever código seguro usando a maioria das funções se as entradas de dados estiverem bem formados e verificado se há confiabilidade.
Controle de conta de usuário (UAC) no Windows Vista
Windows VistaAdiciona um recurso chamado controle de conta de usuário (UAC), que tem implicações de segurança que os desenvolvedores de VSPackage precisam entender. O UAC reduz a possibilidade de ataque do sistema operacional e dos aplicativos. Para obter mais informações, consulte as práticas recomendadas do desenvolvedor e diretrizes para aplicativos em um ambiente de privilégio mínimo.
Para instalar o Visual Studio na Windows Vista, você deve ter direitos de administrador.
Com o UAC, um usuário administrativo tem os mesmos direitos que um usuário padrão até que um processo que requer direitos de administrador é requisitado. O processo solicitado solicita ao usuário de administrador a permissão continuar. Se concedido, permissão dura somente até que o processo for concluído. Por exemplo, gravando um diretório em arquivos de programa ou de uma chave na seção do Registro HKEY_LOCAL_MACHINE pasta requer direitos de administrador; com o UAC, permissão explícita de um usuário administrador é necessário para concluir a operação de gravação.
Para minimizar o número de avisos, elevação de UAC de direitos afeta todo um processo e ocorre somente quando o processo é iniciado. Elevação de direitos para VSPackages ocorre quando Windows Vista é iniciado. Um VSPackage não pode ser executado em um nível diferente de direitos que Visual Studio e outros VSPackages.
Antes de Windows Vista introduziu o UAC, os desenvolvedores geralmente executou Visual Studio em permissões de administrador, mesmo quando eles não eram exigidos. Portanto, eles também ficou apenas VSPackages que tinham permissões de administrador. Isso é válido ainda.
Visual Studio 2005deve ser executado em um processo elevado Windows Vista. Portanto, os VSPackages também executar um processo elevado. No entanto, as futuras versões do Visual Studio não pode exigir a elevação. Certifique-se no futuro que seu VSPackages exige direitos elevados desnecessariamente.
Observe que o UAC também afeta a implantação. Pacotes do Windows Installer devem ser criados corretamente para oferecer suporte ao UAC. Um pacote criado incorretamente geralmente faz com que os erros de "acesso negado" porque o mecanismo Windows Installer tenta usar direitos padrão para executar uma tarefa que exige direitos elevados.
Consulte também
Conceitos
Práticas recomendadas de segurança no VSPackages