Desenvolvimento

Ξ Deixe um comentário

Um assunto pouco debatido: Segurança da informação web

publicado por Marcelo Dias Oliveira

Um assunto pouco debatido: Segurança da informação webOlá prezados Guerreiros de TI Hoje tenho como objetivo “dedilhar” um tema bem comum mas que está “jogado de canto”.

Sabe aquela ferramenta que você tem, mas a usa poucas vezes e por isso você não lembra que tem? Pois é, o mesmo acontece com Segurança da Informação, principalmente durante o desenvolvimento de sistemas web.

Não vejo e não ouço nos times de desenvolvimento debates acalorados em relação a Segurança da Informação. Diferentemente das discussões em relação qual linguagem usar, qual banco implementar, qual framework definir.

Normalmente percebo que esse assunto Segurança é “De largado”, isso mesmo “DE LARGADO” para outra equipe em especial o “Pessoal de Infra”, como corriqueiramente escuto.

  • “Isso é com o pessoal de servidores”.
  • “Ah! Já definiram isso lá com o pessoal dos servidores, eu acho”.
  • Até escutei dizer:“não sei e tenho raiva de quem sabe”.

Mas será que é isso mesmo? Os desenvolvedores não precisam se preocupar com Segurança?
Será que este raciocínio é coerente?
“A se minha aplicação está no servidor X, os donos dos Servidores que devem garantir o controle de acesso”.
Pois bem estudemos essa afirmação.

Quando falamos em segurança estamos falando do que mesmo? Estamos falando de proteção. Por isso, devo ter em mente um fato: quando o assunto é segurança estou falando de duas frentes de defesas: Operacional e Técnica.

Por isso devo entender!

Segurança operacional está relacionado com a forma que o usuário estará utilizando a ferramenta e suas informações. Desse modo, é responsabilidade da equipe de Desenvolvimento analisar:

  • É necessário guarda essa informação?
  • Se é necessário, para que o usuário precisa de tal informação?
  • Como o usuário irá usar essa informação?
  • Por quanto tempo devo guarda tal informação?
  • Meu backup deve ser diário, semanal, mensal, sobreposto?

Segurança técnica é uma frente que envolve a análise do projeto que deve estar engajada com o processo de desenvolvimento. Assim, as respostas das perguntas anteriores culminam nas próximas:

  • Como e quando devemos criptografar os dados ou parâmetros enviados?
  • Um algoritmo de análise de senhas faz sentido?
  • Devo criar um método de sanitização?
  • Como minha arquitetura trabalhara com as sessões e cookies?

Portanto, durante minha fase de análise e desenvolvimento, para uma maior explanação do assunto, procurarei responder as perguntas considerando pontos como:

Cross site script: Quais parâmetros devem ser passados? E quando devem ser passados? Para isso, será essencial que antes do desenvolvimento do sistema o Banco de dados esteja pronto com todos seus Objetos relacionados e testados. O modelo de entidade relacional será o suporte de entendimento das transações.

Tratamento de dados: Parâmetros enviados via GET podem ser tratados usando expressões regulares para ter certeza do tipo de dado recebido. Em muitos casos o sistema de rotas de qualquer framework web pode auxiliar nesse ponto também. Além do fato que as validações via client-side poupam o a aplicação de renderizações desnecessárias, porém a validação server-side, mostra mais eficácia.

SQL injection: Evitar transações de dados de um formulário direto para um query e fundamental. Ou seja, as variáveis enviadas chegam direto no banco de dados sem nenhum tratamento. Com uma simples validação isso pode ser evitado. Querys que vinculam os parâmetros com variáveis declaradas, preparadas e validadas são mais eficientes, procure pesquisar Binds PHP há uma vasta dica de uso.

Restrição de html htmlspecialchars. Imagine a situação: um formulário padrão com campos abertos, como de observação por exemplo, onde o usuário preenche esse campo com simples código html comum, informa um link qualquer ou até carrega um JavaScript malicioso. Essa situação seria uma porta de entrada para seu servidor. Para impedir isso existe um tratamento importante com a função htmlspecialchars, que transforma códigos html em simples códigos texto.

Gravar arquivos via upload: sempre que for gravar um arquivo via upload tenha certeza do tipo de arquivo que está gravando. Em vários casos devemos sempre avaliar com o uso da Criptografia no envio dos Parâmetros. Porém, procure criar uma validação por tipo e tamanho do arquivo que está sendo transacionado.

Confidencialidade: Propriedade que limita o acesso à informação tão somente às entidades legítimas, ou seja, àquelas autorizadas pelo proprietário da informação. Esse é um requisito muito esquecido durante a fase de especificação do projeto.

Integridade: Propriedade que garante que a informação manipulada mantenha todas consistências e características originais estabelecidas pelo proprietário da informação, incluindo controle de mudanças e garantia do seu ciclo de vida (nascimento, manutenção e destruição). Esse requisito segue os relacionamentos especificados no MER.

Disponibilidade: Propriedade que garante que a informação esteja sempre disponível para o uso legítimo, ou seja, por aqueles usuários autorizados pelo proprietário da informação. Em todas as fases da evolução corporativa, é fato que as transações de toda a cadeia de produção – passando pelos fornecedores, fabricantes, distribuidores e consumidores – sempre tiveram a informação como uma base fundamental de relacionamento e coexistência. Não adianta toda tecnologia empregada para propor uma solução segura, se os usuários não estiverem cientes de seus atos e consequências.

Esse estudo contribuirá para um entendimento técnico futuro. Entendo que são os requisitos básicos que toda aplicação deve implementar. É o mínimo necessário quando falo de segurança Web. Por exemplo, uma forma de aplicar esses pontos seria por avaliar, algumas técnicas durante o Desenvolvimento de sistemas web [com PHP].

Requisito 1: Evite uso de Register Globals
Register Globals é sem dúvida alguma a diretiva de configuração mais popular e polêmica já implementada no PHP. É popular entre os desenvolvedores por tornar o processo de programação muito mais ágil e prático. É polêmica porque retira tanto do programador quanto do interpretador da linguagem a responsabilidade em definir a origem das informações utilizadas pela aplicação. Esta diretiva causou tantos problemas que começou a vir desabilitada por default a partir da versão 4.2.0 e será eliminada na versão 6.

Requisito 2: Use require e não include
O comando include e seus derivados – como include_once – é frequentemente usado em detrimento do comando require. Este fato curioso a princípio é consequência da similaridade do comando include com outras linguagens, como C e Java. O que muita gente não sabe, porém, é que este comando carrega consigo um risco muito grande para sua aplicação: se por algum motivo a inclusão do arquivo falhar – erro de digitação, disco corrompido, etc. – será gerado um erro de nível warning, um nível leve de erro que não causa a parada da execução do script. Utilizando o comando require, garantimos que no caso de falha na carga do arquivo seja gerado, além do erro de nível warning, um erro de nível fatal. Isso significa que a execução do seu script será imediatamente interrompida neste caso.

Requisito 3: Filtre a entrada de dados
Um dos principais conceitos de segurança é a filtrar os dados que são recebidos antes de utilizá-los. A falta de filtragem é a causa inúmeros problemas de segurança, incluindo o infame SQL Injection.

Requisito 4: Sem erros para o usuário

As mensagens de erro foram feitas para que o desenvolvedor possa trabalhar de forma mais prática e descobrir o que ele está fazendo de errado. Observem, entretanto, que, quando uma aplicação atinge maturidade suficiente para “entrar em produção”, torna-se imperativo que o usuário não visualize mensagens de erro. A razão disso é muito simples: mensagens de erro frequentemente trazem informações sensíveis.

Requisito 5: Esconda do servidor web o que ele não precisa acessar
Quantos de nós não usamos em nossas aplicações um arquivo, tipicamente chamado de congif ou setup onde guardamos, por exemplo, usuário e senha da base de dados. Não há nada de errado nisso, mas cuidado: se este arquivo não gera saída de informação em HTML porque deixá-lo acessível via web? A solução é simples: movemos o arquivo para fora da raiz web. Ou use um framework de Mercado que o auxilie nisso.

Requisito 6: Use Criptografia
Dados sigilosos são chamados assim por um motivo. Quando tratamos especificamente de senhas é impressionante a quantidade de aplicações web que gravam senhas em texto puro na base de dados. Ora, se a senha possui a importância que tem e quem a escolhe é o usuário, por que alguém mais precisa ler essa senha? Se a senha possui este peso em nossa aplicação, não podemos nos dar ao luxo de fazer com que ela trafegue pela aplicação totalmente exposta.

Requisito 7: Tratamento de dados
Já pensou em sanitizar ou acionar o Garbage Collection? Por que não destruir os $_GET, $_POST e $_REQUEST após usá-los, verificá-los com tipo de dado (is_*) em funções e testes, exemplo.

if(isset($_COOKIE["PHPSESSID"])){
...}
if(is_array($_MinhaVar){
...}

Limitar o uso de addslashes (include $_GET[‘blabla’];). Tal procedimento causa uma possível sobrecarga no processamento em questão

Portanto, chego a conclusão que devo levantar outros pontos para planejar minha própria regra de segurança.
Esse artigo é uma sugestão de algumas ideias compiladas com a experiência prática.

Assim, encerro aqui esse modesto artigo para apoiar aqueles que tem seu desenvolvimento sobre pressão. E Lembre-se Guerreiros de TI, faça sempre o seu melhor, mesmo que for um simples “arroz com feijão”.

Sucesso a todos!

[Crédito da Imagem: Segurança da Informação – ShutterStock]

Autor

Formado em Sistema de Informação com Ênfase em Análise de sistemas e Processamento de Dados. Pós-graduado em Gestão estratégica de Negócios. Certificação Scrum Master. Conhecedor profundo de metodologias Ágeis como: Lean, Kanban, XP e processos para Startup. Além de possuir amplo conhecimento do PMI. Especialista em desenvolvimento Web e tendo profunda experiência com os principais Bancos de Dados do mercado.

Marcelo Dias Oliveira

Comentários

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade



Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes