No último post eu prometi explicar cada item das camadas Java. Hoje irei abordar todos os itens da camada de apresentação Java.
Itens de atenção na camada de apresentação:
- Proteger a aplicação web contra cross site scripting;
- Evitar ataques de CSRF;
- Validar a origem das requisições;
- Controle de acesso;
- Criar nova sessão após a autenticação do usuário;
- Garantir a segurança dos identificadores de sessão (cookies);
- Evitar nomes de arquivos como parâmetros;
- Não utilizar "open redirect";
- Usar corretamente POST e GET;
- Segregar a interface de administração;
Cross site scripting (XSS)
XSS é um problema real e muitas aplicações estão vulneráveis. Um XSS consegue acessar cookies, requisições HTTP e outras informações confidenciais dos usuários. Caso o atacante consiga executar códigos JavaScript em seu website, a segurança do site e dos seus usuários pode ser comprometida. Existem 3 tipos de XSS:
Refletido, Persistido e DOM Based.
- Reflected XSS: Ocorre quando o servidor reflete o que enviamos sem filtrar o que o usuário digitou. No ato de enviar um determinado parâmetro, o servidor repete no código-fonte da página sem tratar o que foi inserido.
- Persistent XSS: Ocorre quando o código malicioso a ser injetado não foi filtrado e está armazenado na página ou em algum componente da aplicação.
- Dom Based XSS: Depende das vulnerabilidades em algum dos componentes da página, o script é quem faz as alterações no HTML atual da página através da manipulação do DOM (Document Object Model). Este é o tipo mais difícil de ser encontrado.
Na essência um xss simples é:
<script>alert('XSS');</script>
Existem alguns tipos de tratamento, como:
- Encoding e Validation;
- Bibliotecas Anti-XSS;
- Content Security Policy (CSP);
- X-XSS-Protection no Header;
- Flag HttpOnly.
- Encoding e Validation
Encoding é filtrar os dados que o usuário irá inserir para que o navegador o interprete apenas como dado e não como código. Validation é filtrar todas as entradas do usuário que podem ser maliciosas para a sua aplicação, e essa será a sua primeira linha de defesa conta os ataques XSS.
- Use bibliotecas Anti-XSS
O AntiSamy, biblioteca da OWASP para HTML e CSS. Utilizada para sanitizar a entradas dos usuários. Customizável, o AntiSamy permite definir níveis de purificação diferentes através de regras em um XML.E exibir mensagens de erros amigáveis para os usuários.
- Content Security Policy (CSP)
O Content Security Policy é um cabeçalho HTTP que fornece uma whitelist de recursos confiáveis no qual o navegador poderá confiar. Um recurso pode ser um script, CSS, imagem ou outro tipo de arquivo que poderá ser indicado. Isso significa que mesmo se um atacante conseguir injetar um código XSS no seu site, o CSP poderá impedir a sua execução.
- X-XSS-Protection no Header
Este cabeçalho pode ser utilizado para configurar uma proteção no navegador contra ataques XSS Reflected.
- Flag HttpOnly
O HttpOnly é uma flag adicional que pode ser incluída junto com a opção Set-Cookie. Quando o HttpOnly é usado, o JavaScript não será capaz de ler esse cookie protegido se acontecer a exploração do XSS do lado do cliente.
CSRF
CSRF é um um ataque, popular e perigoso, mas com devidas proteções é certamente gerenciável. CSRF explora formas para executar a funções que o site carrega que é então transmitido automaticamente com cada requisição para a página. Ao explorar esta transmissão automática, um atacante pode causar a vítima a realizar quase qualquer pedido não está protegido contra CSRF.
Existem alguns tipos de tratamento, os mais conhecidos são:
- Token ESAPI;
- CSRFGuard.
- Token ESAPI
Conhecido como o padrão de design de token sincronizador. Neste padrão quando o usuário faz login, uma String randomizados (token) é colocada na sessão de usuário. Em cada formulário para pedido do site para o servidor, o token é colocado no formulário quando ele é submetido. O servidor valida se o token apresentado corresponde ao token armazenado na sessão. Se qualquer um dos tokens estiver faltando, ou se eles não corresponderem, o servidor não processa a transação.
- CSRFGuard
O projeto OWASP CSRFGuard é uma biblioteca que torna relativamente fácil de construir uma proteção CSRF em sua aplicação, simplesmente mapeando um filtro e atualizar um arquivo de configuração. Seguindo o modelo de Token acima, o CSRFGuard deixa a critério do usuário como o tratamento será realizado. Por meio de JavaScript DOM ou biblioteca de tags JSP. O método de JavaScript DOM,i é injetado dinamicamente fichas de prevenção CSRF em todo o DOM carregado no navegador do usuário. Há pouco ou nenhum impacto no desempenho quando o buscado JavaScript dinâmico atualiza DOM do navegador.
A biblioteca de tags JSP fornece aos desenvolvedores controle sobre a injeção de token. A biblioteca expõe tags JSP que permitem o acesso ao nome do token, o valor do token, e assinar o par de valor de nome do token delimitado por um igual (=). A fim de fazer uso da biblioteca de tags, é necessário garantir que o arquivo Owasp.CsrfGuard.jar esteja dentro do diretório WEB-INF/ WebContent / lib. Depois de colocar a biblioteca no classpath e referenciar as tags em páginas JSP usando referência URI predefinido.
Validar a origem das requisições
Uma técnica conhecida no mundo de segurança é o sequestro de sessão. É de especial importância verificar se todas as requisições de uma mesma sessão são originárias do mesmo cliente. Para isso, existem 2 pontos de verificação:
- verificar o endereço de origem da requisição (IP e portas);
- verificar a identidade do usuário responsável pela requisição.
A verificação dos endereços de origem das requisições pode ser realizada através das APIs Java java.net.Socket.getInetAddress() e java.net.Socket.getPort().
No caso de aplicações web, o Application Server deve prover os métodos de autenticação necessários para proteger a autenticação dos usuários remotos.
Controle de acesso
Quando utilizamos aplicações web, algumas precauções são necessárias, para manter os mecanismos de controle de acesso, autenticação e autorização, tais como:
“Tripple A” Autenticação “Quem é” Autorização ”Pode fazer” Auditoria “O que fez”.
Autenticação baseada em:
O que o usuário sabe (senha, PIN);
O que o usuário possui (crachá, smart card, token);
O que o usuário é (impressão digital, voz, retina);
Onde o usuário está (antes ou depois do firewall).
Autorização baseada em:
Permissões de Leitura, Escrita e Execução.
Auditoria baseada em:
Registrar operações e atividades realizadas em Logs;
Associar a ação a um usuário;
Assinatura Digital;
Para isso, a aplicação deve ser projetada de maneira a que não seja possível acessar o conteúdo da aplicação sem passar pelas páginas de controle de acesso mesmo que a URL das páginas internas seja conhecida.
O controle de permissões dos arquivos geralmente é feito por servidores web. Eles usam os mecanismos de controle de acesso do sistema operacional, focados em controlar as permissões de cada usuário com relação às páginas e demais arquivos que fazem parte da aplicação. A maior parte dos diretórios não deve ter permissão de leitura e apenas alguns arquivos devem ser setados como executáveis.
Os usuários acessam com frequencia aplicações web de computadores compartilhados. Os browsers normalmente armazenam localmente (cache) cópias das páginas acessadas. Como estas cópias poderiam ser lidas por pessoas não autorizadas, a aplicação web deve usar os mecanismos disponíveis, como headers HTTP e tags META para tentar evitar que as páginas fiquem disponíveis localmente.
API Java que poderá ajudar no tratamento dos itens acima:
- Java authentication and authorization service (JAAS).
Depois que o usuário se autentica na aplicação, caso a aplicação não crie uma nova sessão com um novo identificador, facilita absurdamente os ataques de session fixation. Neste ponto, é importante tratar via código java o controle de sessão e a criação de uma sessão nova após a autenticação do usuário.
Garantir a segurança dos identificadores de sessão (cookies)
Cookie é uma pequena quantidade de informação persistida temporariamente pelo navegador. Através de cookies o servidor Web é capaz de trocar informações de estado com o navegador do usuário considerando que o protocolo HTTP não mantém um estado/conexão, cookie se faz necessário. Se excluirmos os cookies, ou o tempo de expiração for atingido, o navegador deixa de anexar as informações no cabeçalho da requisição.
CheckSSLSessionId: indica que o servidor deve validar o identificador de sessão gerado pelo Tomcat contra o identificador da sessão SSL. Isto garante que, mesmo que o cookie com o identificador de sessão seja copiado, a sessão não poderá ser usada, já que a sessão SSL não será a mesma.
SecureCookie: indica que o cookie de identificação de sessão deverá ser marcado como secure e que o browser do usuários somente deverá transmití-lo em conexões SSL, garantindo a sua confidencialidade.
HTTPOnly: são cookies que podem ser setados pelo servidor ou por javascript porém nãopodem ser acessados de nenhuma forma por javascript. Para que seja efetiva a funcionalidade do HTTPOnly o navegador deve estar habilitado para isto.
Evitar nomes de arquivos como parâmetros
Imagine que o servidor possua um arquivo chamado: backup ou passwdsDB, triste seria não? Qualquer hacker que http://meusite.com/download?file=/etc/backup ou http://meusite.com/download?file=/etc/passwdsDB acessaria diretamente o arquivo.
Nestes casos, o ideal é montar uma tabela com os nomes dos arquivos que pode ser acessado através da aplicação e atribuir a cada arquivo um identificador único. configurar o usuário que o servidor de aplicação irá executar e suas as permissões no sistema de arquivos do servidor.
Não utilizar "open redirect"
Aqui, senhoras e senhores um dos maiores vetores para phishing!
Você já deve ter topado alguma vez na vida com um código tipo este:
Response.Redirect(returnUrl);
Onde a aplicação entende que vai capturar o parâmetro returnUrl que deve redirecioná-lo em seguida. Ótimo não? NÃO!
Imagina que na página
http://meusite.com/CestaCompras.aspx?name=value1&returnUrl=http://baixar.com/instalabaidu.exe
Amigo, uma vez com o baidu instalado…. Adeus Adeus!
Da mesma forma que eu fiz um exemplo como executar algo pode ser um outro site, pode ser um formulário pedindo preenchimento de dados do usuário, pode ser uma página fake de banco e etc…
Portanto, é adequado validar e filtrar as URLs a serem utilizadas em redirecionamentos. Esta validação poderia ser feita pela implementação dos seguintes passos:
- Verificar que o protocolo é válido: http://, https:// ou ftp://
- Verificar o domínio alvo do redirecionamento: O alvo deve ser o próprio domínio da aplicação. Caso o cenário seja bem maior é necessário setar a lista de domínios válidos.
Usar corretamente POST e GET
No protocolo HTTP existem vários métodos, 2 em particular são os mais utilizados POST e GET.
- POST
Submete dados a serem processados de forma encapsulada. É considerado um dos métodos mais seguros, pois não expõe os dados enviados no navegador.
- GET
Método é utilizado quando se quer passar poucas ou pequenas informações para realizar uma pesquisa ou simplesmente passar uma informação para outra página através da URL. Neste método os dados são visíveis na barra de endereço
Cuidados com os métodos: Não realizar autenticação do usuário por método GET contanto que queira realmente ver:
http://www.meusite.com/cadastro.php?nome=joao&senha=12345&endereco=rua1
Segregar a interface de administração
Quem nunca acessou uma URL colocando a porta do servidor e a aplicação redirecionou para a página default do servidor?
http://www.meusite.com:8080
Este é um problema típico de falta de segregação de ambientes. Porta default, página default, usuário e senha default, todos estes itens não podem fazer parte de uma aplicação se você deseja que o seu site seja seguro. Portanto é importante:
Segregar as interfaces: Construir a interface de administração e publicar como se fosse uma aplicação à parte, de forma que seja possível definir usuários e permissões específicos, realizar o controle de acesso na infra-estrutura (firewalls, publicação apenas em rede privada, etc).
Usar certificados de cliente para autenticação: Com o intuito de permitir uma autenticação mais robusta e evitar ataques de força bruta.
Gostaram? Então fiquem ligados nas próximas postagens!
Até a próxima \o.
Muito bom o Texto. Fico no aguardo da próxima. Continue assim.
ResponderExcluir