Desenvolvimento

8 ago, 2014

10 boas práticas para tornar seus aplicativos mais seguros – Parte 02

Publicidade

Chegamos à segunda parte da série de artigos sobre as Top 10 práticas proativas da OWASP, contendo as 10 melhores atitudes que você pode tomar como desenvolvedor para tornar o seu aplicativo mais seguro. No artigo anterior, expliquei o motivo pelo qual as consultas de banco de dados parametrizadas são tão importantes no que tange à proteção de aplicativos contra os ataques de injeção SQL, um dos mais comuns e perigosos.

Ataques de injeção SQL são apenas um dos vários tipos de ataques de injeção de código malicioso. Acabar com esses ataques é fácil, através da parametrização de consultas. Os outros tipos de ataques de injeção de código, como injeção de LDAP, injeção de XML, injeção XPath, injeção de comandos do sistema operacional e, especialmente, injeção de Javascript (ataque que também é conhecido como ataque XSS ou Cross Site Scripting), darão muito mais trabalho. A injeção NoSQLSSJS (Server-Side Javascript) – e a injeção de esquema contra bancos de dados NoSQL são algo que ainda estamos aprendendo como fazer.

Como evitar ataques de injeção

A solução para os ataques de injeção são, na verdade, muito simples: caso não seja possível separar claramente o código dos dados (feito para evitar a injeção de SQL usando uma API parametrizada), será absolutamente necessário tornar os dados seguros antes de entregá-los a um intérprete externo (como um parser XML, um Shell de comandos de sistema operacional ou um navegador que execute os dados).

Você pode – e deve – fazer isso trabalhando os dados logo na entrada: rejeitando quaisquer dados que não sejam considerados seguros. Mas há limites para quantos problemas é possível tratar logo na entrada da validação, especialmente se for necessário aceitar e permitir que o texto enviado seja de formato livre (campos textarea, por exemplo).

Assim, para ser seguro, é necessário codificar a saída ou o resgate dos dados antes que estes sejam entregues para o intérprete, de modo que este último não reconhecerá quaisquer declarações executáveis (ou maliciosas) nos dados.

O importante são os detalhes: é preciso entender o funcionamento da codificação e as regras de escapar strings de cada intérprete ou parser e aplicar essas regras de codificação corretamente nos contextos específicos (também certifique-se de não codificar os dados mais de uma vez). Os navegadores tornam isso especialmente difícil, forçando o desenvolvedor a determinar como e quando deve codificar os dados corretamente, seja em HTML, Javascript, XML ou CSS. E isso não é suficiente apenas para dados no formato HtmlEncode:

“Entidades HTML até podem ser boas para dados não confiáveis que sejam enviados no corpo de um documento HTML, como dentro de uma tag <div>, mas esses mesmos tipos de dados não são confiáveis quando utilizados em atributos, especialmente se você for um desenvolvedor metódico acerca do uso de aspas para escapar seus atributos (o que é acertadamente correto). Mas utilizar HTML na codificação de entidade não funciona caso esteja enviando dados não confiáveis dentro de uma tag <script> situada em qualquer lugar do código, ou então um manipulador de eventos de atributos como onmouseover dentro de um arquivo CSS ou em uma URL externa. Assim, mesmo que seja utilizado um método de codificação de entidades HTML em todos os lugares do seu código, ele continuará sendo vulnerável a ataques XSS. Você deve usar a sintaxe de escape para a parte do documento HTML que está sendo colocado em dados não confiáveis. Consulte o documento de prevenção de ataques XSS da OWASP para mais detalhes.

Existem ferramentas para ajudá-lo a fazer isso: o codificador OWASP ESAPI (utilizado para escapar conteúdo CSS, entidades HMTL, URLs e JavaScript, assim como sintaxes Unix, codificação do Windows, VBScript, codificação LDAP, XML, XmlAttribute e XPath), o OWASP Java Encoder para proteção contra ataques XSS, e Anti-XSS Library de código aberto da Microsoft para .NET (algumas funções do codificador voltadas para a proteção contra ataques XSS foram criadas a partir dessa biblioteca, melhoradas e acrescentadas na versão 4.5 do .NET AntiXssEncoder).

Ainda assim, mesmo com essas ferramentas, pode ser difícil conseguir manter tudo seguro, e é por isso que ataques por injeção de código, especialmente XSS, são uma das principais vulnerabilidades de segurança em aplicativos web (para saber mais sobre como funciona o ataque XSS e como identificá-lo em um aplicativo, jogue o jogo interativo de XSS do Google).

CSP – uma abordagem diferente para parar XSS

Uma abordagem completamente diferente – e mais simples – para proteger seu aplicativo web contra ataques XSS, especialmente se você está construindo um aplicativo web a partir do zero, é estabelecer uma robusta política de segurança de conteúdo, contendo regras para restringir fontes válidas para os scripts e outros recursos (conexões, imagens, meios de comunicação, quadros etc.), e para bloquear script inline (será necessário estruturar o seu código JavaScript em conformidade com essa política).

Content-Security-Policy: script-src ‘self’

Esse cabeçalho HTTP é tudo o que você precisa. Claro que existem ressalvas: existem alguns casos extremos que não podem ser manipulados devido a restrições no conteúdo das políticas de segurança, então o cabeçalho Content-Security-Policy só é implementado nos navegadores mais recentes (embora seja compatível), e dessa forma existirá uma dependência de uso dos navegadores compatíveis para implementar as regras corretamente, ou então seu aplicativo que ainda estará vulnerável a bugs exclusivos do navegador.

Assista a um vídeo de Jim Manico, um verdadeiro especialista em segurança de aplicativos, explicando as top 10 práticas proativas.

No próximo artigo, vou abordar a validação de entrada de dados. Simples. Óbvia. E, muitas vezes, feita da forma errada.

***

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-to-make-your-app_9.html