Esta é a sétima parte de uma série de artigos sobre os Top 10 boas práticas proativas da OWASP para desenvolvimento de aplicativos seguros. O artigo anterior pode ser conferido aqui.

Registro e detecção de invasão

O registro é uma parte simples de qualquer sistema. Mas a sua importância é muito maior do que solução de problemas e debug. Ele é fundamental também para a auditoria da atividade, detecção de invasão (dizendo aos ops quando o sistema está sendo hackeado) e laboratório criminal (descobrindo o que aconteceu depois que o sistema foi hackeado). Você tem que levar tudo isso em conta na sua estratégia de registro.

O que registrar e o que não registrar

Tenha certeza de que você está sempre fazendo o registro de quando, quem, onde e o quê: timestamps (você vai precisar cuidar da sincronização de data e hora em todos os sistemas e dispositivos ou estar preparado para explicar as diferenças de fuso horário, precisão e resolução), ID de usuário, IP de origem e outros detalhes de informações de endereços e de eventos.

Para tornar a correlação e a análise mais fáceis, adote uma abordagem de registro comum em todo o aplicativo e em todos os sistemas, sempre que possível. Use um framework de registro extensível como SLF4J com Logback ou Apache Log4j/Log4j2.

Os regulamentos de compliance como PCI DSS podem determinar quais as informações você precisa gravar, quando e como, quem tem acesso aos logs, e quanto tempo você precisa manter essa informação. Pode ser que você também precise provar que os logs de auditoria e outros logs de segurança estão completos e não foram adulterados (usando um HMAC, por exemplo), e garantir que esses registros sejam sempre arquivados. Por essas razões, é melhor separar os logs de operação e de debug dos logs de auditoria de transações e registros de eventos de segurança.

Existem dados nos quais você precisa fazer login (histórico sequencial completo de eventos específicos para atender a compliance ou exigências legais). Dados em que você não deve fazer login (dados PII ou de cartão de crédito, ou dados de saída ou não-rastreáveis em comunicações interceptadas), e outros dados em que você não deve fazer login (informações de autenticação e outros dados pessoais).

E cuidado com ataques Log Forjados, em que são injetados delimitadores como sequências extras CRLF para campos de texto que eles sabem que estarão logados para tentar cobrir seus rastros, ou injetar JavaScript em dados que vão desencadear um ataque XSS, quando a entrada de log é exibida em um visualizador de log baseado em browser. Como em outros ataques de injeção, proteja o sistema por meio da codificação de dados do usuário antes de escrevê-lo para o log.

Revise o código para práticas corretas de exploração de registro e teste o código de registro para se certificar de que ele funciona. O Logging Cheat Sheet do OWASP oferece mais orientações sobre como fazer a exploração certa de logging e com o que tomar cuidado.

AppSensor – Detecção de invasão

Outro projeto OWASP, o OWASP AppSensor, explica como construir o registro de aplicativo para implementar detecção de intrusão em nível de aplicativo. Ele descreve pontos de detecção comuns em um aplicativo, lugares onde você deve adicionar verificações para alertá-lo de que o sistema está sendo atacado. Por exemplo, se uma edição do lado do servidor captura dados ruins que já deveriam ter sido editados no cliente, ou captura uma mudança para um campo não editável, aí você tem um bug ou (mais provável) alguém ignorou a validação do lado do cliente e está atacando o seu aplicativo. Não basta registrar o caso e retornar um erro: lance um alerta ou tome algum tipo de ação para proteger o sistema de ser atacado, como desconectar a sessão.

Você também pode verificar a existência de assinaturas de ataques conhecidos: Nick Galbreath (anteriormente no Etsy e agora na startup  Signal Sciences) fez um trabalho inovador na detecção de injeção SQL e ataques de injeção HTML através da mineração de logs para encontrar impressões digitaiscomuns e retroalimentando filtros para detectar quando os ataques estão em andamento e, potencialmente, bloqueá-los.

Nos próximos três artigos, vamos dar um passo atrás em problemas específicos e dar uma olhada em questões maiores da arquitetura segura, design e requisitos.

***

Artigo traduzido pela Redação iMasters com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2014/06/10-things-you-can-do-as-developer-to_30.html