Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Os recursos de segurança fornecidos pelo Microsoft .NET Framework e pelo Microsoft Office podem ajudar a proteger suas soluções do Office contra possíveis ameaças à segurança. Este tópico explica algumas dessas ameaças e fornece recomendações para ajudar a proteger contra elas. Ele também inclui informações sobre como as configurações de segurança do Microsoft Office afetam as soluções do Office.
Aplica-se a: As informações neste tópico se aplicam a projetos no nível do documento e projetos de suplemento VSTO. Consulte os recursos disponíveis pelo aplicativo do Office e pelo tipo de projeto.
O código confiável é reaproveitado em um novo documento mal-intencionado
Um invasor pode usar um código confiável destinado a uma finalidade específica, por exemplo, baixar informações pessoais para um aplicativo de emprego e reutilizá-lo em outro documento, como uma planilha. O código não sabe que o documento original não está em execução e pode abrir outras ameaças, como revelar informações pessoais ou executar código com privilégios maiores, quando aberto por um usuário diferente. Como alternativa, o invasor pode modificar os dados na planilha de modo que, quando enviado à vítima, ele se comporte inesperadamente. Ao alterar os valores, fórmulas ou características de apresentação de uma planilha vinculada ao código, é possível que um usuário mal-intencionado ataque outro usuário enviando um arquivo modificado. Também pode ser possível que os usuários acessem informações que não deveriam ver modificando valores na planilha.
Como tanto o local da montagem quanto o local do documento devem ter evidências suficientes para serem executados, esse ataque não é fácil de realizar. Por exemplo, documentos em anexos de email ou em servidores de intranet não confiáveis não têm permissões suficientes para serem executados.
Para tornar esse ataque possível, o próprio código deve ser escrito de forma a tomar decisões com base em dados potencialmente não confiáveis. Um exemplo é a criação de uma planilha que tem uma célula oculta que contém o nome de um servidor de banco de dados. O usuário envia a planilha para uma página ASPX, que tenta se conectar a esse servidor usando a autenticação SQL e uma senha SA codificada em código. Um invasor pode substituir o conteúdo da célula oculta por um nome de computador diferente e obter a senha SA. Para evitar esse problema, nunca codifique as senhas de forma fixa e sempre verifique os identificadores do servidor em uma lista interna de servidores confiáveis antes de acessar o servidor.
Recommendations
Sempre valide a entrada e os dados, sejam eles provenientes do usuário, do documento, de um banco de dados, de um serviço Web ou de qualquer outra fonte.
Tenha cuidado ao expor determinados tipos de funcionalidade, como obter dados privilegiados em nome do usuário e colocá-los em uma planilha desprotegida.
Dependendo do tipo de aplicativo, pode fazer sentido verificar se o documento original está em execução antes de executar qualquer código. Por exemplo, verifique se está em execução a partir de um documento armazenado em um local conhecido e seguro.
Pode ser uma boa ideia exibir um aviso quando o documento for aberto se o aplicativo executar ações privilegiadas. Por exemplo, você pode criar uma tela inicial ou uma caixa de diálogo de inicialização informando que o aplicativo acessará informações pessoais e fazer com que o usuário escolha continuar ou cancelar. Se um usuário final receber tal aviso de um documento aparentemente inocente, ele poderá sair do aplicativo antes que qualquer coisa seja comprometida.
O código é bloqueado pela proteção do modelo de objeto do Outlook
O Microsoft Office pode restringir o uso de determinadas propriedades, métodos e objetos no modelo de objeto. Ao restringir o acesso a esses objetos, o Outlook ajuda a impedir que worms e vírus de email usem o modelo de objeto para fins mal-intencionados. Esse recurso de segurança é conhecido como o proteção do modelo de objeto do Outlook. Se um suplemento VSTO tentar usar uma propriedade ou método restrito enquanto o proteção do modelo de objeto estiver habilitado, o Outlook exibirá um aviso de segurança que permite que o usuário interrompa a operação ou permita que o usuário conceda acesso à propriedade ou ao método por um período limitado de tempo. Se o usuário interromper a operação, os Suplementos VSTO do Outlook criados usando soluções do Office no Visual Studio gerarão um COMException.
A proteção do modelo de objetos pode afetar complementos VSTO de diferentes maneiras, dependendo se o Outlook é usado com o Microsoft Exchange Server.
Se o Outlook não for usado com o Exchange, um administrador poderá habilitar ou desabilitar a proteção do modelo de objeto para todos os Suplementos VSTO no computador.
Se o Outlook for usado com o Exchange, um administrador poderá habilitar ou desabilitar o proteção do modelo de objeto para todos os Suplementos VSTO no computador ou o administrador poderá especificar que determinados Suplementos VSTO podem ser executados sem encontrar o proteção do modelo de objeto. Os administradores também podem modificar o comportamento do proteção do modelo de objeto para determinadas áreas do modelo de objeto. Por exemplo, os administradores podem permitir automaticamente que complementos VSTO enviem emails programaticamente, mesmo que a proteção do modelo de objeto esteja habilitada.
A partir do Outlook 2007, o comportamento do proteção do modelo de objeto foi alterado para melhorar a experiência do desenvolvedor e do usuário, ajudando a manter o Outlook seguro. Para obter mais informações, consulte Alterações de segurança de código no Outlook 2007.
Minimizar avisos de proteção do modelo de objeto
Para ajudar a evitar avisos de segurança ao usar propriedades e métodos restritos, verifique se o suplemento VSTO obtém objetos do Outlook do Application campo da ThisAddIn classe em seu projeto. Para obter mais informações sobre esse campo, consulte Suplementos VSTO de programas.
Somente objetos do Outlook obtidos desse objeto podem ser confiáveis pela proteção do modelo de objetos. Por outro lado, os objetos obtidos de um novo Microsoft.Office.Interop.Outlook.Application objeto não são confiáveis e as propriedades e métodos restritos gerarão avisos de segurança se o proteção do modelo de objeto estiver habilitado.
O exemplo de código a seguir exibe um aviso de segurança se o proteção do modelo de objeto estiver habilitado. A propriedade To da classe Microsoft.Office.Interop.Outlook.MailItem é restrita pelo guardião do modelo de objeto. O Microsoft.Office.Interop.Outlook.MailItem objeto não é confiável porque o código o obtém de um Microsoft.Office.Interop.Outlook.Application que é criado usando o novo operador, em vez de obtê-lo do Application campo.
private void UntrustedCode()
{
Microsoft.Office.Interop.Outlook.Application application =
new Microsoft.Office.Interop.Outlook.Application();
Microsoft.Office.Interop.Outlook.MailItem mailItem1 =
application.CreateItem(
Microsoft.Office.Interop.Outlook.OlItemType.olMailItem) as
Microsoft.Office.Interop.Outlook.MailItem;
mailItem1.To = "someone@example.com";
MessageBox.Show(mailItem1.To);
}
O exemplo de código a seguir demonstra como usar a propriedade To restrita de um objeto Microsoft.Office.Interop.Outlook.MailItem protegido pelo mecanismo de segurança do modelo de objeto. O código usa o campo confiável Application para obter o Microsoft.Office.Interop.Outlook.MailItem.
private void TrustedCode()
{
Microsoft.Office.Interop.Outlook.MailItem mailItem1 =
this.Application.CreateItem(
Microsoft.Office.Interop.Outlook.OlItemType.olMailItem) as
Microsoft.Office.Interop.Outlook.MailItem;
mailItem1.To = "someone@example.com";
MessageBox.Show(mailItem1.To);
}
Observação
Se o Outlook for usado com o Exchange, a obtenção de todos os objetos do Outlook do ThisAddIn.Application não garante que seu Add-in VSTO poderá acessar todo o modelo de objeto do Outlook. Por exemplo, se um administrador do Exchange definir o Outlook para negar automaticamente todas as tentativas de acessar informações de endereço usando o modelo de objeto do Outlook, o Outlook não permitirá que o exemplo de código anterior acesse a propriedade To, mesmo que o exemplo de código use o campo confiável ThisAddIn.Application .
Especificar em quais suplementos confiar ao usar o Exchange
Quando o Outlook é usado com o Exchange, os administradores podem especificar que determinados Suplementos VSTO podem ser executados sem passar pela proteção do modelo de objeto. Suplementos VSTO do Outlook criados usando soluções do Office no Visual Studio não podem ser confiados individualmente; eles só podem ser confiados em grupo.
O Outlook confia em um Suplemento VSTO com base em um código de hash da DLL do ponto de entrada do Suplemento VSTO. Todos os Suplementos VSTO do Outlook destinados ao runtime das Ferramentas do Visual Studio para o Office usam a mesma DLL de ponto de entrada (VSTOLoader.dll). Isso significa que, se um administrador confiar em qualquer Suplemento VSTO que tenha como alvo o runtime do Visual Studio Tools for Office para ser executado sem encontrar a proteção do modelo de objeto, todos os outros Suplementos VSTO que têm como alvo o runtime do Visual Studio Tools for Office também são confiáveis. Para obter mais informações sobre como confiar em suplementos específicos do VSTO para serem executados sem acionar a proteção do modelo de objeto, consulte Especifique o método que o Outlook usa para gerenciar recursos de prevenção de vírus.
As alterações de permissão não entrarão em vigor imediatamente
Se o administrador ajustar as permissões de um documento ou assembly, os usuários deverão encerrar e reiniciar todos os aplicativos do Office para que essas alterações entrem em vigor.
Outros aplicativos que hospedam aplicativos do Microsoft Office também podem impedir que as novas permissões sejam impostas. Os usuários devem encerrar todos os aplicativos que usam o Office, hospedados ou autônomos, quando as políticas de segurança são alteradas.
As configurações da central de confiabilidade no sistema do Microsoft Office não afetam suplementos ou personalizações no nível do documento
Os usuários podem impedir que suplementos VSTO carreguem configurando uma opção na Central de Confiabilidade. No entanto, suplementos VSTO e personalizações no nível do documento criados usando soluções do Office no Visual Studio não são afetados por essas configurações de confiança.
Se o usuário impedir que suplementos VSTO carreguem usando a Central de Confiabilidade, os seguintes tipos de Suplementos VSTO não carregarão:
Suplementos COM VSTO gerenciados e não gerenciados.
Documentos inteligentes gerenciados e não gerenciados.
Suplementos VSTO de automação gerenciados e não gerenciados.
Componentes de dados em tempo real gerenciados e não gerenciados.
Os procedimentos a seguir descrevem como os usuários podem usar a Central de Confiabilidade para restringir o carregamento de suplementos VSTO no Microsoft Office 2013 e no Microsoft Office 2010. Esses procedimentos não afetam suplementos VSTO ou personalizações criadas usando ferramentas de desenvolvimento do Office no Visual Studio.
Para desabilitar complementos VSTO nos aplicativos Microsoft Office 2010 e Microsoft Office 2013
Escolha a guia Arquivo .
Escolha o botão ApplicationNameOpções.
No painel de categorias, escolha Central de Confiabilidade.
No painel de detalhes, escolha Configurações da Central de Confiabilidade.
No painel categorias, escolha Suplementos.
No painel de detalhes, selecione Exigir que os Suplementos de Aplicativo sejam assinados pelo Trusted Publisher ou desabilite todos os Suplementos de Aplicativo.