UNIVERSIDADE DO ESTADO DE SANTA CATARINA CENTRO DE CIÊNCIAS TECNOLÓGICAS - CCT TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ANDRE MENDES DUARTE DEIWYS LUCIANO GRUMOVSKI GUSTAVO HEIDRICH GRUNWALD Análise da vulnerabilidade de códigos em Java pelos principais ataques definidos pela OWASP JOINVILLE, SC 2013
LISTA DE CÓDIGOS Código 3.1.1.1 Código vulnerável de cross-site request forgery 28 Código 3.1.1.2 Código de tratamento do cross-site request forgery 29 Código 3.1.1.3 Código validação de cross-site request forgery 29 Código 3.2.1.1 Código sem tratamento de command injection 30 Código 3.2.1.2 Código executando command injection 31 Código 3.2.1.3 Código com tratamento de command injection 31 Código 3.3.1.1 Exemplo de ataque Cross Site Scripting 32 Código 3.3.1.2 Exemplo de ataque Cross Site Scripting 32 Código 3.4.1.1 Exemplo de uma falha no gerenciamento da sessão. 33 Código 3.5.1.1 Trecho de uma chamada SQL que não possui verificação 35 Código 3.8.1.1 URL que da acesso direto a conteúdo protegido 39 Código 3.10.1.1 Utilização de uma página para fazer o redirecionamento do usuário 42 Código 3.10.1.2 Utilização de um parâmetro para realizar o redirecionamento do usuário. 42
LISTA DE FIGURAS Figura 2.1 Como ocorre o Buffer Overflow 17 Figura 2.2 Como ocorre o Command Injection 18 Figura 3.4.1 - Botão Sair 34 Figura 3.6.1.1 Mensagem de erro mostra que a conta não existe. 37 Figura 3.7.1.1 Resultado de uma consulta SQL 38 Figura 3.9.1.1 Testando os protocolos de segurança de um web site. 41
SUMÁRIO INTRODUÇÃO... 6 1. CONCEITOS... 7 1.1 LINGUAGEM DE PROGRAMAÇÃO JAVA... 7 1.2 HISTÓRICO DAS APLICAÇÕES EM JAVA... 8 1.3 NORMAS E TÉCNICAS DE SEGURANÇA EM JAVA... 10 1.4 CONSIDERAÇÕES PARCIAIS... 12 2. PROBLEMAS DE SEGURANÇA EM JAVA... 13 2.1 SEGURANÇA EM JAVA... 13 2.2 PRINCIPAIS PROBLEMAS DE SEGURANÇA EM JAVA... 16 2.2.1 COMMAND INJECTION... 16 2.2.2 CROSS-SITE REQUEST FORGERY (CSRF)... 17 2.2.3 CROSS SITE SCRIPTING (XSS)... 19 2.2.4 BROKEN AUTHENTICATION AND SESSION MANAGEMENT... 19 2.2.5 INSECURE DIRECT OBJECT REFERENCES... 20 2.2.6 SECURITY MISCONFIGURATION... 20 2.2.7 INSECURE CRYPTOGRAPHIC STORAGE... 22 2.2.8 FAILURE TO RESTRICT URL ACCESS... 22 2.2.9 INSUFFICIENT TRANSPORT LAYER PROTECTION... 23 2.2.10 UNVALIDATED REDIRECTS AND FORWARDS... 24 2.3 CONSIDERAÇÕES PARCIAIS... 26 3. ANÁLISE DE CODIFICAÇÃO EM JAVA... 27 3.1 ANÁLISE CROSS-SITE REQUEST FORGERY... 27 3.1.1 ANÁLISE DE CÓDIGOS... 28 3.2 ANÁLISE COMMAND INJECTION... 30 3.2.1 ANÁLISE DE CÓDIGOS... 30 3.3 ANÁLISE CROSS SITE SCRIPTING... 31 3.3.1 ANÁLISE DE CÓDIGOS... 32 3.4 ANÁLISE BROKEN AUTHENTICATION AND SESSION MANAGEMENT... 33 3.4.1 ANÁLISE DE CÓDIGOS... 33 3.5 INSECURE DIRECT OBJECT REFERENCES... 34 3.5.1 ANÁLISE DE CÓDIGOS... 35 3.6 SECURITY MISCONFIGURATION... 35 3.6.1 ANÁLISE DE CÓDIGOS... 36 3.7 INSECURE CRYPTOGRAPHIC STORAGE... 37 3.7.1 ANÁLISE DE CÓDIGOS... 38
3.8 FAILURE TO RESTRICT URL ACCESS... 39 3.8.1 ANÁLISE DE CÓDIGOS... 39 3.9 INSUFFICIENT TRANSPORT LAYER PROTECTION... 40 3.9.1 ANÁLISE DE CÓDIGOS... 40 3.10 UNVALIDATED REDIRECTS AND FORWARDS... 41 3.10.1 ANÁLISE DE CÓDIGOS... 42 3.11 CONSIDERAÇÕES PARCIAIS... 42 CONCLUSÃO... 43 REFERÊNCIAS BIBLIOGRÁFICAS... 45
INTRODUÇÃO Existe uma grande necessidade e demanda de aprimorar e tornar seguras as aplicações desenvolvidas em Java, impulsionada pelo avanço das tecnologias e pelo aumento do número de usuários em um contexto global. Isso ocasiona em uma expansão no compartilhamento de dados e um aumento considerável no tamanho da informação compartilhada. Ao desenvolver uma aplicação em Java a maior dificuldade é criar um software seguro e confiável. Para se evitar isto, é importante conhecer quais os principais ataques às aplicações web e quais os seus efeitos. Estes ataques podem danificar a aplicação e os dados do cliente ou utiliza-los para obter informações confidenciais do usuário. Para ter um desenvolvimento confiável em Java é preciso conhecer esta linguagem, e saber qual a sua finalidade. Portanto no capítulo 1 será apresentado o que é o Java, por que esta linguagem foi criada e quais os seus principais produtos. Pensando em segurança existem normas que podem ser seguidas para um desenvolvimento confiável, as duas que serão apresentadas são ITSEC e OWASP, porém o foco será na segunda, pois é a mais utilizada. Os princípios de segurança em Java e como ele é importante na tomada de decisões no desenvolvimento das aplicações será visto no capítulo 2. Além disto, a OWASP listou os dez principais ataques às aplicações web, e serão apresentadas suas vulnerabilidades e como evita-los. A análise dos códigos será feito no capítulo 3, quais as boas práticas de programação para se evitar os ataques listados pela OWASP. Os códigos serão analisados individualmente com exemplos de códigos vulneráveis e códigos seguros. As empresas de software para evitar que seus produtos sejam vulneráveis é ideal conhecer estes ataques. Utilizando uma aplicação segura à empresa terá mais confiança e credibilidade no mercado.
1. CONCEITOS Para se entender sobre segurança em Java é importante saber o que é o Java e quais as suas plataformas. As primeiras versões do Java tiveram como intenção criar um dispositivo que pudesse ser facilmente programável e que tinham por finalidade o entretenimento doméstico. Contudo, com o passar do tempo e com a democratização da Internet o foco mudou e diferentes plataformas foram criadas. Além disso, para se falar de desenvolvimento confiável em Java é importante conhecer sobre normas e técnicas de programação. 1.1 LINGUAGEM DE PROGRAMAÇÃO JAVA Lançado em 1995 pela Sun Microsystems, o Java, é uma linguagem e plataforma de computação encontrado em laptops, data centers, consoles de jogo, supercomputadores científicos, telefones celulares e até na Internet (JAVA, 2013). O Java não é apenas uma linguagem, mas sim uma plataforma de desenvolvimento, e com ela é possível desenvolver aplicações para diversos dispositivos diferentes como, por exemplo, aplicativos para celular. (DEVMEDIA 1, 2013). O Java possui várias plataformas, cada uma com sua finalidade. Uma breve relação das plataformas (ORACLE, 2013): JRE (Java Runtime Environment): Necessário para a execução de mini aplicativos e aplicativos que utilizam linguagem Java. JSE (Java Standard Edition): Necessário para a criação de aplicativos em desktop e computadores. JME (Java Micro Edition): Plataforma utilizada para desenvolvimento de aplicativos móveis. JEE (Java Enterprise Edition): Muito utilizado em empresas e aplicativos Web, pois suporta uma grande quantidade de usuários simultâneos.
JFX: Auxilia o desenvolvimento, pois permite que o desenvolvedor reutilize bibliotecas Java em suas aplicações. Java Card: Permite a criação e execução com segurança de cartões inteligentes. JTV: Está presente na plataforma JME. Permite o desenvolvimento de aplicativos Java executados em dispositivos de TV e set-top box (conversor). Observar-se que o Java é uma das principais linguagens para desenvolvimento de software, devido a sua quantidade de plataformas está presente na maior parte dos dispositivos, como computadores, celulares e até em dispositivos de TV. Para se entender melhor sobre o Java e suas plataformas é bom conhecer a sua história e o que foi feito para se tornar uma linguagem tão conhecida. 1.2 HISTÓRICO DAS APLICAÇÕES EM JAVA Em 1991 foi criado dentro da Sun Microsystems um grupo chamado Green Team (Time Verde), que tinha como objetivo interligar dispositivos domésticos com computadores, auxiliando no entretenimento doméstico, porém, as linguagens existentes não eram suficientes. (ORACLE TIMELINE, 2011). O Green Team foi iniciado por Patrick Naughton, Mike Sheridan, e James Gosling em 01 de fevereiro de 1991, com o objetivo de inventar uma nova tecnologia que poderia levar à convergência de dispositivos de consumo controlados digitalmente e computadores. (EASY PROGRAMING, 2013) O primeiro dispositivo em Java (até então conhecido como OAK em português Carvalho) o Star7 foi criado em 1992, por James Gosling, era uma espécie de controle remoto para eletrodoméstico. (ORACLE TIMELINE, 2011). James Gosling chamou o Java primeiramente de OAK, por causa de uma árvore de carvalho crescendo fora da janela do seu escritório, porém teve que alterar, pois este nome não estava disponível. (HELIUM, 2008). Utilizando a linguagem de programação OAK em 1994 foi criado o WebRunner (renomeado mais tarde para HotJava), o primeiro navegador que suporta objeto em movimento e conteúdo executável dinâmico. (ORACLE
TIMELINE, 2011). O desenvolvimento do navegador originalmente começou em 1994 sob o nome "WebRunner", e em 1996 foi o primeiro navegador capaz de suportar Applets Java. (COMPUTER HOPE, 2013) Somente em 1995, quando o OAK foi então renomeado para Java, que o mundo começa a conhecer esta nova linguagem de programação. Em 1996 iniciou-se a JavaOne, uma conferência anual para se discutir a tecnologia Java. A partir deste ano a linguagem Java começou a ser utilizada mundialmente e com o passar dos anos novas plataformas foram sendo anunciadas. (ORACLE TIMELINE, 2011). E foi neste ano que foi lançado o Java Development Kit (JDK ou Java 1.0). (DEVMEDIA 2, 2013). Em 1998 foi anunciado o Java Ring, um anel que continha um microprocessador que funcionava como dispositivo de segurança semelhante a um cartão inteligente. (ORACLE TIMELINE, 2011). Este anel foi produzido pela Dallas Semiconductor Corp e tinha um revestimento de aço inoxidável. (JAVA WORLD 1, 2013) A máquina virtual HotSpot foi lançada em 1999, neste ano também é anunciado o JavaServer Pages, que simplifica a criação de conteúdo Web Dinâmico. Neste ano também surgem às plataformas JEE e JME. (ORACLE TIMELINE, 2011). Com o passar dos anos novas plataformas foram apresentadas e liberadas, e o Java foi se espalhando pelo mundo. Até que em 2009 a Oracle anuncia a aquisição da Sun. (ORACLE PRESS, 2009). A ideia inicial da Sun era criar um grupo focado no desenvolvimento de dispositivos de entretenimento doméstico, mas acabou criando uma nova linguagem de programação. A cada tecnologia que surgia uma nova plataforma era criada pelo Java, tornando assim uma marca de valor, tanto que em 2009 a Oracle comprou a Sun por uma quantia milionária. Para que se crie um software confiável é importante conhecer sobre normas de segurança, as duas mais conhecidas são a ITSEC (The Information Technology Security Evaluation Criteria, ou Tecnologia da Informação de critérios para avaliação da segurança) e OWASP (The Open Web Application Security Project, ou Projeto Aberto de Segurança de Aplicações Web).
1.3 NORMAS E TÉCNICAS DE SEGURANÇA EM JAVA Colocado de forma simplificada, as normas e técnicas são uma forma acordada, repetível de se construir algo, elas tornam a criação de software mais fácil e aumentam a segurança e a efetividade do produto. Uma norma é um documento que contém uma especificação técnica e critérios precisos desenvolvidos para serem utilizados como padrão. (BSI, 2013). Em 1991 uma comissão Europeia formada por três países (Alemanha, França e Inglaterra), publicou uma norma para certificação de segurança denominada ITSEC (The Information Technology Security Evaluation Criteria), tornando-se depois de fato um padrão europeu voltado tanto para avaliação de sistema, como de produtos. Sua versão atual é a 1.2, publicada em 1991. (ABSOLUTA, 1999). Seu objetivo é demonstrar a conformidade de um produto ou sistema contra a sua meta de segurança. Primeiramente, definem-se vários Securitys Target (alvos de segurança) e após esse levantamento é realizado um teste de eficácia para cada alvo. Se necessário for, correções serão aplicadas para atingir os resultados definidos. (RYCOMBE, 2011). A ITSEC (The Open Web Application Security Project) foi criada na Europa e é utilizada em vários países, porém é uma norma antiga. Outra norma que surgiu foi a OWASP (The Open Web Application Security Project), uma norma criada para auxiliar no desenvolvimento de um software seguro. A OWASP (The Open Web Application Security Project) é uma norma criada por uma comunidade dedicada exclusivamente as empresas para adquirir, operar, conceber, desenvolver e manter aplicações com alto nível de confiabilidade e segurança. Todas as ferramentas e informações sobre a norma são gratuitas e abertas a qualquer indivíduo interessado em melhorar um produto de software. Esta norma foi estabelecida em 2001. (OWASP, 2010). Segundo levantamento feito pela OWASP em 2010, os dez principais riscos para a segurança de uma aplicação web são:
Injection: O ataque é baseado em texto que exploram a sintaxe do intérprete alvejado, assim a aplicação executa comandos não desejáveis. Cross-Site Scripting (XSS): O atacante envia os scripts de ataque baseados em texto que exploram o intérprete no navegador, que executa sem saber que se trata de um script não confiável. Broken Authentication and Session Management: Usa vazamentos ou falhas nas funções de gerenciamento de autenticação ou sessão, podendo sequestrar uma sessão do usuário e assumir sua identidade. Insecure Direct Object References: Um usuário do sistema autorizado, muda o valor do parâmetro que se refere diretamente a um objeto do sistema para outro objeto, podendo assim acessar dados que não está autorizado. Cross-Site Request Forgery (CSRF): O usuário que está autenticado executa ações indesejadas, podendo comprometer os seus dados. Security Misconfiguration: Para obter acesso não autorizado o atacante acessa contas padrão, páginas não utilizadas, falhas não corrigidas, arquivos desprotegidos e diretórios. Insecure Cryptographic Storage: Armazenamento inseguro da criptografia devido ao seu uso inadequados ou mal projetado. Failure to Restrict URL Access: O atacante utiliza as falhas de restrição de acesso à URL, para acessar páginas sem autorização. Insufficient Transport Layer Protection: É a proteção insuficiente da camada de transporte, podendo expor dados de usuários individuais e levar ao roubo de conta. Unvalidated Redirects and Forwards: O atacante engana o usuário fazendo-o clicar em um link que redireciona e encaminha para url inválido que pode tentar instalar malware ou descobrir informações confidenciais da vítima. Para se construir uma aplicação segura em Java, torna-se necessário o conhecimento das normas de segurança descritas. Torna-se improvável
certificar se um produto de software é seguro sem que ele atenda e respeite os critérios definidos em uma norma. Devem-se aplicar os conceitos e técnicas apresentado nas normas e validar se a aplicação atende aos requisitos de segurança definidos para garantir a confiabilidade da aplicação. 1.4 CONSIDERAÇÕES PARCIAIS A segurança é um fator importante quando se trata de sistemas de computadores, ainda mais sistemas para a web, onde o acesso às informações fica mais vulnerável. Fazendo uma análise para mostrar o que mais tem afetado a segurança das informações armazenadas na web, a OWASP levantou os dez principais riscos para a segurança de uma aplicação web. Neste trabalho será descrito e discutido os dez ataques, como esses atuam nas aplicações web e como é possível evitá-los.
2. PROBLEMAS DE SEGURANÇA EM JAVA O estudo e avaliação das soluções de segurança em aplicações escritas Java é de extrema importância e possui muitos desafios. As vulnerabilidades de aplicações Java listadas pela OWASP são consideradas as mais comuns e críticas. Existem também estudos voltados para a solução dessas vulnerabilidades visando a extinção dos problemas que elas trazem. 2.1 SEGURANÇA EM JAVA Princípios de segurança de aplicativos são coleções de propriedades desejáveis das aplicações de software, comportamentos, modelos e práticas de implementação que tentam reduzir a probabilidade de realização de ameaça e os impactos que essas ameaças têm sobre os aplicativos. Princípios de segurança são primitivamente independentes de linguagem e arquitetura, sendo assim, pode-se aproveitar vários modelos e práticas de programação para projetar e construir aplicações seguras. (OWASP, 2013) Os princípios de segurança são importantes porque auxiliam a tomar decisões de segurança em situações novas com as mesmas ideias básicas. Ao considerar cada um desses princípios, pode-se derivar os requisitos de segurança, fazer arquitetura e implementação de decisões, e identificar possíveis deficiências nos sistemas. (OWASP, 2013) A vulnerabilidade é um problema ou uma fraqueza na aplicação, que pode ser uma falha de projeto ou um bug de implementação, que permite a um atacante para causar danos às partes de um aplicativo. As partes interessadas incluem o dono do aplicativo, os usuários de aplicativos e outras entidades que dependem da aplicação. (OWASP, 2013) Desde que o Java começou a ser compilado, e foi desenvolvido para ser transmitido em formato binário através da rede, a programação segura tornouse importante para uma empresa de software. Nenhum usuário quer executar uma parte de um código que exista a possibilidade, na execução, acontecer algo como (GTA UFRJ, 2013):
Danificar hardware, software, ou informação na máquina do usuário; Passar informações não autorizadas para qualquer pessoa; e Tornar a máquina do usuário inutilizável através de esgotamento de recursos. Quando tornar-se necessário criar códigos fonte em Java deve-se sempre levar em consideração os três itens citados. Assim, garante-se o mínimo de segurança possível para os dados da aplicação que está executando no ambiente do cliente, e também inibe o usuário de possíveis ameaças decorrentes de um código mal feito. Os usuários que carregam arquivos do Java de servidores remotos, lugares pouco seguros, precisam se certificar que o código Java carregado em sua máquina não pode danificar ou inserir códigos maliciosos no seu ambiente. (GTA UFRJ, 2013). Diante desse ambiente é avaliado o contexto de segurança em Java dos dez principais ataques listados devido à importância definida pela norma OWASP. (OWASP, 2013): Command Injection: Falhas na injeção, tais como SQL, ocorrem quando dados não confiáveis são enviados para um intérprete, como parte de um comando ou consulta. Cross-Site Scripting (XSS): As falhas XSS ocorrem sempre que uma aplicação recebe dados não confiáveis e os envia para um navegador Web sem que os tenha validado ou filtrado convenientemente. O XSS permite aos atacantes a execução de scripts no navegador da vítima que podem ser usados para sequestrar informações da sessão do utilizador, alterar endereços Web de forma perigosa ou redirecionar o utilizador para endereços maliciosos. Broken Authentication and Session Management: Funções de aplicação relacionadas com autenticação e gerenciamento de sessão, muitas vezes não são implementadas corretamente, permitindo que os atacantes roubem senhas, chaves, fichas de sessão e assim o atacante assume a identidade do usuário no sistema em que ele está usando; Insecure Direct Object References: A referência de objeto direta ocorre quando um programador expõe uma referência de um objeto de
implementação interna, como um arquivo, diretório ou chave de banco de dados. O atacando pode acessar esse objeto para roubar dados da aplicação; Cross-Site Request Forgery: Um ataque CSRF inclui um código registrado no navegador da vítima para enviar um pedido HTTP forjado, incluindo o cookie de sessão da vítima e qualquer outra informação de autenticação; Security Misconfiguration: Boa prática de segurança é sempre manter todos os softwares utilizados pela aplicação atualizados, garantindo que nenhum atacante irá invadir, devido a uma falha que não está corrigida, pois o software não está atualizado; Insecure Cryptographic Storage: Manter todas as informações que são de acesso pessoal seguras, como CFP, RG, chave de segurança e outros, para que o atacante não roube essas informações e realize ataques como, por exemplo, clone um cartão de crédito; Failure to Restrict URL Access: As aplicações necessitam fazer controle de acesso de todas as URLs para que atacantes não tenham acesso a conteúdo oculto permitido apenas a administradores do sistema, por exemplo; Insufficient Transport Layer Protection: As aplicações devem autenticar, criptografar e proteger os dados quando os mesmo estão sendo transmitidos na rede. Muitas empresas pecam neste aspecto utilizando certificados já expirados; e Unvalidated Redirects and Forwards: As aplicações devem validar as páginas de destino quando redirecionam um usuário para que o atacante não redirecione o usuário para o destino incorreto e tenha acesso a informações pessoais do usuário. Ataques podem ocorrer com o intuito de danificar uma aplicação, portanto as empresas desenvolvedoras de software devem atentar-se para os quesitos de segurança mostrados acima. Além disso, certos ataques podem comprometer dados sigilosos, causando um dano econômico maior. Sobre os dez principais ataques listados pela OWASP, é de suma importância que o software desenvolvido tenha como objetivo inibi-los. Para que isto ocorra o desenvolvedor deve saber como eles funcionam e como são feitos. Estes tipos
de vulnerabilidades podem ser evitadas com o desenvolvimento de um software seguro e testes. 2.2 PRINCIPAIS PROBLEMAS DE SEGURANÇA EM JAVA Os principais problemas relacionados com segurança na linguagem JAVA são listados pela OWASP. Cada vulnerabilidade listada está associada a formas de ataque. A OWASAP também sugere formas de evitar que atacantes explorem essas vulnerabilidades, assim como também incentiva a produção de software que leve em consideração possíveis falhas de segurança, solucionando-as antes que ocorram. 2.2.1 COMMAND INJECTION Originalmente conhecido como injeção de comandos shell, o processo foi descoberto acidentalmente em 1997 por um programador na Noruega. A primeira injeção de comando resultou na eliminação de páginas web a partir de um site, removida tão facilmente quanto arquivos de um disquete ou disco rígido. (SEARCH SOFTWARE QUALITY, 2013). O principal objetivo deste ataque é inserir e executar comandos específicos para conseguir autenticar ou até mesmo destruir uma aplicação, conforme figura 2.2. Vale ressaltar que se o usuário possuiu acesso de administrador, o atacando que tiver sucesso na sua injeção de comando terá os mesmos privilégios que o usuário final. No geral esse tipo de ataque pode ser evitado caso haja uma validação nos dados de entrada do sistema. Muitos desenvolvedores, por falta de conhecimento, acabam não se importando com esse item de segurança. Raramente se vê nas empresas as equipes responsáveis por testes de sistema fazer esse tipo de verificação (OWASP, 2013).
Figura 2.1 Como ocorre o Command Injection Fonte: (Veracode, 2011) A figura 2.2 exemplifica uma operação normal e uma operação com Command Injection. Na primeira o usuário faz uma requisição e a aplicação mostra o resultado, já na segunda, ele insere um comando para obter uma informação adicional. Um exemplo clássico é quando o atacante insere um comando para excluir todas as tabelas do banco de dados da aplicação. Quando esse tipo de ataque dá certo, efetivamente pode acabar com um sistema caso o mesmo não tenha backup (cópia da base de dados para eventuais problemas) (OWASP, 2013). Por fim, no capítulo três são apresentados exemplos práticos de como a aplicação pode identificar que está sofrendo um ataque de command injection. Tratando as entradas de maneira correta evitará que o usuário seja afetado por este ataque. 2.2.2 CROSS-SITE REQUEST FORGERY (CSRF)
CSRF é um ataque que obriga o usuário final a executar ações maliciosas em uma aplicação web em que está logado. Com um pouco de ajuda das mídias sociais (como: envio de um hyperlink via e-mail / chat / Facebook / outros), um atacante pode forçar os usuários de uma aplicação web a executar ações que irão comprometer os dados do usuário final. Se o usuário final tiver permissões de uma conta de administrador, isso pode comprometer a aplicação web inteira (OWASP, 2013). A falsificação de solicitação entre sites envolve forçar uma vítima (usuário final) a enviar uma solicitação HTTP para um destino alvo, sem seu conhecimento ou aprovação. Muitos sites não levam em consideração essa vulnerabilidade e os desenvolvedores desses sites também não se preocupem em garantir que a aplicação esteja segura neste aspecto. (DJANGO PROJECT, 2013). Para minimizar esse tipo de ataque o desenvolvedor deve fazer validações em todo o processo de requisição de páginas HTTP do site. A primeira validação deve ocorrer no que se chama de client-side ou lado do cliente onde geralmente executa código fonte que é executada no navegador do cliente. A segunda validação deve ocorrer no que se chama de client-server ou lado do servidor no qual executa código de servidor como o Java por exemplo. Pequenas validações podem garantir que uma aplicação fique protegida das maiorias das investidas de ataques CSRF. (DJANGO PROJECT, 2013). Para evitar a falsificação CSRF, o método mais comum utilizado é a cada pedido requisitado adicionar um símbolo ao mesmo, assim o desenvolvedor terá a segurança de que o pedido é válido e não proveniente de uma fonte que não seja o usuário (VERACODE, 2013). Por fim, no capítulo 3 são apresentados exemplos práticos de como a aplicação pode identificar que está sofrendo um ataque de CSRF. Seguindo alguns métodos é possível anular ou inibir o ataque, e assim, evitar que o seu usuário final seja prejudicado.
2.2.3 CROSS SITE SCRIPTING (XSS) Considerando alguém que possa enviar dados não confiáveis para o sistema, incluindo utilizadores externos, utilizadores internos e administradores. O atacante envia scripts textuais que exploram o interpretador no seu navegador. Quase qualquer fonte de dados poderá constituir um vetor de ataque, incluindo fontes internas tais como dados de uma base de dados. (OWASP, 2013) O XSS é um dos riscos que mais prevalece no contexto das falhas de segurança em aplicações web. As falhas XSS acontecem quando uma aplicação inclui dados fornecidos pelo utilizador numa página enviada para o navegador sem que alguma validação ou filtragem tenha sido feita aos dados. Existem três tipos conhecidos de falhas XSS: Armazenada; Refletida; XSS baseado em DOM. Descobrir falhas XSS é razoavelmente fácil através de testes ou análise do código fonte, que são abordados no capítulo três. (OWASP, 2013). É necessário assegurar que todos os dados inseridos por utilizadores e enviados pelo navegador são verificados quanto à sua validade (através da validação da entrada dos dados) e que os dados são devidamente filtrados antes de serem incluídos na página. A codificação adequada da saída de dados assegura que os dados de entrada são sempre tratados como texto pelo navegador, ao invés de serem considerados como conteúdo ativo passível de ser executado. (OWASP, 2013) Tanto as ferramentas estáticas como as dinâmicas podem excluir automaticamente problemas de XSS. Mas para dificultar a detecção automática, cada uma delas utiliza diferentes interpretadores como JavaScript, Microsoft Active-X, Adobe Flash e Microsoft Silverlight e constrói as páginas de formas diferentes. Também existem tecnologias provenientes da Web 2.0, como o AJAX, que fazem com que este risco XSS seja muito mais difícil de detectar através de ferramentas automáticas (OWASP, 2013). 2.2.4 BROKEN AUTHENTICATION AND SESSION MANAGEMENT Os atacantes usam falhas ou brechas nas funções de autenticação ou de gestão de sessões (por exemplo, contas expostas, palavras chave,
identificadores de sessão) para se fazerem passar por outros utilizadores. Os programadores desenvolvem frequentemente esquemas de autenticação e de gestão de sessões, no entanto fazer isto da forma mais correta é difícil. Como resultado, estes esquemas personalizados apresentam frequentemente falhas em áreas como o fecho de sessão, gestão de palavras chave, expiração de sessões, sistemas do tipo remember me, questões secretas, atualização da conta, entre outros (OWASP, 2013). 2.2.5 INSECURE DIRECT OBJECT REFERENCES Levando em conta os perfis de usuários do sistema e suas configurações de acesso, um atacante, que por sua vez é um usuário autorizado no sistema, altera o valor do atributo de um objeto do sistema, burlando as restrições de uso de seu perfil e consegue acesso a páginas as quais não deveria ter. (OWASP, 2013). As aplicações usam frequentemente o nome real ou a chave de um objeto quando realiza a geração das páginas web. As aplicações nem sempre verificam se o utilizador está autorizado para usar o objeto alvo. Isto resulta numa falha de referência direta insegura ao objeto. Efetuando testes é possível manipular facilmente os valores dos parâmetros para excluir tais falhas e a análise de código feita no capítulo 3 mostra até que ponto está adequadamente a ser verificada a autorização. Tais falhas podem comprometer todos os dados que possam ser referenciados pelo parâmetro. A menos que o espaço dos nomes seja escasso, torna-se fácil para um atacante acessar a todos os dados disponíveis desse tipo (OWASP, 2013). 2.2.6 SECURITY MISCONFIGURATION Os atacantes externos anônimos são que tentam comprometer o sistema sem possuir o acesso e existem os atacantes internos, usuários com acesso ao sistema que pretendem disfarçar ou esconder as suas ações ilícitas. O atacante pode utilizar contas criadas por omissão, páginas não utilizadas, falhas não corrigidas, arquivos e diretórios não protegidos, entre outros, para
conseguir obter acesso não autorizado, ou para obter conhecimentos sobre o sistema. (OWASP, 2013). Uma configuração de segurança incorreta pode ocorrer a qualquer nível da pilha aplicacional, incluindo a plataforma, o servidor web, o servidor aplicacional, assim como o código personalizado desenvolvido. Os programadores e administradores de rede necessitam de trabalhar em conjunto para assegurar que a pilha aplicacional esteja convenientemente configurada. As ferramentas de pesquisa e análise automática (scanners) são bastante úteis na detecção de correções/atualizações em falta, configurações incorretas, utilização de contas por omissão, serviços desnecessários, entre outros. Estas falhas fazem com que frequentemente os atacantes possam ter acesso não autorizado a alguns dados ou funcionalidades do sistema. Ocasionalmente, estas falhas comprometem completamente o sistema (OWASP, 2013). Para saber se a aplicação é vulnerável é necessário executar uma verificação de segurança apropriada ao longo da pilha aplicacional. Uma sequência de verificações pode ser feita para identificar essas vulnerabilidades (OWASP, 2013): 1. O sistema deve possuir algum processo que permita mantê-lo atualizado. Estas atualizações devem incluir o sistema operacional, servidor web e de aplicação, sistema de gestão de bases de dados, aplicações, e todas as bibliotecas de código fonte. 2. Tudo o que não é necessário deve ter sido desativado, removido, ou não instalado (por exemplo: portas, serviços, páginas, contas e privilégios). 3. As palavras chave das contas por omissão devem ser desativadas. 4. O sistema de tratamento de erros deve ser configurado de forma que impeça que informações comprometedoras sejam divulgadas através de mensagens de erros. 5. Os frameworks de desenvolvimento (por exemplo: Structs, Spring, ASP.Net) e bibliotecas de código devem ter suas configurações configuradas. Um processo concentrado e repetitivo é necessário para desenvolver e manter uma configuração de segurança aplicacional adequada.
2.2.7 INSECURE CRYPTOGRAPHIC STORAGE Os atacantes nem sempre quebram a criptografia e sim outros elementos, tais como encontrar chaves, obter cópias legíveis de dados, ou tentam acessar dados através de canais que os decifram automaticamente. A falha mais comum nesta área é o simples fato de não cifrar os dados que necessitam ser cifrados. A utilização de funções de resumo fracas sem a utilização de fatores de entropia para proteger palavras chave é igualmente comum. Os atacantes externos têm dificuldades em detectar estas falhas devido ao seu acesso limitado e habitualmente tentam explorar outras alternativas em primeiro lugar para tentar obter o desejado acesso (OWASP, 2013). Este tipo de falha compromete frequentemente todos os dados que deveriam ter sido cifrados. Tipicamente esta informação inclui dados sensíveis tais como registos médicos, credenciais, dados pessoais, cartões de crédito, entre outros. Primeiramente é necessário determinar quais são os dados verdadeiramente sensíveis que precisam ser cifrados. Por exemplo, palavras chave, cartões de crédito, registos médicos, e informação pessoal devem ser cifrados. Para todos estes dados, é necessário assegurar (OWASP, 2013): 1. Sempre que armazenados a longo prazos, os mesmo devem estar cifrados, e por garantia, em especial em cópias de segurança. 2. Após decifrarem os dados, apenas os utilizadores autorizados devem possuir acesso as cópias decifradas (por exemplo, sistema de controle de acesso). 3. O algoritmo de criptografia deve ser forte e devidamente padronizado por entidades internacionais. 4. A chave gerada é sempre robusta, protegida contra acessos não autorizados, e se encontra planejada a futura mudança de chave. 2.2.8 FAILURE TO RESTRICT URL ACCESS Neste tipo de falha, o atacante é um utilizador autorizado do sistema que pode alterar a URL para acessar uma página com privilégios. Estes utilizadores anônimos podem acessar a páginas privadas que não estejam protegidas. As aplicações não protegem os pedidos de páginas convenientemente. Em alguns
casos a proteção da URL é gerida através de configurações, e nos casos que o sistema está mal configurado, existe a vulnerabilidade. Existe também a omissão por parte dos programadores, que esquecem de efetuar as validações apropriadas no código. A detecção destas falhas é fácil. A parte difícil está em identificar que páginas (URLs) estão vulneráveis a ataques. Tais falhas permitem aos atacantes acessar a funcionalidades não autorizadas. As funções de administração são o alvo chave neste tipo de ataque (OWASP, 2013). A melhor forma de saber se uma aplicação tem falhas na restrição de acesso a uma URL consiste em verificar todas as páginas. Cada uma das páginas pode ser pública ou privada. Se for uma página privada (OWASP, 2013): 1. Deve ser necessário algum tipo de autenticação para efetuar o acesso à página. 2. É necessário verificar se o usuário que está buscando a página tem permissão para acessa-la. Alguns mecanismos de segurança externa fornecem esse tipo de verificação de autenticação e autorização para acessar à página. É interessante verificar se estes estão configurados adequadamente para cada página. Se for utilizada proteção ao nível do código fonte, é necessário verificar também se isto foi aplicado em todas as páginas que o requerem. Os testes de penetração podem também ajudar verificar se a proteção adequada está ativa. 2.2.9 INSUFFICIENT TRANSPORT LAYER PROTECTION Para explorar esta falha, o atacando busca monitorizar o tráfego de rede dos usuários do sistema. Se a aplicação está na Internet, não é sabido quais os meios utilizados pelos usuários para acessar o sistema. Monitorar o tráfego dos usuários na rede pode ser difícil, mas na maior parte das vezes é fácil. A principal dificuldade reside na monitoração do tráfego de rede apropriado enquanto os utilizadores acessam ao endereço vulnerável (OWASP, 2013). As aplicações frequentemente não protegem o tráfego de rede. Podem utilizar SSL/TLS durante a autenticação, mas não no restante, expondo dados e Ids de sessão a possível interceptação. Certificados mal configurados ou
expirados podem também ser utilizados. Detectar falhas básicas é fácil, basta observar o tráfego de rede do endereço. Falhas mais sutis requerem inspeção da arquitetura da aplicação e da configuração do servidor (OWASP, 2013). Estas falhas expõem dados de utilizadores e podem originar roubos de contas e caso uma conta de administração seja comprometida, todo o endereço pode ser exposto. Más configurações do SSL podem também facilitar ataques de MITM (Man In The Middle) e phishing (OWASP, 2013). A melhor maneira de descobrir se uma aplicação possui proteção suficiente da camada de transporte é verificar se (OWASP, 2013): 1. O SSL é utilizado para proteger todo o tráfego relacionado com autenticações. 2. Nas páginas privadas e serviços, é utilizado o SSL para todos os recursos que fazem uso das mesmas. Isto protege todos os dados e símbolos de sessão que são trocados. A utilização de conteúdo misto numa página (conteúdo SSL e não SSL) deve ser evitado, pois isso poderá causar avisos no navegador, expondo o identificador de sessão do utilizador. 3. Apenas algoritmos robustos são suportados. 4. Todos os cookies de sessão possuem a opção secure para que o navegador nunca os transmita sem que estejam cifrados adequadamente. 5. O certificado do servidor é legítimo e está devidamente configurado. Isto inclui ser emitido por um emissor autorizado, não estar expirado, não ter sido revogado e mapear todos os domínios que o endereço utiliza. 2.2.10 UNVALIDATED REDIRECTS AND FORWARDS Não validar os encaminhamentos e redirecionamentos de endereços web pode gerar falhas onde atacantes podem encontrar uma alternativa de exploração. Um atacante pode enganar os usuários com um endereço qualquer que aponta para um redirecionamento inválido e iludem as vítimas, ou seja o usuário, para que estas os selecionem. As vítimas estão mais propensas a selecionar essa ligação, desde que a mesma pareça levar a um endereço
válido e verdadeiro. O atacante ataca encaminhamentos inseguros para tentar contornar as verificações de segurança (OWASP, 2013). As aplicações redirecionam frequentemente os utilizadores para outras páginas ou utilizam encaminhamentos internos de uma maneira similar. Em alguns casos a página destino é especificada através de um parâmetro que não é validado, permitindo assim que um atacante possa escolher a página de destino. Acabar com os redirecionamentos que não são validados é simples, basta procurar por redirecionamentos onde você pode definir o URL por completo. Os encaminhamentos não validados são mais difíceis, uma vez que eles possuem como alvo páginas internas (OWASP, 2013). Tais redirecionamentos podem tentar instalar malware ou podem tentar enganar as vítimas com o intuito de as levar a divulgar palavras chave ou outras informações sensíveis. Os encaminhamentos inseguros podem permitir contornar os controles de acesso. A melhor forma de verificar se alguma aplicação possui redirecionamentos ou encaminhamento não validados é (OWASP, 2013): 1. Quando é utilizado algum tipo de redirecionamento ou encaminhamento, o código deve ser revisado. Para cada utilização, deve-se identificar se a URL de destino faz parte de algum valor de um parâmetro. Caso seja, verificar se os parâmetros são validados para apenas conter destinos permitidos ou elementos de um destino. 2. Navegar pelo web site para verificar se o mesmo gera algum redirecionamento (códigos de resposta HTTP 300-307, tipicamente o 302). Antes do redirecionamento, deve ser verificado se os parâmetros fornecidos antecipadamente são parecidos com a URL de destino, integralmente ou parcialmente. Caso isso seja confirmado, a URL de destino deve ser alterada e deve ser verificado novamente se o web site o redireciona para esse novo destino. 3. Verificar todos os parâmetros para ver se estes parecem ser parte de uma URL de destino, de um redirecionamento ou encaminhamento, e testar todos que o sejam.
2.3 CONSIDERAÇÕES PARCIAIS É imprescindível que as aplicações tenham segurança, isto evita que o usuário final tenha problemas como perda de desempenho, inconsistência dos dados ou erros que danifiquem a sua aplicação. Seguindo algumas regras e conhecendo as principais formas de ataque, o desenvolvedor tem mais facilidade em identificar o que deve ser feito para evitá-los, e assim ter uma disponibilidade seletiva dos dados. Com a intenção de educar desenvolvedores, designers, arquitetos e organizações a respeito das consequências de deixar uma aplicação vulnerável, a OWASP listou os dez principais ataques em JAVA, e também apresentou os métodos básicos para a defesa contra esses ataques, os quais podem ser evitados com o desenvolvimento correto da aplicação. No capítulo 3 será feita uma análise dos códigos em Java em consideração a estes ataques e demonstradas formas de esquiva-los.
3. ANÁLISE DE CODIFICAÇÃO EM JAVA A maioria dos problemas relacionados à segurança de uma aplicação Java, pode ser evitado com uma prática de programação segura. Muitos códigos inseguros são a causa de vulnerabilidades de grandes ou pequenas aplicações, sendo muito comum usuários de diversos tipos de sistemas terem, por exemplo, seus dados pessoais roubados para fins ilícitos e o pior é saber que tais ataques poderiam ter sido evitados com pequenos cuidados no momento da construção do software. Por isso é de extrema importância saber identificar um código fonte seguro. Não há como certificar se o código é seguro se não se aplica ao mínimo, os conceitos explicitados na norma OWASP. A análise e o teste dos requisitos torna-se de fato, um ato importantíssimo no desenvolvimento dos produtos de software, para assim, se garantir o mínimo de segurança para aplicações que rodam sobre a plataforma do Java. Para cada vulnerabilidade é exibido um exemplo de código fonte, e é feita uma análise para identificar as boas e más práticas de programação esclarecendo e explicitando, à nível de código, alguns dos exemplos de ataques citados no presente trabalho. 3.1 ANÁLISE CROSS-SITE REQUEST FORGERY Os navegadores web (Internet Explorer, Firefefox, Chrome) permitem que as aplicações web solicitem requisições POST e GET entre vários sites. O ataque cross-site request forgery ocorre basicamente quando um usuário acessa uma página maliciosa, que faz com que o navegador envie solicitações para uma aplicação que o usuário não sabe ou não tinha a intenção. Esse tipo de ataque pode ser feito com as tags HTML (<image>, <frame>, entre outros). Assim sendo, o site malicioso pode executar ações sem a devida autorização do usuário. (VERACODE, 2013) Basicamente todas as aplicações web são vulneráveis a ataques de CSRF, e os desenvolvedores precisam proteger as suas aplicações para não ser um alvo potencial de ataques.
3.1.1 ANÁLISE DE CÓDIGOS O código 3.1.1.1 é um exemplo de um código fonte que irá identificar uma tentativa de utilizar uma parte da memória que não foi alocada pela aplicação. Código 3.1.1.1 Código vulnerável de cross-site request forgery Pode-se verificar nesse código fonte, que o atacante, dono da página Web, colocou um link com o nome Veja minhas fotos, sobretudo, quando o usuário clicar no link será redirecionado para página de um banco, na qual fará um depósito no valor de R$ 100.000,00. Sabe-se que se trata de um caso hipotético, sobretudo, é exatamente assim que acontecem os ataques aos sites. Na URL são passados alguns parâmetros, na qual faz a aplicação executar uma ação que não poderia. Para conseguir corrigir esse tipo de erro, torna-se necessário criar uma chave (Token) para cada sessão iniciada pelo usuário. Toda vez que o usuário acessa uma página Web dentro da mesma aplicação, o programa irá validar o token do usuário, caso as informações não batam, ele nega o acesso a página. O token deve ser colocado em um campo hidden, que significa escondido. (JAVA SAPAO, 2013). O Código 3.1.1.2 exemplifica isso.
Código 3.1.1.2 Código de tratamento do cross-site request forgery Fonte: JAVA SAPAO Ao acessar a página, a aplicação deve validar o token e se necessário for bloquear o acesso ao mesmo, como segue no código 3.2.1.3. (JAVA SAPAO, 2013). Código 3.1.1.3 Código validação de cross-site request forgery Fonte: JAVA SAPAO
Deve-se atentar, que sempre que usado o token deve ser descartado e a aplicação deve gerar um novo token. (JAVA SAPAO, 2013). 3.2 ANÁLISE COMMAND INJECTION Os programas externos são chamados para executar uma função requerida pelo sistema global. Esta prática é uma forma de reutilização e pode até mesmo ser considerada uma forma grosseira de engenharia de software baseada em componentes. O ataque Command Injection ocorre quando um aplicativo não consegue limpar a entrada não confiável e usa-o na execução de programas externos. (SECURECODING, 2013). A vulnerabilidade do Command Injection está na entrada dos comandos. Se o código for tratado de maneira correta evita que os dados do usuário sejam disponibilizados, excluídos ou alterados. 3.2.1 ANÁLISE DE CÓDIGOS O código 3.2.1.1 é um exemplo de código fonte que poderá danificar os dados do cliente, caso seja executada uma entrada não confiável: String sql = "select * from tabela_usuarios where login='" + campo_login +"' and senha='" + campo_senha + "'"; Statement stmt = con.createstatement(); ResultSet rs = stmt.executequery(sql); if (rs.next()) System.out.println("Usuário Logado com sucesso."); else System.out.println("Usuário ou Senha não conferem."); Código 3.2.1.1 Código sem tratamento de command injection Fonte: DEVMEDIA 3 Deve se tomar cuidado ao usar consultas SQL para validar os campos, pois isto possibilita que o atacante execute comandos que afetem o banco de dados. Por exemplo, se o usuário passasse como parâmetro de login o valor ' OR 1=1 -- isto resulta no código 3.2.1.2 (DEVMEDIA, 2013):
String sql = "select * from tabela_usuarios where login='' OR 1=1 --' and senha='" + campo_senha + "'"; Statement stmt = con.createstatement(); ResultSet rs = stmt.executequery(sql); if (rs.next()) System.out.println("Usuário Logado com sucesso."); else System.out.println("Usuário ou Senha não conferem."); Código 3.2.1.2 Código executando command injection Fonte: Adaptado de DEVMEDIA 3 Desta maneira é possível acessar a aplicação sem saber o login, pois será verificado se o login é igual a vazio ou se 1=1, retornando verdade, o resto das validações serão ignoradas porque estão comentadas. (DEVMEDIA, 2013). O código 3.2.1.3 é um exemplo de como este problema pode ser tratado. String sql = "SELECT * FROM tabela_usuarios WHERE login =? AND senha =?"; PreparedStatement prepstmt = con.preparestatement(sql); prepstmt.setstring(1,login); prepstmt.setstring(2,senha); ResultSet rs = prepstmt.executequery(); Código 3.2.1.3 Código com tratamento de command injection Fonte: DEVMEDIA 3 Neste exemplo é criado um PreparedStatement. Por vezes é mais conveniente usá-lo para enviar instruções SQL à base de dados, pois contém não apenas uma instrução SQL, mas uma instrução SQL que foi précompilada. (Docs Oracle 2, 2013). Sendo assim, pode-se verificar que utilizando comandos definidos pelo Java é possível tratar as entradas corretamente. Desta forma evita-se inconsistências nos dados dos clientes. 3.3 ANÁLISE CROSS SITE SCRIPTING Tanto as ferramentas estáticas como as dinâmicas podem detectar automaticamente problemas de XSS. No entanto, cada aplicação constrói as páginas de diferente modo e usa diferentes interpretadores associados aos navegadores como JavaScript, ActiveX, Flash e Silverlight, o que dificulta a detecção automática. Portanto, uma detecção completa destes problemas
requer uma combinação de revisão manual do código e testes de penetração manual, como complemento a qualquer abordagem automática que possa ser usada. As tecnologias Web 2.0, como o AJAX, fazem com que este risco XSS seja muito mais difícil de detectar através de ferramentas automáticas (OWASP, 2013). Se faz necessário assegurar que todos os dados inseridos por utilizadores e enviados pelo navegador são verificados quanto à sua validade (através da validação da entrada dos dados) e que os dados são devidamente filtrados antes de serem incluídos na página. A codificação adequada da saída de dados assegura que os dados de entrada são sempre tratados como texto pelo navegador, ao invés de serem considerados como conteúdo ativo passível de ser executado (OWASP, 2013). 3.3.1 ANÁLISE DE CÓDIGOS A aplicação usa dados não confiáveis na construção do fragmento de HTML como no exemplo 3.3.1.1 sem validação ou filtragem dos mesmos. O atacante modifica o parâmetro 'CC' no seu navegador para como no exemplo 3.3.1.2. Isto faz com que o ID da sessão da vítima seja enviado para o endereço web do atacante, permitindo a este último capturar a sessão corrente do utilizador (OWASP, 2013). Código 3.3.1.1 Exemplo de ataque Cross Site Scripting Fonte OWASP. Código 3.3.1.2 Exemplo de ataque Cross Site Scripting Fonte OWASP.
3.4 ANÁLISE BROKEN AUTHENTICATION AND SESSION MANAGEMENT A melhor forma de descobrir se uma aplicação é vulnerável a uma referência direta insegura a um objeto, consiste em verificar que todas as referências a objetos possuem defesas apropriadas. Para conseguir isto, é preciso considerar (OWASP, 2013): 1. Para referências diretas a recursos restritos, a aplicação necessita verificar se o utilizador está autorizado a acessar o recurso exato que foi solicitado. 2. Se a referência é uma referência indireta, o mapeamento para a referência direta deve ser limitada aos valores autorizados para o utilizador atual. A revisão do código fonte de uma aplicação pode verificar de forma fácil e rápida se as duas abordagens citadas 1 e 2 estão implementadas corretamente. Os testes são igualmente um meio eficiente para identificar referências diretas a objetos e se as mesmas são seguras. As ferramentas automáticas tipicamente não procuram este tipo de falhas uma vez que não conseguem reconhecer o que necessita de proteção e o que é ou não seguro. 3.4.1 ANÁLISE DE CÓDIGOS Ao utilizar identificadores e atributos de sessão na URL, o usuário ou atacante podem utilizá-los de forma errônea, propositalmente no caso do atacante. O Código 3.4.1.1 mostra um caso onde o atributo de identificação da sessão está presente na URL. Um usuário desavisado pode enviar a URL completa para alguém, que ao acessá-la, utilizará a mesma sessão. Código 3.4.1.1 Exemplo de uma falha no gerenciamento da sessão. Em outro tipo de ataque, o mesmo problema citado no Código 3.4.1.1 pode ser utilizado para alterar diretamente a sessão, caso o atacante conheça identificadores de sessão utilizados. Dessa forma, o usuário mal intencionado