Entradas e Saídas
A vulnerabilidade de segurança mais predominante das aplicações atuais é uma falha no processamento correto dos dados recebidos a partir de origens externas, em particular as entradas de utilizador. Deve analisar sempre com cuidado todas as entradas, para ter a certeza de que foram validadas antes de serem utilizadas. Não analisar a existência de possíveis ataques nas entradas de utilizador pode levar à perda ou exposição dos dados, à elevação de privilégios ou até mesmo à execução de código malicioso nos computadores de outros utilizadores.
O pior desta situação é que este é um problema fácil de resolver. Nesta unidade, abordaremos como tratar os dados quando são recebidos, quando são exibidos na tela e quando são armazenados para uso posterior.
Porque é que temos de validar as nossas entradas?
Imagine que você está criando uma interface para permitir que um usuário crie uma conta em seu site. Nossos dados de perfil incluem um nome, e-mail e um apelido que exibiremos para todos que visitarem o site. E se um utilizador novo criar um perfil e introduzir uma alcunha que incluam alguns comandos do SQL? Por exemplo, e se um usuário mal-intencionado inserir algo como o seguinte trecho:
Eve'); DROP TABLE Users;--
Se inserirmos este valor numa base de dados sem o analisarmos, o mesmo pode alterar a instrução SQL para executar comandos que não queremos executar! Este exemplo é referido como um ataque de "Injeção de SQL", que é um dos muitos tipos de explorações que podem ser feitas quando as entradas de utilizador não são processadas devidamente. Então, o que podemos fazer para corrigir esta situação? Esta unidade mostra-lhe como validar as entradas, como codificar as saídas e como criar consultas parametrizadas (que solucionam a exploração anterior). Estas são as três principais técnicas de defesa contra entradas maliciosas que são introduzidas nas suas aplicações.
Em que casos é que tenho de validar as entradas?
A resposta é em todos. Tem de validar todas as entradas das suas aplicações. Isso inclui parâmetros na URL, entrada do usuário, dados do banco de dados, dados de uma API e qualquer coisa que seja passada de forma clara que um usuário possa manipular. Use sempre uma abordagem de lista de permissões, o que significa que você só aceita entradas "boas conhecidas", em vez de uma lista de bloqueio (onde você procura especificamente entradas ruins) porque é impossível pensar em uma lista completa de entradas potencialmente perigosas. Faça esse trabalho no servidor, não no lado do cliente (ou além do lado do cliente), para garantir que suas defesas não possam ser contornadas. Trate TODOS os dados como não confiáveis e você se protegerá da maioria das vulnerabilidades comuns de aplicativos Web.
Se você estiver usando ASP.NET, a estrutura oferece um ótimo suporte para validar a entrada no lado do cliente e do servidor.
Se você estiver usando outra estrutura da Web, há algumas ótimas técnicas para fazer a validação de entrada disponíveis na folha de dados de validação de entrada OWASP.
Utilize sempre consultas parametrizadas
Os bancos de dados SQL são comumente usados para armazenar dados; Por exemplo, seu aplicativo pode armazenar informações de perfil de usuário em um banco de dados. Você nunca deve criar SQL embutido ou outras consultas de banco de dados em seu código usando a entrada bruta do usuário e enviá-la diretamente para o banco de dados; Este comportamento é uma receita para o desastre, como vimos anteriormente.
Por exemplo, não crie código como o seguinte exemplo de SQL embutido:
string userName = Request.QueryString["username"]; // receive input from the user BEWARE!
...
string query = "SELECT * FROM [dbo].[users] WHERE userName = '" + userName + "'";
Aqui, concatenamos cadeias de texto para criar a consulta, ao utilizar a entrada do utilizador e gerar uma consulta SQL dinâmica para procurar o utilizador. Mais uma vez, se um utilizador malicioso percebesse que estamos a fazer isto ou simplesmente experimentasse estilos de entradas diferentes para ver se existia uma vulnerabilidade, poderíamos acabar com um desastre de proporções enormes. Em vez disso, utilize instruções SQL parametrizadas ou procedimentos armazenados como este:
-- Lookup a user
CREATE PROCEDURE sp_findUser
(
@UserName varchar(50)
)
SELECT * FROM [dbo].[users] WHERE userName = @UserName
Com esse método, você pode invocar o procedimento do seu código com segurança, passando-lhe a userName cadeia de caracteres sem se preocupar com o fato de ele ser tratado como parte da instrução SQL.
Codificar sempre as saídas
Qualquer saída que apresente visualmente ou num documento deve ser sempre codificada e escapada. Isso pode protegê-lo no caso de algo ter sido perdido no passe de higienização ou o código acidentalmente gerar algo que pode ser usado maliciosamente. Este princípio de conceção irá garantir que tudo é apresentado como saída e que não é inadvertidamente interpretado como algo que deveria ser executado, o que é outra técnica de ataque comum referida como "Scripting Entre Sites" (XSS).
Dado que a prevenção de XSS é um requisito de aplicação comum, esta técnica de segurança é outro aspeto de que o ASP.NET irá tratar por si. Por predefinição, todas as saídas já estão codificadas. Se você estiver usando outra estrutura da Web, poderá verificar suas opções de codificação de saída em sites com o OWASP XSS Prevention Cheatsheet.
Resumo
Limpar e validar as suas entradas é um requisito necessário para garantir que são válidas e podem ser utilizadas e armazenadas em segurança. A maioria das estruturas Web modernas oferece funcionalidades incorporadas que podem automatizar parte deste trabalho. Pode consultar a documentação da sua estrutura preferida e ver quais as funcionalidades que esta oferece. Embora as aplicações Web sejam o local mais comum onde isto acontece, tenha em atenção que os outros tipos de aplicação podem ser igualmente vulneráveis. Não pense que está seguro apenas porque a sua nova aplicação é uma aplicação de ambiente de trabalho. Você ainda precisará lidar corretamente com a entrada do usuário para garantir que alguém não use seu aplicativo para corromper seus dados ou prejudicar a reputação da sua empresa.