10 dicas para escrever aplicativos seguros em ASP.NET

A segurança é um dos aspectos mais importantes de qualquer aplicativo – e quando falamos de segurança, principalmente em aplicativos ASP.NET, não se limita ao desenvolvimento.

Um aplicativo seguro envolve várias camadas de segurança na configuração, estrutura, servidor web, servidor de banco de dados e muito mais. Neste post, veremos as nove principais dicas para escrever aplicativos seguros em ASP.NET.

1. Cross Site Scripting (XSS)

Essa vulnerabilidade permite que um invasor injete algum código malicioso ao inserir dados. Pode ser código JavaScript, script VB ou qualquer outro código de script. Por padrão, o ASP.NET MVC valida as entradas e gera um erro de servidor no caso de script. Digamos que colocamos o script no formulário de entrada:

Quando enviarmos a página acima, obteremos o erro abaixo:

Por padrão, o mecanismo de exibição razor protege contra ataques XSS. Mas há certos cenários (blogs, aplicativos sociais etc.) em que talvez seja necessário permitir tags html em controles de entrada. Para isso, temos a opção de adicionar o filtro ValidateInput como false:

[HttpPost]
[ValidateInput(false)]
public async Task < ActionResult > Register(RegisterViewModel model) {
    if (ModelState.IsValid) {
        //  Etc.
    }
}

Mas isso é muito arriscado porque aqui não estamos validando a solicitação completa. Digamos que o modelo tenha vinte propriedades, todas estarão isentas da validação, embora talvez precisemos permitir html em apenas um ou alguns controles.

Nesse cenário, em vez de usar esse ValidateInput, devemos colocar o atributo an AllowHTML na propriedade específica do ViewModel como:

public class RegisterViewModel {
    [Required]
    [AllowHtml]
    [Display(Name = "User Name")]
    public string Name {
        get;
        set;
    }
...
}

Agora podemos usar tags apenas para o nome.

2. Falsificação de recursos entre sites (CSRF)

O CSRF (também conhecido como ataque de um clique) é um tipo de ataque malicioso em que comandos não autorizados são disparados de um site confiável onde o usuário é autenticado. No cenário do mundo real, digamos que o usuário tenha feito login em um aplicativo com autenticação baseada em windows/cookie. Agora, sem sair, o usuário visita um site malicioso e clica em um botão. O site externo inicia uma solicitação por meio de seu site para fazer uma operação antiética. Ele será considerado uma solicitação válida porque a solicitação foi autenticada.

Para evitar ataques CSRF, o MVC fornece o mecanismo AntiForgeryToken. Para isso, precisamos usar o auxiliar AntiForgeryToken em vista como

@Html.AntiForgeryToken()

E para validar o token, precisamos colocar o filtro Antiforgerytoken sobre a ação como:

[ValidateAntiForgeryToken]
public async Task < ActionResult > Register(RegisterViewModel model) {
    if (ModelState.IsValid) {
        // etc.
    }
    return View(model);
}

Ele cria dois tokens em resposta, um é definido como um cookie e outro é definido em um campo oculto como:

<form action="/Account/Register" class="form-horizontal" method="post" role="form">
<input name="__RequestVerificationToken" type="hidden" value="Qorw9RPABdHoRC7AojnSnQYYuGZP5iPF63UFVSw_[…]" />

Ao enviar o formulário, ambos os tokens (cookie e campo oculto) são enviados ao servidor. Ambos são validados no servidor e, se um deles não estiver presente ou for adulterado, a solicitação não será permitida.

3. Handling Errors Properly

Erros estão fadados a acontecer e eles encontram seu caminho para chegar ao usuário. Mas se eles não forem tratados corretamente, os erros podem vazar informações internas para o mundo exterior, o que pode ser uma ameaça para o aplicativo. Seguir o YSOD é comum quando ocorre uma exceção sem tratamento:

Mas veja quanta informação ele está mostrando para o mundo exterior: código interno, estrutura de arquivo físico, rastreamento de pilha e a versão do ASP.NET e do .NET Framework.

Uma solução rápida pode ser definir o modo customErrors como:

<customErrors mode="On"></customErrors> 

Isso mostrará uma página de erro padrão ASP.NET no caso de cada erro. Para lidar com isso da melhor maneira, use o modo de erros personalizado RemoteOnly e tenha uma página de erro comum que é exibida em caso de erro.

<customErrors mode="RemoteOnly" redirectMode="ResponseRewrite" defaultRedirect="~/Error.aspx" />

Aqui estamos exibindo nossa própria página de erro em caso de erro.

4. SQL Injeção

A injeção de SQL é uma vulnerabilidade de segurança bem conhecida, mas ainda não é tratada adequadamente em muitos aplicativos. A injeção de SQL permite que hackers adulterem dados existentes, modifiquem transações ou até mesmo excluam dados ou bancos de dados, o que pode ser uma grande perda para os negócios.

Usando essa técnica, o hacker injeta alguns comandos SQL maliciosos por meio de entrada. Esses comandos têm o poder de alterar a instrução SQL em execução no servidor.  Digamos que autenticando um usuário em um aplicativo, escrevemos uma consulta em uma classe como:

"select * from Users where UserName='"+txtUserName.Text+"'and Password='"+txtPwd.Text+"' ";

Agora o usuário coloca o seguinte valor no nome do usuário:

Agora a consulta será gerada no servidor como:

select * from Users where UserName='’ or 1=1 --' and Password='"+txtPwd.Text+"' ";

Isso sempre retornará itens e permitirá que os usuários entrem no aplicativo.

Para lidar com isso, a melhor maneira é usar o procedimento armazenado SQL, onde passaremos os valores de um parâmetro ou pelo menos usaremos os parâmetros como:

"select * from Users where UserName= @username and Password=@password”

5. Click-Jacking

O click-jacking é outra grande vulnerabilidade que é ignorada normalmente. Neste, o invasor usa uma camada opaca para induzir o usuário a clicar em um botão ou link em uma página diferente (digamos, botão de transferência no site do banco) enquanto ele deve clicar na página de nível superior.

Para evitar esse problema, não devemos permitir que nenhum site de domínio diferente no iframe seja aberto. Para conseguir isso, precisamos adicionar um cabeçalho de resposta X-FRAME-OPTIONS como deny ou sameorigin. No ASP.NET, podemos definir em Global.asax como:

void Application_BeginRequest(object sender, EventArgs e)
{
    HttpContext.Current.Response.AddHeader("X-FRAME-OPTIONS ", "DENY");
}

Ele adicionará o cabeçalho em todas as respostas enviadas pelo aplicativo.

Também podemos usar o IIS para adicionar o mesmo cabeçalho. No IIS, vá para o site pretendido, vá para a guia Cabeçalhos HTTP e adicione um cabeçalho personalizado com o cabeçalho X-FRAME-OPTIONS, conforme discutido. Você precisará reiniciar o IIS para colocá-lo em vigor.

6. Ocultar estrutura do aplicativo / listagem de diretórios

Gostaria de compartilhar a estrutura de pastas do seu aplicativo com o usuário final?  Não! Certo? Vejamos um exemplo. Eu implantei ASP.NET aplicativo padrão de formulários da web no IIS, então agora, quando eu acessar a URL, ela exibe:

Ele mostra todos os arquivos e pastas disponíveis em Conta. Essas informações podem ser uma ameaça potencial ao aplicativo se estiverem disponíveis publicamente.

A navegação de diretório deve ser desabilitada no IIS. Quando está desabilitado, vemos:

Ele retorna 403 (proibido), mas isso ainda deixa alguma vulnerabilidade, pois informa ao usuário que esta pasta está disponível. Quando tentamos acessar um diretório que não está disponível, ele retorna 404.

Para isso, podemos escrever nosso próprio manipulador http personalizado e configurá-lo para que ele sempre retorne 404 sempre que alguém tentar acessar uma pasta.

7. Encrypt Sensitive Information in Web.config

Muitas vezes, colocamos informações críticas no Web.config, mais comumente a cadeia de conexão.

Para criptografar qualquer parte da cadeia de conexão, precisamos navegar até a pasta do framework no prompt de comando (digamos C:\Windows\Microsoft.NET\Framework\v4.0.30319 ) e executar o seguinte comando:

aspnet_regiis -pef "connectionStrings" path

Aqui, path é o caminho da pasta em que Web.config reside. Depois de executar o comando, ele aparece como:

Da mesma forma, podemos criptografar outras seções como <appsettings> etc.

8. Secure Cookies

Cookies são pequenos textos armazenados por navegadores nas máquinas dos usuários que trafegam entre o servidor da web e o navegador. Os cookies são usados para armazenar as informações relacionadas ao usuário para o site específico. Em ASP.NET, o ID da sessão é uma das informações mais comuns para as quais os cookies são usados para salvar.

Como essas informações são armazenadas em texto simples na máquina de um usuário, elas podem ser um alvo fácil para invasores. Existem algumas etapas que precisamos seguir para evitar o armazenamento de dados em cookies, como definir uma data de validade e criptografar os dados. Além dessas duas etapas, há mais duas coisas que devemos fazer:

1. Permitir cookies apenas em SSL
2. Defina os cookies como HTTPOnly. Isso garante que os cookies não possam ser lidos pelo script do lado do cliente, portanto, nosso token de autenticação de sessão ou formulário não pode ser lido em um navegador.

Podemos fazer as configurações em Web.config como:

<httpCookies domain="String" httpOnlyCookies="true "requireSSL="true " />

9. Encrypting View State

O estado de exibição é uma das técnicas mais comuns usadas para manter o estado entre os PostBacks de página em formulários ASP.NET Web. O estado de exibição é salvo em uma variável oculta na página com id__VIEWSTATE. Quando vemos isso no código-fonte, descobrimos que ele contém uma série de números e caracteres. Certifique-se de que não esteja criptografado, mas no formato base64. Qualquer pessoa pode decodificá-lo para ler as informações.

Existem duas opções para criptografar e torná-lo à prova de adulteração. Há a propriedade ViewStateEncryptionMode, que pode ser definida no nível da página no arquivo aspx ou pode ser definida em Web.config, que se aplica a todas as páginas do aplicativo. Ele criptografa o estado de exibição antes de colocá-lo na resposta. Da mesma forma, outra propriedade, EnableViewStateMac, pode ser definida como true na página ou em Web.config. Ele cria um hash do conteúdo do estado de exibição e é adicionado no campo oculto. No próximo post de volta, novamente o hash é criado e verificado. Se não corresponder, o post back será rejeitado e um erro será gerado.

10. Remover informações confidenciais dos cabeçalhos de resposta

Aqui está o cabeçalho de resposta de uma página de um aplicativo ASP.NET:

Aqui podemos ver que ele está revelando muitas informações para o usuário final, o que ele não exige, como na versão do IIS, no site criado e na versão ASP.NET. Se um invasor conhece as brechas de qualquer um deles, ele pode explorar a vulnerabilidade. Essas informações são adicionadas por padrão e devemos removê-las, a menos e até que seja especificamente necessário.

1. Para remover ASP.NET cabeçalho de versão, só precisamos adicionar o seguinte no Web.config:

<system.web>
  <httpRuntime enableVersionHeader="false" />
</system.web>

2. Para remover a versão MVC, precisamos ir AppliCation_Start evento em Global.asax e adicionar o seguinte código:

MvcHandler.DisableMvcResponseHeader = true;

3. O X-Power-By é adicionado pelo IIS e pode ser removido adicionando a seguinte configuração

  <system.webServer>
        <httpProtocol>
            <customHeaders>
                <remove name="X-Powered-By" />
            </customHeaders>
        </httpProtocol>
  </system.webServer>

Conclusão

Neste post, discutimos que a segurança é fundamental para qualquer aplicativo da web e, se não for tratada adequadamente, pode prejudicar significativamente os negócios. Discutimos nove das vulnerabilidades mais comuns de ASP.NET aplicativos da Web e vimos que a maioria delas pode ser corrigida fazendo alguma alteração de configuração ou pequenas alterações de código.

Crie aplicativos de negócios completos para qualquer navegador com controles Infragistics ASP.NET! Baixe a avaliação gratuita agora.