Roteiro para a melhoria da segurança dos sistemas
Para facilitar a vida dos desenvolvedores, abaixo seguem 2 regras para trabalhar melhor o aspecto de segurança da aplicação, seguindo como um roteiro para melhorar a segurança dos sistemas. Obviamente cada desenvolvedor deve verificar quais das regras se adéquam melhor as necessidades da aplicação. Na grande maioria dos casos o simples fato de aplicar 1 das regras já surte o efeito necessário como contenção de riscos na aplicação.
Nunca inserir dados não confiáveis exceto em locais permitidos.
Esta primeira regra é para negar tudo. Não insira dados inseguros em um documento HTML a não ser que seja em uma localização diferente das listadas abaixo. A razão disto é que existem muitos contextos estranhos em HTML que podem tornar o filtro por caracteres de escape muito complicado e as vezes ineficiente. Pensando friamente não existe nenhuma boa razão para colocar dados não confiáveis nestes contextos.
Diretamente em um Script:
Dentro de um comentário HTML:
Em um nome de Atributo:
Em uma tag name:
E o mais importante: Nunca aceite códigos JavaScript a partir de uma origem não confiável e depois execute. Por exemplo, um parâmetro chamado “callback” que contem um JavaScript Code Snippet. Nem uma centena de escaping rules conseguiria consertar uma vulnerabilidade destas.
Faça HTML Escape antes de inserir dados não confiáveis em um elemento HTML
Esta regra é para aqueles que desejam colocar dados não confiáveis diretamente em algum lugar do corpo do formulário HTML. Isto inclui tags normais como div, p, b, td, etc. A maioria dos framworks web tem um método para HTML encoding que escapam os caracteres abaixo. Entretanto, isto é absolutamente não eficiente para outros contextos HTML.
...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...
Faça escape dos seguintes caracteres com HTML entity encoding para previnir problemas em contextos de execução, como por exemplo um script, style ou entção event handlers. Usar codificação hexadecimal é recomendada. Alem disto existem 5 caracteres significantes em XML (&, <, >,”,’) que podem ajudar em um contexto HTML.
& --> &
< --> <
> --> >
" --> "
' --> ' ' não e recomendado
/ --> / a barra de data é recomendada em contextos html.
Resumindo, quando pensamos em XSS attacks, temos que levar em conta que o Client Side é tão crítico quando o Server side, ou seja, temos que cuidar sempre do aspecto do cliente que acessa a aplicação evitando problemas futuros com roubos de informações.
(continua na próxima edição...)
Ivo Machado
Diretor de Operações da In2Sec (Itelligence to Security), é formado em Análise de Sistemas com MBA em Gestão de Riscos, atuou em diversas empresas nacionais e multinacionais, no Brasil e exterior. Especialista em Gestão de Riscos e Segurança da Informação, é responsável pelas operações das Américas da Certificadora TrustSign e das Consultorias de Segurança e-Horus e A.
