Tempo de leitura: 11 minutos
1 – Injeção
Ainda hoje o maior foco de ataques são os servidores com aplicações vulneráveis a injeção, mesmo sendo uma vertente de ataque tão antiga e utilizado em grande escala. Proteger de ataques de injeção pode ser simples, mas ainda sim os desenvolvedores costumam pecar nesse quesito trazendo um grande risco a sua aplicação.
Exemplos de cenários de ataque
Cenário #1: A aplicação utiliza dados não confiáveis na construção da seguinte chamada SQL vulnerável: String query = “SELECT * FROM accounts WHERE custID='” + request.getParameter(“id”) + “‘”;
Cenário #2: De forma similar, uma aplicação confiar cegamente nos frameworks pode resultar em consultas que continuam vulneráveis, (ex., linguagem de consulta Hibernate (HQL)): Query HQLQuery = session.createQuery(“FROM accounts WHERE custID=’“ + request.getParameter(“id”) + “‘”); Em ambos os casos, o atacante modifica o valor do parâmetro ‘id’ em seu navegador para enviar: ‘ or ‘1’=’1. Por exemplo: http://example.com/app/accountView?id=’ or ‘1’=’1 Isso muda o significado de ambas as consultas para retornar todos os registros da tabela de contas. Ataques mais perigosos poderiam modificar dados ou até mesmo chamar procedimentos armazenados.
2 – Quebra de autenticação e gerenciamento de sessão
Outra vertente de ataque muito comum e o ataque direcionado a sessões, vários desenvolvedores não tem dado a devida atenção para essa vertente que tem um alto impacto no negócio.
Exemplos de cenários de ataque
Cenário # 1: Uma aplicação de reservas de passagens aéreas suporta reescrita de URL, colocando IDs de sessão na URL: http://example.com/sale/saleitems;jsessionid=2P0OC2JSNDLPSK HCJUN2JV?dest=Hawaii Um usuário autenticado do site quer deixar seus amigos saberem sobre a venda. Ele envia um e-mail do link acima sem saber que com isso também está enviando a sua ID da sessão. Quando seus amigos utilizarem o link, irão usar sua sessão e cartão de crédito.
Cenário # 2: O tempo de expiração da aplicação não está definido corretamente. O usuário utiliza um computador público para acessar o site. Em vez de selecionar “logout” o usuário simplesmente fecha a aba do navegador e vai embora. O atacante usa o mesmo navegador uma hora mais tarde, e esse navegador ainda está autenticado.
Cenário # 3: Atacante interno ou externo ganha acesso ao banco de dados de senhas do sistema. Senhas de usuários não estão utilizando hash, expondo assim todas as senhas dos usuários ao atacante.
3 – Cross-Site Scripting (XSS)
XSS e uma vertente bastante utilizada quando você adentra no mundo hacking, já que o XSS básico e de fácil utilização. Porém muitas pessoas não tem a real noção do impacto dessa falha, utilizando ‘xss persistent’ você consegue afetar todos usuários de uma aplicação com o código malicioso injetado.
Exemplo de cenário de ataque
A aplicação utiliza dados não-confiáveis na construção do seguinte fragmento HTML sem validação ou filtro: (String) page += “”; O atacante modifica o parâmetro ‘CC’ em seu navegador para: ‘>// ‘. Isso causa o envio do ID de sessão da vítima para o site do atacante, permitindo que o atacante sequestre a sessão atual do usuário. Note que o atacante também pode usar o XSS para anular qualquer defesa automática de CSRF que a aplicação possa empregar.
4 – Referência insegura e direta a objetos
E muito comum encontrar sistemas sem as devidas verificações de segurança nos métodos, sem essas verificações qualquer um com uma pequena noção da aplicação consegue enviar parâmetros e realizar ações que não deveria ter permissão e as vezes até simular solicitações de outro usuário.
Exemplo de cenário de ataque
A aplicação utiliza dados não verificados em uma chamada SQL que está acessando as informações de conta: String query = “SELECT * FROM accts WHERE account = ?”; PreparedStatement pstmt = connection.prepareStatement(query , … ); pstmt.setString( 1, request.getParameter(“acct”)); ResultSet results = pstmt.executeQuery( ); O atacante simplesmente modifica o parâmetro ‘acct’ em seu navegador para enviar qualquer número de conta. Se não verificado adequadamente, o atacante pode acessar qualquer conta de usuário, em vez de somente a conta do cliente pretendido. http://example.com/app/accountInfo?acct=notmyacct
5 – Configuração incorreta de segurança
No meu ponto de vista a vulnerabilidade que mais impacta no negócio, levando em consideração que dependendo da configuração incorreta o atacante consegue acesso total a toda infraestrutura da aplicação.
Exemplos de cenários de ataque
Cenário #1: O console de administração do servidor de aplicação é instalado automaticamente e não é removido. Contas padrão não são alteradas. Atacantes descobrem as páginas padrão de administração que estão em seu servidor, fazem login com senhas padrão e assumem o acesso do ambiente.
Cenário #2: A listagem de diretórios não está desativada em seu servidor. O atacante descobre que pode simplesmente listar os diretórios para encontrar qualquer arquivo. Atacante encontra e transfere todas as suas classes Java compiladas, e pode decompilar e fazer engenharia reversa para obter todo o seu código customizado. Assim, ele encontra uma falha grave de acesso de controle em sua aplicação.
Cenário #3: Configuração do servidor de aplicação permite que os rastreamentos de pilha sejam devolvidos aos usuários, potencialmente expondo falhas potenciais. Atacantes adoram as mensagens de erro que fornecem informações extras.
Cenário #4: Servidor de aplicação vem com exemplos que não são removidos do seu servidor de produção. Aplicações de exemplo têm falhas de segurança conhecidas que os atacantes podem usar para comprometer o seu servidor.
6 – Exposição de dados sensíveis
E uma falha de alto impacto para o negócio, caso aconteça a exposição de dados sensíveis a reputação do seu negócio está gravemente comprometida.
Exemplos de cenários de ataque
Cenário #1: Uma aplicação criptografa números de cartão de crédito em um banco de dados usando a criptografia automática do banco de dados. No entanto, isso significa que também descriptografa esses dados automaticamente quando recuperados, permitindo uma falha de injeção SQL para recuperar os números de cartão de crédito em texto claro. O sistema deveria ter criptografado os números de cartão de crédito através de uma chave pública, e só permitir a descriptografia por aplicações de back-end com a chave privada.
Cenário #2: Um site simplesmente não usa SSL em todas as páginas autenticadas. O atacante simplesmente monitora o tráfego de rede (como uma rede wireless aberta), e rouba o cookie de sessão do usuário. O atacante então reproduz este cookie e sequestra a sessão do usuário, acessando dados privados do mesmo.
Cenário #3: O banco de dados de senhas dos usuários usa hashes simples (unsalted) para armazenar as senhas de todos. Uma falha de upload de arquivos permite que um atacante recupere o arquivo de senhas. Todos os hashes simples poderão ser expostos através de uma rainbow table de hashes pré-calculados.
7 – Falta de função para controle do nível de acesso
Um erro muito comum de desenvolvedores e focar na página principal da sua área administrativa a validação do login, em vários sistemas que analisei existiam várias páginas de áreas administrativas que se acessadas isoladamente não exigiam autenticação.
Exemplos de cenários de ataque
Cenário #1: O atacante simplesmente força a navegação pelas URLs alvo. As seguintes URLs exigem autenticação. Direitos de administrador também são exigidos para acessar a página “admin_getappInfo” . http://example.com/app/getappInfo http://example.com/app/admin_getappInfo Se um usuário não autenticado pode acessar qualquer página, isso é uma falha. Se um usuário autenticado, não administrador, tem permissão para acessar a página “admin_getappInfo”, isso também é uma falha, e pode levar o atacante para mais páginas de administração inadequadamente protegidas.
Cenário #2: Uma página fornece um parâmetro ‘action‘ para especificar a função que está sendo chamada, e diferentes ações exigem papéis diferentes. Se esses papéis não são aplicados, isso é uma falha.
8 – Cross-Site Request Forgery (CSRF)
Muitos desenvolvedores não conhecem o real impacto do CSRF em uma aplicação, por isso e uma das falhas mais encontradas atualmente.
Exemplo de cenário de ataque
A aplicação permite que um usuário submeta uma requisição de mudança de estado que não inclui qualquer segredo. Por exemplo: http://exemplo.com/app/transferirFundos?quantia=1500 &contaDestino=4673243243 Com isso, o atacante constrói uma requisição que irá transferir dinheiro da conta da vítima para a conta do atacante, e então incorpora este ataque em uma requisição armazenada em uma imagem ou iframe em vários sites sob o controle do atacante:
<img src=”http://exemplo.com/app/transferirFundos?
quantia=1500&contaDestino=contaAtacante#“
width=”0″ height=”0″ />
Se a vítima visitar qualquer um dos sites do atacante enquanto estiver autenticado em exemplo.com, essas requisições forjadas irão incluir automaticamente informações de sessão do usuário, autorizando o pedido do atacante.
9 – Utilização de componentes vulneráveis conhecidos
Muito comum hoje em dia, os componentes “módulos, bibliotecas, add-ons” são um grave risco para a sua aplicação caso não sejam monitorados quanto a falhas existentes e suas atualizações estejam sempre em dia.
Exemplo de cenários de ataque
Vulnerabilidades de componentes podem causar quase qualquer tipo de risco imaginável, variando do malware trivial ao sofisticado desenvolvido para atingir uma organização específica. Componentes quase sempre executam com todos os privilégios de uma aplicação, então falhas em qualquer componente podem ser sérias. Os dois seguintes componentes vulneráveis foram baixados 22m de vezes em 2011.
• Apache CXF Authentication Bypass – Ao não fornecer um token de identidade, atacantes podem chamar qualquer serviço web com todas as permissões. (Apache CXF é um framework de serviços, não deve ser confundido com o Servidor de Aplicação Apache.)
• Spring Remote Code Execution – Abuso da implementação de Linguagem Expression no Spring permitiu aos atacantes executarem código arbitrário, efetivamente comprometendo o servidor.
Toda aplicação utilizando qualquer dessas bibliotecas vulneráveis está vulnerável a ataques já que ambos componentes são diretamente acessíveis por usuários da aplicação. Outras bibliotecas vulneráveis, usadas mais profundamente em uma aplicação, podem ser mais difíceis de explorar.
10 – Redirecionamentos e encaminhamentos inválidos
O redirecionamento e utilizado para facilitar a navegação pela sua aplicação, normalmente também não são consideradas pelos desenvolvedores um risco.
Portanto e um dos pontos aonde o atacante deve agir, levando em consideração que o desenvolvedor não espera ataques voltado a esse tipo de vertente a proteção nesses casos e quase nula.
Exemplos de cenários de ataque
Cenário #1: A aplicação possui uma página chamada “redirect.jsp” que recebe apenas um parâmetro “url”. O atacante cria uma URL maliciosa que redireciona os usuários para o site malicioso, que executa phishing e instala malware. http://www.example.com/redirect.jsp?url=evil.com
Cenário #2: A aplicação usa encaminhamentos para rotear requisições entre partes diferentes do site. Para facilitar, algumas páginas usam um parâmetro para indicar onde o usuário deve ser enviado se a transação for efetuada com sucesso. Neste caso, o atacante cria uma URL que irá passar pela verificação de controle de acesso e encaminhá-lo para uma funcionalidade administrativa que o atacante não teria autorização para acessá-la. http://www.example.com/boring.jsp?fwd=admin.jsp
Como vocês podem notar nas vulnerabilidades citadas acima, existe uma gama de possibilidades para realizar um ataque bem sucedido. Hoje não e possível dizer que você está “100% seguro”, use sua criatividade e não pare nos 10. Existem centenas de problemas que podem afetar a segurança geral de uma aplicação web.
