UNIVERSIDADE DO ESTADO DE SANTA CATARINA CENTRO DE CIÊNCIA E TECNOLOGIA CCT TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

Transcrição

1 UNIVERSIDADE DO ESTADO DE SANTA CATARINA CENTRO DE CIÊNCIA E TECNOLOGIA CCT TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS LIANA BUSS LUCAS CARVALHO PUNCHIROLLI RICARDO FACHIN OLIVO ANÁLISE DAS VULNERABILIDADES ENCONTRADAS EM TÉCNICAS DE PROGRAMAÇÃO PHP PARA TRATAMENTO DE QUERIES SQL JOINVILLE

2 LISTA DE ILUSTRAÇÕES Figura 1: Linha do tempo da linguagem PHP Figura 2: Exemplo de um formulário de login. Fonte: Elaborado pelo autor Figura 3: Processo padrão de fluxo dos dados da aplicação WEB

3 LISTA DE TABELAS TABELA 1: ESTATÍSTICAS DOS ERROS PHP ENCONTRADOS NA WEB FONTE: ADAPTADO DO NVD( NATIONAL VULNERABILITY DATABASE) TABELA 2: TIPOS DE VARIÁVEIS PHP. FONTE: MELO, DE E NASCIMENTO (2007, P.52) TABELA 3: SUPERGLOBAIS PHP. FONTE: (PHP, 2013D) TABELA 4: TIPOS DE DADOS EM SQL FONTE: (PATRICK, 2002)

4 LISTA DE CÓDIGOS Código 1: Exemplo de código respeitando as normas. Fonte: (PEAR, 2013c) Código 2: Exemplo da norma para estruturas de controle com testes lógicos longos. Fonte: (PEAR, 2013c) Código 3: Exemplo da divisão das condições por variáveis. Fonte: (PEAR, 2013c) Código 4: Exemplo da divisão das condições ternárias. Fonte: (PEAR, 2013c) Código 5: Exemplo de alinhamento entre as funções. Fonte: (PEAR, 2013d) Código 6: Exemplo do alinhamento entre as igualdades. Fonte: (PEAR, 2013D) Código 7: Exemplo da disposição da definição da função. Fonte; (PEAR, 2013F) Código 8: Exemplo dos comentários de cabeçalho. Fonte: (PEAR, 2013l) Código 9: Exemplo de código vulnerável para o SQL Injection. Fonte: (WASSERMANN; SU, 2007) Código 10: Exemplo de utilização do prepared statement. Fonte: Elaborado pelo autor Código 11: Exemplo de Stored procedures no PHP. Fonte: Adaptado do site oficial do PHP Código 12: Exemplo do comando INSERT Código 13: Exemplo do comando DELETE Código 14: Exemplo do comando UPDATE. Fonte: Elaborado pelo autor Código 15: Comando DROP. Fonte: (DATABASE LANGUAGE SQL, 1992). p Código 16: Exemplo do comando SELECT Código 17: Utilização dinâmica de queries SQL. Fonte: Adaptado de (ORACLE, 2013) Código 18: Utilização da Whitelist Fonte: OWASP, Código 19: Exemplo SQL Injection Fonte: (PHP, 2013c) Código 20: Exemplo Cross Site Scripting Fonte: (OWASP, 2013B)

5 SUMÁRIO LISTA DE ILUSTRAÇÕES... 2 LISTA DE TABELAS... 3 LISTA DE CÓDIGOS INTRODUÇÃO CONCEITOS DEFINIÇÃO DE PROGRAMAÇÃO WEB HISTÓRICO DA LINGUAGEM PHP E SQL PHP SQL PROGRAMAÇÃO SEGURA NORMAS GUIA DE BOAS PRÁTICAS Identação e comprimento da linha Estruturas de controle Chamadas de funções Definições de classes Definições de funções Arrays Comentários Código de inclusão Tags de código PHP Bloco de comentários no cabeçalho Convenção de nomenclatura Formato de arquivos CONTEXTUALIZAÇÃO PHP E SQL CONSIDERAÇÕES PARCIAIS ESTUDO DAS FERRAMENTAS PHP TRATAMENTO DE DADOS TIPOS DE DADOS TECNICAS DE PROGRAMAÇÃO SQL OPERAÇÕES BÁSICAS

6 INSERT DELETE UPDATE DROP SELECT TIPO DE DADOS DA TABELA UTILIZAÇÃO DINÂMICA DE QUERIES SQL HTML TIPOS DE FORMULÁRIO METODOS GET MÉTODOS POST CONSIDERAÇÕES PARCIAIS ANÁLISE Tipos de Dados Tratamento de dados Whitelist Blacklist Sanitize SQL Injection Restrições de HTML Cross Site Scripting Considerações Parciais CONSIDERAÇÕES FINAIS REFERÊNCIAS

7 1. INTRODUÇÃO Ao longo do processo do desenvolvimento de uma aplicação WEB, são várias as etapas que exigem um cuidado do desenvolvedor para a aplicação ser segura. Empresas e mesmo órgãos do governo, em qualquer que seja o tamanho ou importância das informações passadas, necessitam da informação digitalizada para melhorar o processo de suas decisões. Independentemente do motivo para o uso de uma aplicação dentro da WEB, este processo de digitalização das informações demonstra que o processo segurança relacionada às mesmas necessita ser minucioso. A perda de dinheiro devido às consequências desse descuido pode ser catastrófica, levando a organização a um dano irreparável, que poderia ter sido evitado com um baixo investimento, se comparado ao valor de perdas e vazamento de informações da aplicação (STONEBURNER ET AL., 2004). Neste trabalho são introduzidas as fundamentações das ferramentas PHP, SQL e HTML, para o entendimento das análises das técnicas de desenvolvimento para uma aplicação segura. Para essas técnicas, foram utilizadas referências retiradas da OWASP, uma organização de desenvolvedores que tem como objetivo criar e evoluir o desenvolvimento seguro de aplicações WEB. Sendo assim, o objetivo desse trabalho é analisar vulnerabilidades encontradas na programação utilizando as linguagens PHP e SQL. Além disso, identificar técnicas sobre os aspectos de tratamento de dados através do PHP, redução das vulnerabilidades da ocorrência de SQL Injection através do uso de frameworks, tipos de dados esperados e recebidos pela aplicação, restrições de HTML juntamente com o cross site scripting. Os objetivos específicos do trabalho são relacionados ao estudo das ferramentas em conjunto com a utilização das normas OWASP para obter a segurança da aplicação: Estudo das linguagens PHP e SQL, no contexto técnico e histórico, importante para compreender a necessidade de atualização de versões e de funcionalidades. Estudo das normas OWASP e PEAR para dar à aplicação um desenvolvimento orientado para a segurança e com a padronização dos códigos da aplicação. Estudo do HTML e seus métodos nativos, através dos quais a aplicação capta os dados e transmite para as diversas páginas associadas a aplicação WEB. Estudo das normas OWASP para a segurança da aplicação WEB, no âmbito de tratamento da informação na autenticação, transmissão dos dados, tratamento dos dados 7

8 recebidos e utilização de frameworks recomendadas para a redução da possibilidade do ataque de SQL injection e cross site scripting, ambos provenientes da injeção de código na aplicação. Análise das técnicas sugeridas para a segurança da aplicação. Observar quais técnicas se encaixam melhor em determinados casos, assumindo que o processo de desenvolvimento se tornará eficiente e a aplicação segura. Através do processo listado, são obtidas informações e formas de tornar uma aplicação segura, com relação ao armazenamento dos dados do usuário e a transição dessas informações ao longo das páginas da aplicação. É através da revisão e atualização destas etapas que o processo de segurança da aplicação será confiável. O trabalho está estruturado da seguinte maneira: No Capítulo 2 são fundamentadas a definição da WEB, o histórico das linguagens utilizadas, e as comunidades que são voltadas para a segurança e padronização do código da aplicação. Através deste capítulo, é possível obter a compreensão do contexto de segurança que está inserida a aplicação que utiliza o PHP e SQL para o desenvolvimento, e também um breve histórico das versões das ferramentas, que buscaram melhorar e prover funcionalidades para o objetivo de deixar o processo de desenvolvimento mais prático e seguro. O Capítulo 3 apresenta um aprofundamento sobre as linguagens definidas para o trabalho, PHP, SQL e HTML buscando fazer citações as normas OWASP anteriormente referenciadas no trabalho. Este capítulo é necessário para a compreensão das técnicas de programação empregadas pela comunidade, bem como o conhecimento do principal framework utilizado para a realização da execução do código SQL construído pela aplicação. Por fim, o Capítulo 4 são as análises relacionadas a todas as técnicas e padrões citados anteriormente no trabalho. São descritas algumas considerações sobre usos e empregabilidade de recomendações das normas na aplicação. O trabalho foi realizado através de pesquisas feitas dentro da comunidade cientifica, com o acervo digital disponível através da rede da UDESC, e com a consulta de comunidades voltadas para a segurança da aplicação WEB. Através do estudo destas informações, analisamos as opções disponíveis para as linguagens PHP, SQL e HTML, dentro do escopo de uma aplicação WEB. 8

9 2. CONCEITOS No passado, grande parte dos ataques tradicionais era focado em redes internas. Porém, os administradores destas redes começaram a utilizar técnicas de proteção avançadas, como Firewalls, sistemas de prevenção IDS 1 /IPS 2. Os atacantes então, ao invés de atacarem estas redes mais protegidas, passaram a atacar computadores individuais através da WEB 3, onde as técnicas para não detecção dos atacantes são mais acessíveis, justamente pela comprovação de descuidos por parte dos usuários e também dos desenvolvedores (SYMANTEC, 2008). O desenvolvimento para sistemas da WEB então, através da utilização de técnicas de programação PHP e SQL para manipulação de informações, sofreu uma grande evolução com a necessidade de contenção dos ataques na WEB. Com esta evolução, as aplicações começaram a demandar também alterações estruturais dentro dos códigos, necessárias para abranger a nova complexidade do dinamismo das informações que trafegavam nas aplicações WEB. Para alcançar este objetivo, foram necessários também alguns ajustes nas ferramentas PHP 4 e SQL 5 para acompanharem o processo de segurança necessário para a utilização apropriada de tais sistemas, sejam eles apenas sites ou sistemas ERP. 2.1 DEFINIÇÃO DE PROGRAMAÇÃO WEB A WEB consiste em um meio de informação, tendo em suas aplicações um padrão de orientação a conteúdo (JACYNTHO, 2009), e seu processamento ocorre através de um ambiente distribuído, com uma parte sendo executada no lado cliente, o qual pode ser apenas um ou vários computadores, e outra parte da aplicação no lado do servidor (ARAUJO, 1997). Dentro da programação WEB, no lado servidor, existem várias linguagens disponíveis para o processamento das informações: ASP,.NET, CGI, Perl, Java, Groovy, Python, Ruby, entre outras. No entanto, o PHP foi a linguagem escolhida para a análise, devido a sua popularidade, alcançada em grande parte por ser open-source. Como prova disto, podemos citar algumas aplicações WEB famosas: Facebook, Flickr, Wikipedia, SugarCRM, Dotproject, Drupal, entre outros(macintyre, 2010). E para a manipulação do banco de dados existem 1 Intrusion Detecion System 2 Intrusion Prevention System 3 World Wide Web 4 Hypetext Preprocessor 5 Structured Query Language 9

10 algumas ferramentas à disposição dentro do mercado, como as principais podemos citar: MySQL, Postgress, MS-SQL, Oracle (VOGT, 2008). Apesar de existir um padrão SQL, existem diferenças da interpretação e em algumas características destas ferramentas, obrigando o desenvolvedor muitas vezes a tratar uma mesma instrução de formas diferentes entre as ferramentas (ARVIN, 2012). Para a compreensão destas características, é necessário compreender o contexto histórico de cada uma destas ferramentas, juntamente com a linguagem PHP, para observar a evolução e as peculiaridades criadas pelos seus desenvolvedores, para contornar os problemas que surgiram ao longo do tempo. 2.2 HISTÓRICO DA LINGUAGEM PHP E SQL Com o crescimento do uso da WEB, cresceu também o interesse por linguagens para tratar o dinamismo de aplicações desse porte. Assim como ocorreu com o GNU/Linux, diversos desenvolvedores do software livre acabaram se interessando pela linguagem PHP e passaram a contribuir com ideias. Entre algumas destas ideias, estava a conexão com o banco de dados e a exibição destes resultados de maneira dinâmica (MELO, DE E NASCIMENTO, 2007). A evolução desta técnica de manipulação de dados foi fundamental para acompanhar o processo de segurança do desenvolvimento destas aplicações WEB PHP O antecessor do PHP é um produto chamado de PHP/FI. O seu criador Rasmus Lerdorf, em 1995, desenvolveu uma série de scripts PERL, os quais foram nominados de Personal Home Page Tools para obter estatísticas de acesso de seu currículo online. A partir da necessidade de mais funcionalidades, Rasmus escreveu uma aplicação C mais robusta, capaz de se comunicar com base de dados, permitindo assim que usuários passassem a desenvolver aplicativos dinâmicos para WEB. Esta implementação foi disponibilizada na Internet, seja para utilização, ou para que todos tivessem acesso ao código. (PHP, 2013a). Já na versão 2.0, teve a sua plataforma desenvolvida em C e foi lançada com o nome PHP/FI 2.0, e obteve o apoio e reconhecimento de milhares de usuários e desenvolvedores. Com a utilização de um número aproximado de domínios, o PHP/FI foi relatado em uma base de 1% dos domínios da WEB(MELO, DE E NASCIMENTO, 2007). A integração 10

11 com o banco de dados foi criada a partir desta versão, e esse fato contribuiu para o aumento de seus usuários(macintyre, 2010). A versão 3.0 do PHP, foi escrita por Andi Gutmans e Zeev Suraski em 1997, e é a versão que mais se assemelha ao PHP que é utilizado atualmente. Esta versão foi totalmente reescrita, após os seus autores perceberem a grande capacidade do PHP/FI 2.0 em seus projetos de comércio eletrônico da faculdade. A versão oferecia para os usuários finais uma infraestrutura sólida para diversos bancos de dados, protocolos e APIs (MELO, DE E NASCIMENTO, 2007). No entanto, o PHP 3.0 não foi construído pensando em uma grande complexidade das aplicações, as quais já começavam a demandar mais eficiência da linguagem. Para este propósito foi lançada em 1999 a zend engine, e no ano seguinte baseado na nova engine, foi lançado o PHP 4.0, com melhorias relacionadas a performance, suporte a diversos servidores WEB, sessões HTTP, buffer de saída e maneiras mais seguras de manipular entradas de dados do usuário. Atualmente, o PHP conta com 20% dos domínios da internet(php, 2013a). A versão 5.0 foi a versão que quebrou uma série de paradigmas existentes da linguagem. A partir desta, é possível desenvolver o código com orientação a objetos de uma forma consistente. Feita em cima da Zend Engine 2, esta versão foi lançada oficialmente em Julho de Também foram lançadas algumas outras funcionalidades, como melhoria de suporte a XML 6, manipulação de webservices SOAP 7 e REST 8, suporte melhorado ao SQL, e também melhorou o gerenciamento de memória(melo, DE E NASCIMENTO, 2007). Observando o contexto histórico, é notável como o lançamento de novas versões da linguagem acompanhou o processo de crescimento da WEB, como observado na figura 1. 6 extensible Markup Language 7 Simple Object Access Protocol. 8 Representional State Transfer 11

12 Criação da primeira versão do PHP/FI Lançada a versão PHP Desenvolvida a Zend Engine PHP 5.0 lançado juntamente com o Zend Lançada a segunda versão do PHP/FI PHP 3.0 utilizada por 10% dos servidores A partir da Zend Engine, foi lançada a versão PHP 4.0 Figura 1: Linha do tempo da linguagem PHP. Através de todas as evoluções e alterações do projeto inicial (figura 1), é notável a evolução da linguagem nos quesitos de segurança, confiabilidade e nas técnicas de programação suportadas. No entanto, apenas a evolução da linguagem não iria suprir o processo de segurança e de tecnologia necessário pelo mercado no decorrer dos anos. Para alcançar esse propósito foram efetuadas e analisadas também algumas modificações na linguagem SQL SQL Nos anos 70, a IBM sentia a necessidade de um método padronizado para a manipulação de dados em um banco de dados relacional. Para esse objetivo, Dr. E. F. Codd, pesquisador da IBM, desenvolveu um produto chamado de SEQUEL 9, o qual mais tarde viria a ser rebatizado de SQL 10. Codd, em sua teoria, aplicou regras matemáticas rigorosas para a manipulação dos dados, obedecendo a uma lista de critérios que um banco de dados deve respeitar para ser considerado relacional (KLINE, 2010). Inicialmente as bases de dados relacionais realizavam um processamento paralelo, o qual fornecia dados para uma aplicação escrita em uma linguagem processual, como o C ou Cobol (PATRICK, 2002). Apesar de a IBM ter sido a criadora da teoria, a Oracle foi a primeira empresa que utilizou a tecnologia comercialmente. A IBM começou o trabalho com o System/R, em Era um trabalho em testes e, portanto, não utilizado comercialmente (Chamberlin et al., Structured English Query Language Uma das primeiras versões do SQL. 10 Structured Query Language Nome utilizado atualmente para a linguagem de dados relacional. 12

13 apud VOGT, 2008). Logo após a criação do SEQUEL, a Oracle iniciou o desenvolvimento da aplicação RDBMS 11, a qual utilizava SQL(Drake,2001, apud VOGT, 2008). No mesmo ano do término dos testes do System/R, a Oracle lançou sua primeira aplicação comercial (Oracle, 2003 apud VOGT, 2008) que suportava SQL, se posicionando, portanto, dois anos a frente da IBM no mercado (Drake, 2003 apud VOGT, 2008). Com o tempo o SQL aumentou sua popularidade, chamando a atenção da American National Standards Institute(ANSI), que criou os padrões de SQL lançados posteriormente em 1986,1989, 1992, 1999, 2003, 2006(KLINE, 2010). Juntamente com a evolução da estruturação, plataforma e ferramentas das linguagens descritas, e os padrões adotados pela ANSI, surgiu também a necessidade de algumas normas e técnicas para a programação da aplicação ser confiável e manter padronizados os códigos entre si. Para isso serão descritos alguns tópicos relacionados à programação segura, suas normas e também o guia de boas práticas. 2.3 PROGRAMAÇÃO SEGURA Com a evolução das aplicações WEB, passando de simples websites, cujo propósito era apenas prover alguma informação de uma maneira simplória, para sistemas complexos repletos de transações de dados entre as páginas, surgiu também à existência de um processo de software sistemático, apoiando o ciclo de vida do sistema (JACYNTHO, 2009). Portanto, a partir dessa evolução surge também necessidade de maior controle dentro da programação. As partes mais vulneráveis de uma aplicação WEB são os trechos nos quais existe o fornecimento ou a manipulação dos dados (MACINTYRE, 2010), como por exemplo as telas de login da aplicação, ou algum processo no qual exista alguma manipulação da base de dados. A partir destas necessidades dentro do código da aplicação, devem-se tratar estes dados da melhor maneira possível dentro das sessões criticas, seguindo algumas normas recomendadas para o desenvolvimento, especificadas por uma comunidade de desenvolvedores com o intuito de propagar técnicas de desenvolvimento para aplicações seguras. Estas normas buscam tratar os dados que serão manipulados, assegurar que existirá codificação dos dados para dificultar sua leitura, manter a versão da linguagem sempre atualizada, entre outras especificações. 11 Relational Database Management System Gerenciamento de banco de dados relacional. 13

14 2.3.1 NORMAS Com o intuito de tomar precauções contra os atacantes da WEB, foi criada uma comunidade no ano de 2001 nos Estados Unidos, chamada OWASP 12, sem fins lucrativos, com objetivo de fornecer informações para o desenvolvimento de aplicações seguras na WEB. Devido a não possuir vínculos com empresas, a comunidade pode fornecer informações não tendenciosas, praticas, e relacionando o melhor custo-benefício sobre as técnicas (OWASP, 2013A). Geralmente quando é criada uma aplicação WEB, existirá em algum momento a entrada de dados para o login da aplicação. A estrutura geralmente segue o mesmo padrão, usuários são criados com alguma senha definida ou não por ele, e então são armazenados em algum banco de dados. Para haver a autenticação e armazenamento desses dados de forma segura, devem ser respeitadas as seguintes regras: (OWASP, 2009a) As credenciais do usuário devem utilizar um algoritmo de hash confiável, antes de serem armazenadas no banco de dados (OWASP, 2009a). Para o caso do PHP, a partir da versão 5.5, existe a função password_hash que utiliza algoritmo BCrypt, o algoritmo mais poderoso e seguro suportado pelo PHP, atualmente(ferrara, 2012). As credenciais devem ser transmitidas através de links codificados. O sistema de armazenamento de variáveis deve programar configurações para limite de tentativas de login, complexidade da senha, e deve emitir alerta de acordo com a necessidade. A aplicação deve ser desenvolvida para suportar diferentes algoritmos de hash, pois é bem provável que ao longo do tempo, a troca de algoritmos para seguir o processo de segurança, será inevitável. Todas as funções que tratam de dados privados, devem ser protegidas por um mecanismo de autenticação comum para toda a aplicação. As aplicações devem emitir alerta no caso de falhas de login do usuário, e disponibilizar a opção de recuperação de senha. Todas as páginas da aplicação devem ter um botão de logout para o usuário. Senhas necessitam ser facilmente modificadas pelo usuário. 12 The Open Web Application Security Project Comunidade internacional que discute as formas de tornar aplicações WEB seguras. 14

15 As aplicações devem manter um log, com os acessos do usuário. No processo de autenticação, deve ser informado ao usuário se a conta informada existe, ou a senha está incorreta. As aplicações devem possuir funções administrativas com o intuito de gerenciar contas que nunca foram utilizadas, contas que estão inativas por muito tempo, ou contas que estão bloqueadas. É recomendado existir uma diferença entre contas bloqueadas pelo administrador, e as contas que foram bloqueadas devido a várias tentativas de login, para que caso seja necessário habilitar todos os usuários do sistema, os usuários que foram bloqueados pelo administrador continuem bloqueados. Aplicações que manipulam dados com informações valiosas, devem requerer a autenticação do usuário novamente para realizar as transações as transações. Aplicações não devem guardar partes de senhas em respostas para perguntas de recuperação de senha. Não devem ser informados nenhum dado de autenticação para fontes desconhecidas, tais como cookies, header, ou arquivos escondidos. Não devem ser utilizados recursos da infraestrutura para autenticação, como por exemplo, endereços IPs, já que estes podem ser forjados. Todas as regras listadas pela OWASP demonstram a preocupação com a manipulação dos dados, o seu armazenamento de forma segura, a forma de resgatar dados confiáveis, como a senha, para o usuário, de forma que somente o usuário capacitado pelo sistema a fazer uma operação especifica seja de fato, capaz de fazê-la. Os atacantes sempre esbarrarão diante de uma dificuldade, pois as normas buscam justamente cortar as formas que venham a facilitar o ataque. Outra medida importante que deve ser levada em consideração é a filtragem dos dados de fora passados para a aplicação. Pode-se citar como exemplo os dados que provém das variáveis $_POST e $_GET, ou mesmo valores definidos na variável global do servidor $_SERVER (OWASP, 2013B), ou mesmo dados passados para o arquivo HTML, permitindo a execução de código JavaScript dentro da sua aplicação, técnica conhecida como Cross-Site Scripting(OWASP, 2009b). Para uma aplicação ser construída de forma a ser confiável, devem ser levados em consideração pelo desenvolvedor, todos os possíveis meios que a aplicação WEB em questão, se comunica com o exterior da mesma. 15

16 Uma boa técnica para filtrar estes dados, é a utilização de técnicas que retirem todos os caracteres ilegais ou inseguros para a aplicação. No PHP, para o caso de validação de dados que serão passados para um comando SQL, existe a extensão PDO 13 (PHP, 2013b), com técnicas especificas como, por exemplo, prepared statements ou stored procedures, que irá filtrar os dados para evitar um ataque de SQL Injection(OWASP, 2012A). Por fim, a validação dos tipos de dados que são esperados na aplicação deve ser sempre feita, verificando se o que está sendo recebido é o tipo de dado esperado (OWASP, 2009b). Se por exemplo, a aplicação está aguardando a entrada de um , em determinada variável, é necessário algum mecanismo para validar se o usuário está passando, de fato, um . As normas são de fato fundamentais para o desenvolvimento ser confiável, porém existem também técnicas para o desenvolvimento em PHP ser mais eficaz e organizado. Estas técnicas são chamadas de boas práticas, pequenas maneiras de se escrever um código que deixará ele padronizado de acordo com a comunidade GUIA DE BOAS PRÁTICAS Existem alguns manuais dispostos pela Internet, ou através de livros, para guiar o desenvolvedor para boas práticas de programação, seja para a lógica da programação de uma maneira geral, ou PHP especificamente, como por exemplo o site Phptherightway(PHP THE RIGHT WAY, 2013) ou livros como (SHIFFLET, 2005). Como o trabalho aborda o PHP especificamente, e não a lógica de desenvolvimento, foi empregado o guia publicado pela comunidade oficial do PHP, PEAR que aborda de maneira genérica algumas práticas que farão com o que código seja reutilizável, e facilitará também a implementação de código já existente da comunidade. Para o desenvolvimento WEB em PHP seguir um padrão e ser o mais reutilizável possível, foi criado o PEAR 14 em Segundo seu idealizador, Stig S. Bakken, a missão é dispor componentes reutilizáveis, incentivar inovações para o PHP, e educar os desenvolvedores, com a disponibilização das seguintes ferramentas: (BAKKEN, 2007). Uma biblioteca com códigos open-source para os desenvolvedores; Um sistema para distribuição de códigos e manutenção de pacotes; 13 The PHP Data Objects Extensão para php para manipulação de comandos SQL. 14 PHP Extension and Application Repository Framework para auxílio do desenvolvimento PHP. 16

17 Normas para o desenvolvimento em PHP; A PECL 15, para distribuição de extensões escritas para o PHP; e Um website, listas de discussão e mirrors para ajudar a comunidade. Com essas ferramentas disponibilizadas para os desenvolvedores, a praticidade para encontrar alguma funcionalidade que é necessária é grande. Podemos encontrar, por exemplo, na página do PECL, extensões para autenticação, como o krb5 16, ou ferramentas para codificação do código, como o BLENC 17. E caso não exista a solução para o problema do desenvolvedor, existem listas de discussão de apoio para auxiliá-lo no desenvolvimento da aplicação. Para a obtenção do objetivo de padronização dos códigos, foram criadas algumas normas com a ajuda dos desenvolvedores, que com o passar do tempo, sofreram alguns ajustes através da publicação de RFCs(PEAR, 2013a). São elas as seguintes: Identação e comprimento da linha A identação deve, por padrão, possuir o tamanho de 4 espaços, sem a utilização de tabulação, para evitar problemas com diffs 18, patches 19, histórico na SVN 20, e anotações. E para o comprimento das linhas, a norma define que uma linha possua aproximadamente de 75 a 85 caracteres, para melhor leitura do código-fonte (PEAR, 2013b) Estruturas de controle Norma criada para padronizar a forma de dispor no código as estruturas if, else, while, switch, etc. No Código 1 é apresentado um exemplo de como é a recomendação (PEAR, 2013c). 15 PHP Extension Community Library Biblioteca com extensões para o PHP. 16 Kerberos authentication and management 17 Transparent PHP Script Encryption using Blowfish 18 Função da SVN que computa as diferenças entre determinadas versões de códigos 19 Parte de software que resolve problemas da aplicação ou atualiza 20 Subversion Software para controlar versões de código e disponibilizá-las a partir de um número de revisão. 17

18 Código 1: Exemplo de código respeitando as normas. Fonte: (PEAR, 2013c). As estruturas de controle (Código 1) devem possuir um espaço entre os parênteses e a palavra reservada, para haver uma diferença elas das chamadas de funções. Também é recomendado o uso de parênteses mesmo em situações que o uso dele não seja necessário, diminuindo assim a ocorrência de erros de lógica, e melhorando a compreensão do código (PEAR, 2013c). Estes ajustes tornam o desenvolvimento muito mais rápido e organizado, para o desenvolvedor que siga essa recomendação, devido a organização e aos espaços das condições lógicas, tornando a compreensão mais ágil. Existem também os casos em que o teste de lógica dentro de um if, por exemplo, são grandes o suficiente para ultrapassarem o limite de caracteres de uma linha. Para estes casos, é recomendada a quebra de linha entre os operadores lógicos, como observado no código 2 (PEAR, 2013c). Código 2: Exemplo da norma para estruturas de controle com testes lógicos longos. Fonte: (PEAR, 2013c). Para seguir o padrão, as condições devem ser posicionadas na próxima linha, como é apresentado no código 2, com a identação de quatro caracteres. Os operadores lógicos devem estar no começo da sentença para facilitar a exclusão da linha. Apesar dessa recomendação, o melhor caso seria dividir as condições lógicas por variáveis, desta forma, deixando a condição principal utilizada dentro da estrutura mais curta e facilitando sua leitura, como visto no código 3(PEAR, 2013C). 18

19 Código 3: Exemplo da divisão das condições por variáveis. Fonte: (PEAR, 2013c). No caso exemplificado (Código 3), existem quatro condições lógicas, havendo assim a necessidade da divisão por linhas. Para evitar a quebra de linha, foram criadas duas variáveis para receberem as condições lógicas, respectivamente, ($condition1 $condition2) e ($condition3 & $condition4). Em seguida estas variáveis contendo o resultado das condições, é utilizada no controle if. Todas estas recomendações se aplicam aos testes ternários 21 apenas mantendo o ponto de interrogação e os dois pontos na frente da linha, como observado no código 4(PEAR, 2013c). Código 4: Exemplo da divisão das condições ternárias. Fonte: (PEAR, 2013c). Seguindo o padrão, as condições foram mantidas na mesma linha e houve a quebra de informações (Código 4), com os identificadores reservados sendo deslocados para o inicio da linha quando necessário Chamadas de funções Funções devem ser chamadas sem espaços entre o nome da função e o parênteses, entre o parênteses e o primeiro parâmetro, o último parâmetro e o parênteses, e o parênteses e o ponto e vírgula. Apenas terá espaço entre a vírgula e o restante dos parâmetros, se 21 Operador ternário operador para expressão condicional. 19

20 houverem. Em casos em que a função é definida para várias variáveis, espaços podem ser definidos para a melhor leitura do código, como verificado no código 5(PEAR, 2013d). Código 5: Exemplo de alinhamento entre as funções. Fonte: (PEAR, 2013d). Para a facilitação de leitura, foram adicionados espaços entre os parâmetros e as vírgulas (Código 5), para ficarem na mesma linha vertical dentro do código, facilitando o trabalho de um desenvolvedor que possua a necessidade, por exemplo, de pesquisa de algum parâmetro especifico que está sendo atribuído para tal função. Como parâmetros de função sempre são muito buscados pelos desenvolvedores e mantenedores da aplicação, a facilidade para sua legibilidade pode acarretar maior velocidade de resolução de erros ou mesmo de reutilização de algum trecho de código. No caso de alinhamento de atribuições, o sinal de igualdade deve ficar sempre alinhado com os sinais de igualdade que aparecerem nas linhas seguintes, salvo o caso da diferença do comprimento da linha ser superior a de 8 caracteres, como visto no código 6(PEAR, 2013D) Código 6: Exemplo do alinhamento entre as igualdades. Fonte: (PEAR, 2013D). No caso das duas primeiras atribuições (Código 6), é nítido que a diferença é menor do que 8 caracteres, entrando assim, na regra de alinhamento dos sinais de igualdade. Porém, nas linhas seguintes, como a variável extrapolou a diferença de 8 caracteres, não foi efetuado o alinhamento. 20

21 Definições de classes A única norma, é que a chave para iniciar classe deve constar em uma nova linha(pear, 2013e) Definições de funções Argumentos com valores padrões devem ser declarados apenas no final da lista de argumentos, para facilitar o trabalho do desenvolvedor ao utilizar a função. Sempre é aconselhável retornar algum valor da função. A declaração das funções segue o padrão K&R Style 22, ou seja, ao declarar o nome da função, a chave é inserida em uma nova linha, e no termino da função, a chave que fechará a função deve ser disposta alinhada com a chave aberta pela função, como visto no código 7 (PEAR, 2013F). Código 7: Exemplo da disposição da definição da função. Fonte; (PEAR, 2013F). No exemplo é possível perceber, a abertura da chave das estruturas de controle segue a norma recomendada citada anteriormente, porém as chaves relacionadas com a definição da função seguem o K&R Style. Também é importante relatar a declaração de argumento com valor padrão para o final da lista de argumentos para o desenvolvedor não precisar atribuir valores toda vez em que será utilizada a função. 22 Nome dado ao estilo usado no livro de Kernighan e Ritchie The C Programming Language 21

22 Arrays Os parâmetros dos arrays, devem ser alinhados, e o após o ultimo valor atribuído, deve ser colocado uma ultima virgular, para manter os diffs de maneira padrão(pear, 2013g) Comentários Devem ser documentados trechos mais complexos do código, para facilitar a compreensão do seu funcionamento. O uso de comentários pode ser através das barras utilizadas em C (/* */) ou C++(//). O uso do estilo de comentários de Perl(#), não é recomendado pela norma(pear, 2013h) Código de inclusão Em todos os casos que esteja sendo adicionada uma classe, sem condições impostas, deve-se utilizar o require_once. Para os demais casos que necessitem de uma condicional, é recomendada a utilização do include_once. Com esses cuidados, será assegurado que os arquivos serão adicionados uma única vez durante a execução (PEAR, 2013i) Tags de código PHP As tags delimitadoras do código PHP devem sempre ser utilizadas da forma <?php?>, e jamais utilizar apenas <??>. Por questões de portabilidade a primeira opção é a indicada para não ocorrerem problemas. (PEAR, 2013j) Bloco de comentários no cabeçalho Incluir no começo dos arquivos, um comentário page-level, e acima das classes um comentário class-level, seguindo o exemplo do código 8(PEAR, 2013l). 22

23 Código 8: Exemplo dos comentários de cabeçalho. Fonte: (PEAR, 2013l). Na parte superior do exemplo, foram colocados os comentários relacionados ao arquivo, com informações como categoria, pacote no qual o arquivo esta, autor, etc. E na parte inferior, está o comentário relacionado a classe, com informações como autor, versão, pacote, categoria, etc Convenção de nomenclatura Se for necessário a definição de variáveis globais, seus nomes devem começar com um 23

24 underline, seguido do nome do pacote e outro underline, como por exemplo, dentro do pacote PEAR existe a variável global $_PEAR_destructor_object_list. Funções globais devem ter também o nome do pacote em caps lock no inicio, para evitar colisões, e em seguida o nome da função em letra minúscula. Porém a cada nova palavra dentro do nome da função, deve-se iniciar com letra maiúscula, como por exemplo: XML_RPC_serializeData()(PEAR, 2013m). Com relação às classes, devem ser criados nomes que descrevam sua funcionalidade, e sempre se deve iniciar com letra maiúscula. Já os seus métodos e variáveis usam o studly caps 23, como por exemplo: buildsomewidget(). No caso de serem métodos privados, inicia-se com um underline (PEAR, 2013m). Já as constantes, devem ter todas as letras maiúsculas, e para se separar as palavras é utilizado o underline. O prefixo dessas variáveis deve ser o nome da classe ou pacote nos quais eles estão sendo utilizados (PEAR, 2013m). Dentro de um código, a nomenclatura é importante para haver uma boa apresentação do trecho. Quando um desenvolvedor segue os padrões PEAR para criar os nomes de suas classes, constantes, variáveis ou funções, ele estará implicitamente adicionando sua funcionalidade no nome, e também o local onde ele se encontra no caso de ser algum trecho global do código. Quando a leitura da função já está definindo estes atributos, o programador muitas vezes economizará tempo buscando a sua compreensão Formato de arquivos Devem ser utilizados o ISO ou UTF-8 para codificação dos caracteres. Utilizar o Unix formating, ou seja, as linhas devem terminar com o line feed 24. E é necessário também exista um line feed após a tag de fechamento do código php?>(pear, 2013n). Todas estas práticas abrangem formas fundamentais para se organizar o código. Porém é válido salientar que não foram verificadas práticas que estivessem focadas com a segurança da aplicação, o que pode ser considerado uma falha para uma comunidade oficial da linguagem. 2.4 CONTEXTUALIZAÇÃO PHP E SQL Após o levantamento de padrões e normas para o desenvolvimento da aplicação, é 23 Studly caps é uma forma de nomear a variável através de algum padrão para a capitalização das letras. 24 Line feed Caractere para identificar ao sistema baseado em ASCII o inicio de uma nova linha 24

25 possível perceber que o desenvolvimento em PHP, mesmo com a utilização conjunta do SQL, é simples de ser feito, já que a linguagem aceita facilmente a implementação que for definida. Porém, esta característica do PHP se torna muitas vezes um problema quando desenvolvido sem o seguimento de alguma norma, podendo ocasionar a geração de vários erros, e destes erros ocorrendo o surgimento de várias vulnerabilidades (CRANE, 2013). Existem alguns problemas no desenvolvimento PHP que podem gerar diversos erros, os quais podem atrasar o andamento do projeto. Se o desenvolvedor do código não seguir os padrões recomendados pela PEAR, para nomenclatura das funções, por exemplo, existe a probabilidade de existirem problemas devido a falta do recurso de namespace 25 nas versões anteriores a versão dentro da linguagem PHP. Isto é claro, além dos problemas já citados neste trabalho, na seção 1.3.1, principalmente relacionados à construção de comandos SQL dentro do PHP (PHP, 2013c). Portanto, a conclusão tirada é que apesar das diversas normas, padrões, e ferramentas disponíveis para auxiliar o desenvolvedor na construção de sua aplicação, o PHP permite que o desenvolvimento seja finalizado sem dificuldades, mesmo que não sejam seguidos nenhum destes requisitos. É possível observar na tabela 1, tirada a partir da página NVD (National Vulnerability Database), que grande parte das vulnerabilidades relatadas na WEB possui a origem em códigos PHP. 25 Namespace - Uma separação das variáveis através do local no qual onde elas estão inseridas. 25

26 Ano Total de vulnerabilidades Porcentual dentro da WEB Tabela 1: Estatísticas dos erros PHP encontrados na WEB Fonte: Adaptado do NVD 26 ( National Vulnerability Database) É possível visualizar a partir da tabela 1 que existem anos onde o porcentual de erros na WEB atingiu uma marca muito alta, como por exemplo, o ano de 2002, com 74.03%. É também nítido que o porcentual de erros começa a reduzir, com relação ao ano de lançamento da versão 5.3 do PHP, em 2009, onde a versão 5.0 já estava alguns anos no mercado, demonstrando o quão importante é possuir a versão mais atualizada possível do PHP. É válido relatar que esta tabela pode conter alguns desvios nos números reais, pois nem todos os erros relacionados com PHP relatados podem ser de fato de origem do código PHP, já que o código está geralmente em conjunto com código HTML e JAVASCRIPT (COELHO, 2013). Após a contextualização das linguagens em conjunto para o desenvolvimento da aplicação WEB, serão observadas algumas considerações finais necessárias para o desenvolvimento do restante do trabalho. Estas considerações irão abranger o capitulo 1, com algumas observações pertinentes relacionadas aos assuntos descritos neste trabalho. 26 Disponível em: < results?cves=on&query=php&cwe_id=&pub_date_start_month=-1&pub_date_start_year=- 1&pub_date_end_month=-1&pub_date_end_year=-1&mod_date_start_month=-1&mod_date_start_year=- 1&mod_date_end_month=-1&mod_date_end_year=- 1&cvss_sev_base=&cvss_av=&cvss_ac=&cvss_au=&cvss_c=&cvss_i=&cvss_a=>. Acesso em maio de

27 2.5 CONSIDERAÇÕES PARCIAIS Através do histórico das linguagens é possível observar que dentro da linguagem PHP, existiu a preocupação por parte da equipe de desenvolvedores, de corrigir alguns erros pertinentes ao simplismo implícito da linguagem, a partir de versões após a 5.0. No entanto, ainda é muito alto o porcentual de vulnerabilidades encontrado na WEB, como foi observado na seção 1.4, através da tabela 1. Para a aplicação WEB desenvolvida não fazer parte desta estatística, é necessário, além da utilização da versão mais recente do PHP, a utilização das normas, principalmente as apresentadas na seção 1.3.1, relacionadas a OWASP, e a utilização de ferramentas recomendadas pelas próprias normas, e disponibilizadas pelo próprio PHP, através do repositório PEAR. As normas OWASP são extremamente necessárias à aplicação WEB se tornar segura. Apesar do trabalho ao se seguir algumas dessas normas, o processo de segurança exigirá muito menos trabalho adicional se estas forem seguidas. Para isso é necessário o treinamento dos desenvolvedores da aplicação, a conscientização por parte das empresas ao desenvolver as aplicações de que elas precisam ser orientadas a sua segurança, e ter esta ideia a partir do seu núcleo de desenvolvimento. É recomendável também o incentivo a OWASP, pois a partir deste, os pesquisadores irão desenvolver novas técnicas necessárias para o processo de segurança da aplicação. Estes processos estão em constante atualização, já que os atacantes estão sempre em busca de falhas e vulnerabilidades das aplicações (OWASP, 2013B). Para o entendimento destas técnicas, são necessários os estudos das ferramentas PHP e SQL em conjunto. No capítulo 2 serão abordadas justamente as principais técnicas relacionadas às linguagens e alguns exemplos de utilização das normas relacionadas no capitulo 1. 27

28 3. ESTUDO DAS FERRAMENTAS Para a compreensão das técnicas utilizadas para a proteção dos dados que transitam na aplicação, é necessário o aprofundamento com relação às ferramentas utilizadas neste trabalho, o PHP e o SQL. O foco principal será com relação à filtragem e tratamento dos dados da aplicação, para evitar injeções de códigos maliciosos na parte dos comandos SQL através do PHP, via métodos de transmissão de dados GET ou POST do HTML (OWASP, 2013b). Através das regras citadas para filtragem dos dados, também é possível evitar os ataques onde são enviados códigos maliciosos para o script da aplicação, caracterizando o Cross-Site Scripting 27 (OWASP, 2011). Através das normas listadas pela OWASP, com explicações através de trechos de códigos, serão demonstradas as normas aplicadas em casos reais da aplicação. Através destas normas é possível viabilizar o uso comercial seguro da aplicação, com redução de riscos e a consequente economia de gastos em casos de ocorrências relacionadas a ataques da aplicação. 3.1 PHP O PHP, como citado no Capítulo 1, nasceu com a prerrogativa de disponibilizar páginas de forma dinâmica, com isso disponibilizando os dados e os transmitindo de acordo com a programação empregada. Consequentemente, será esta a linguagem, que ditará na maior parte do código, as normas da OWASP para o tratamento dos dados, através de ferramentas disponibilizadas pela própria linguagem, como por exemplo, no caso de tratar dados utilizados em comandos SQL, a extensão PDO. (OWASP, 2012A). Para atingir a segurança da aplicação com relação ao fluxo de dados, serão apresentadas algumas técnicas para os tratamentos destes. A empregabilidade correta destas técnicas de tratamento irá garantir uma transição de dados seguras para as diferentes partes da aplicação TRATAMENTO DE DADOS Uma das falhas mais comuns relacionada às aplicações WEB é a falta de uma validação apropriada para os dados que são passados para aplicação, seja através do usuário 27 Cross-Site Scripting - Conhecido também como XSS 28

29 ou de outra fonte externa. Esta falha resulta em diversas vulnerabilidades da aplicação, como por exemplo, injeção de código malicioso. Para assegurar os dados passados para aplicações e evitar as vulnerabilidades, foram definidos três tipos de testes: (OWASP, 2009). Integridade: Assegurar que não houve violação dos dados. Validação: Assegurar que os dados possuem uma sintaxe correta, com delimitações de largura, e que contenham apenas caracteres permitidos pela aplicação. Regras de negócio: Assegurar que as regras de negócio são sempre respeitadas. Para evitar a perda de integridade dos dados, sempre devem ser feitos testes no momento que os dados são passados de uma fonte confiável para uma menos confiável, como por exemplo, quando é passado o dado de um aplicativo externo para um campo oculto dentro do HTML. Se for necessária a utilização deste tipo de campo para o armazenamento de algum dado, existem algumas regras a serem seguidas (OWASP, 2009): Dados confidenciais nunca devem ser passados sem alguma codificação. Os campos ocultos devem sempre ser testados com relação a sua integridade, e é recomendada a utilização de algum algoritmo de codificação. Os dados codificados devem possuir um mecanismo de proteção contra os ataques de repetição 28. Dados enviados para o usuário devem sempre ser validados pelo servidor. Isto evita o ataque de repetição. A utilização do campo oculto é arriscada, e deve-se buscar não utilizá-la para a manutenção dos dados. Porém, caso a solução exija a utilização, é necessário o seguimento das normas listadas, devido ao fato do campo oculto ser facilmente acessado pelos navegadores. Através da utilização da ferramenta de exibição do código fonte HTML, que é público, é possível a visualização dos dados que estão contidos nos campos, inclusive o oculto, exigindo então a proteção dos mesmos TIPOS DE DADOS Os tipos de dados no PHP são similares a outras linguagens, como por exemplo: Java, C ou Delphi, porém, na linguagem PHP não é necessário e nem suportado, especificar o 28 Ataques de repetição Ataque onde o intruso envia um dado codificado enviado previamente para obter algum acesso não autorizado. 29

30 tipo na declaração da variável, caracterizando o PHP como uma linguagem fracamente tipada. Isto é: o tipo de dado de uma variável é definido em tempo de execução da aplicação. São oito os tipos de dados suportados pelo PHP: integers, booleans, float, string, array, object, null, que estão descritos na tabela 2. (MELO, DE E NASCIMENTO, 2007) Tipo Faixa de Valores Aplicação Boolean True ou False Utilizado para realizar operações lógicas. Ex: $flag = true; Integer a Utilizado para armazenar dados do tipo inteiro, como por exemplo, a idade de uma pessoa. Deve-se atentar para não armazenar valores dos bancos de dados que possam ocasionar estouro da capacidade do tipo(overflow). Ex: $idade = 25; Float 1.40 E-45 a 3.40 E+38 Tipo de dado utilizado no caso de necessidade de precisão decimal. Deve-se atentar para erros causados por comparações de igualdade, devido ao número de casas decimais. Ex: $valor = 25.50; String Não possui Utilizado para armazenar uma cadeia de caracteres. Ex: $cidade = Joinville ; Array Não possui Utilizado para uma cadeia de tipos heterogêneos. Utiliza-se uma chave e o valor correspondente. A chave pode ser uma string ou um integer. Ex: $valores = array(1 => 90, required => false); Object Não possui É a instância de uma classe. Ex: $funcionario = new Funcionario(); Null Não possui Representa a ausência de um valor para uma variável. 30

31 Resource Não possui Ex: $iteracao = null; Armazena uma referência para funções, bancos de dados, arquivos que estejam fora do PHP. (MACINTYRE, 2010) Tabela 2: Tipos de variáveis PHP. Fonte: MELO, DE E NASCIMENTO (2007, p.52). Outro ponto importante relacionado à leitura do código é a nomenclatura utilizada para a definição das variáveis. Como descrito no Capítulo 1, seção , deve-se utilizar nomes que identifiquem a utilização da variável através do padrão studlycaps. Tratando também da manutenção do código, é importante sempre utilizar a variável para o mesmo propósito de criação. Uma vez que ela seja do tipo integer, se for necessária uma variável do tipo float, é recomendável a criação de uma nova variável, ao invés da utilização da mesma (MACINTYRE, 2010). Para a utilização de variáveis constantes, existem 2 modos distintos para a interpretação do PHP. O primeiro é a utilização da função nativa do PHP, define, que definirá a constante em tempo de execução, em um escopo global, e permite a presença de expressões lógicas no nome da constante e no valor. Já o segundo modo, é a utilização da palavra reservada const, que define a variável em tempo de compilação, causando erros de compilação em caso de haver mais de uma definição da constante. Para a maioria dos casos é recomendável a utilização do modo define, uma vez que este é mais flexível. Porém, em casos no qual a aplicação é um sistema extremamente custoso, e necessite de otimização, ou maior controle de leitura de código ou constantes de classes, é recomendável a utilização do const. (CABAL, 2013) No caso da necessidade de uma variável global no PHP, deve-se declarar fora do escopo de classes e funções, e caso ela seja usada dentro de algum destes escopos, existe a palavra reservada global, que identificará para o PHP que a variável a ser utilizada é a definida anteriormente, no escopo global do script(melo, DE E NASCIMENTO, 2007). Outro ponto importante a ser destacado: é que no PHP existem variáveis que são interagidas com entidades externas do script. São denominadas como superglobais e estão classificadas na tabela 3 (PHP, 2013d). $GLOBALS Contém referência para todas as variáveis do escopo global do script. $_SERVER Variáveis definidas no servidor no qual o PHP é executado. 31

32 $_GET $_POST $_FILES $_COOKIE $_SESSION $_REQUEST $_ENV Variáveis enviadas via método HTTP GET. Variáveis enviadas via método HTTP POST. Variáveis enviadas via upload de formulários. Variáveis armazenadas em cookies navegador. Variáveis da sessão aberta. Tabela 3: Superglobais PHP. FONTE: (PHP, 2013d) do Variáveis contidas em $_GET, $_POST, e $_COOKIE. Variáveis do ambiente de execução. A dinamicidade do PHP em tratar os dados pode ser considerada uma vantagem quando está sendo utilizada por desenvolvedores que atentem os cuidados necessários para a validação destes dados. Da mesma forma que existe a facilidade para a criação e utilização de dados, deve-se levar em conta a facilidade que o atacante tem de alterar estes mesmos dados, sem se preocupar com tipos. Por este motivo, a importância da utilização das normas OWASP para validação dos tipos de dados citada na parte de tratamento de dados, através de técnicas de programação TECNICAS DE PROGRAMAÇÃO A flexibilidade do PHP pode ser usada de forma inadequada por usuários mal intencionados e proporcionar vulnerabilidades no servidor. Com algumas técnicas de programação minimizam-se essas vulnerabilidades. (WINAND, 2002). Como um dos problemas de segurança mais encontrados dentro das aplicações WEB, destaca-se o ataque em cima de trechos de códigos PHP que manipulam os dados da SQL, através da injeção de um comando SQL do atacante. Conhecidos como SQL Injection, esses ataques ocorrem justamente pela facilidade do acesso a aplicações WEB, e o fato dos bancos de dados armazenarem informações valiosas para os atacantes (WASSERMANN; SU, 2007). Para evitar estes ataques, deve ser feito o tratamento do código fraco para evitar a entrada de dados através da manipulação do atacante. Por exemplo, no código 9, o atacante utiliza o comando GET para enviar dados para a página no servidor. 29 Cookie Um dado que é armazenado a partir de um site, no navegador do usuário. 30 Disponível em: < Acesso em 18/maio de

33 Código 9: Exemplo de código vulnerável para o SQL Injection. Fonte: (WASSERMANN; SU, 2007). Dentro do código, é possível verificar que o GET é validado para ser um número inteiro (linha 2), e depois concatenado no comando SQL (linha 19 e 20), que irá buscar um usuário válido na base de dados. Apesar de existir uma validação numérica para o GET, ela não será suficiente para impedir o atacante de injetar um código SQL. Se o atacante definir o GET como 1; DROP TABLE unp_user., será efetuada a exclusão de todos os usuários da base de dados (WASSERMANN; SU, 2007). As técnicas de programação são muito importantes para reduzir as vulnerabilidades do sistema, como o SQL Injection. Para dificultar o acesso de "atacantes" a aplicações WEB, o tratamento de dados deve ser feito, com isso os pontos fracos do código serão reduzidos. Visando evitar esses ataques, atualmente existem algumas normas para a prevenção da injeção de código malicioso (OWASP, 2013B): Validação da entrada de dados: usar um mecanismo padrão para validar os dados que serão passados de algum formulário ou mesmo de outra forma, para o comando SQL que será executado. Validar o tamanho do comprimento dos dados passados, regras de negócio, sintaxe, tipo antes de passar esses dados para a execução. Definir privilégios baixos para os usuários para a conexão com o banco de 33

34 dados. Evitar informações nas mensagens de erros que possam ajudar o atacante. Utilização de prepared statements. Utilização de stored procedures. Utilizar técnicas para filtrar os caracteres especiais. Com relação às normas, ocorrem no processo de desenvolvimento da aplicação, como a validação de dados e a definição de privilégios. Para os três últimos casos, existem ferramentas prontas em PHP para a utilização do desenvolvedor, através da extensão PDO 31. Essas ferramentas auxiliam o programador no controle das vulnerabilidades. A técnica de prepared statements ou parameterized queries, consiste em utilizar consultas pré-montadas, através da substituição das variáveis de controle por um marcador. Ou seja, essa técnica força o desenvolvedor a inicialmente definir todo o código SQL que será utilizado, e só depois serão passados os parâmetros, um por um. Desta forma, o banco de dados consegue distinguir a diferença entre o código SQL e os dados que são passados para ele, assegurando que o atacante não conseguirá alterar o código SQL original (OWASP, 2012A). Dentro da linguagem PHP, existe a extensão PDO, para a utilização desta técnica com o método bindvalue, utilizado no código 10. Código 10: Exemplo de utilização do prepared statement. Fonte: Elaborado pelo autor. 31 PHP Data Objects Extensão para PHP, para prover uma interface para acesso do banco de dados. Funciona apenas a partir da versão

35 No exemplo do código 10 foi utilizada a extensão PDO para PHP, linha 8. Para preparar o comando SQL, é necessário montar sua estrutura, substituir no lugar de utilização das variáveis o marcador?, e enviar o comando com sua estrutura lógica preparada para o método pdo::prepare,linha 8. Para enviar os parâmetros que serão utilizados na SQL é utilizado método pdo::bindvalue, como pode-se observar na linha 15. Outra técnica citada, stored procedures, tem o funcionamento similar da técnica anterior, prepared statements, a diferença dentro da lógica dela é que o código SQL prédefinido, é armazenado dentro do próprio banco de dados, e então chamado pela aplicação. Ou seja, é necessário por parte do desenvolvedor, criar o código dentro do banco de dados específico utilizado pela aplicação, e então chamar esta aplicação. Podemos ver um exemplo da técnica stored procedures no código 11 (OWASP, 2012A). Código 11: Exemplo de Stored procedures no PHP. Fonte: Adaptado do site oficial do PHP 32. A técnica apresentada na código 11 demonstra a criação de procedures, códigos previamente definidos na base de dados, como visto na linha 12. Após a criação destes, chama-se pelo PHP a execução do comando CALL procedure, linha 16, para a execução do código criado passando como parâmetro um inteiro. Grande parte das aplicações WEB utiliza a combinação PHP com SQL, para manipulação dos dados da aplicação (OWASP, 2012A). Observa-se que grande parte das 32 Disponível em: < Acesso em 20/maio de

36 falhas existentes nas aplicações é a falta de preocupação no processo de desenvolvimento PHP juntamente com o SQL para a manipulação das informações. Portanto, Após a compreensão das técnicas utilizadas no PHP, é necessário entender a linguagem SQL e suas propriedades, dentre elas: operações básicas, tipos de dados da tabela e utilização dinâmica de queries SQL no PHP. 3.2 SQL Como visto no Capitulo 1, o SQL é uma linguagem criada em cima de uma lógica relacional matemática, e isso reflete em como são buscados os dados dentro da aplicação. O grande poder da linguagem vem justamente da capacidade de buscar dados de várias tabelas respeitando alguma relação entre elas ou alguma operação matemática (IBM, 2013). Através destas operações de lógica de conjuntos, é possível incluir, alterar, remover ou buscar dados, de acordo com a necessidade do desenvolvimento. E isso tudo é possível devido a possibilidade de incorporar o código SQL dentro da aplicação PHP (MICROSOFT, 2013). No entanto, pode-se verificar que grande parte dos problemas relatados as falhas da aplicação WEB neste trabalho são justamente a falta de tratamento adequado, através das operações SQL utilizadas na aplicação. As operações em si são simples, tornando flexíveis para o atacante manipular de acordo com sua vontade, se não houverem as validações anteriormente citadas. O SQL tem papel fundamental no bom funcionamento das aplicações. A combinação com o PHP juntamente com o tratamento de dados, faz com que o programa fique mais seguro, deixando o usuário longe de riscos. Esta é uma linguagem eficiente para executar requisições, inserir, atualizar e excluir registros. As definições mais importantes são: INSERT, DELETE, UPDATE, SELECT e DROP. Para compreender e analisar como devem ser feitas as validações, é necessário verificar estas operações básicas do SQL. As mesmas são comumente usadas nas aplicações e a partir do seu entendimento, podem-se antecipar possíveis comandos que o atacante irá tentar executar para obter ou manipular informações OPERAÇÕES BÁSICAS Os programas do SQL funcionam através da utilização de dados lógicos. Ou seja, é 36

37 utilizada a teoria dos conjuntos em todos os comandos SQL: SELECT, INSERT, UPDATE e DELETE. Com isso, os dados são relacionados através de conjuntos que dentro da aplicação são as tabelas. (KLINE, 2010). Devido a esta flexibilidade da linguagem SQL para seleção dos dados, ela encaixa na necessidade das aplicações WEB, para o retorno, manipulação e inserção dos dados da aplicação. É valido reforçar o ponto que, através desta flexibilidade da linguagem, é importante a utilização de validações por parte do desenvolvedor. Na seção até a seção as principais operações do SQL são mostradas, a realização da inserção, a remoção, a atualização e a seleção de dados em SQL INSERT O comando INSERT é utilizado para adicionar registros na tabela de um determinado banco de dados, uma partição de uma tabela particionada ou uma sub-partição, ou uma tabelaobjeto. Para conseguir executar o comando, o desenvolvedor deve possuir privilégios do comando. O valor de retorno do comando é o número de registros afetados pelo comando, ou uma mensagem de erro. Podemos identificar no Código 12 como é feita a declaração do comando INSERT (ORACLE, 2013): Código 12: Exemplo do comando INSERT Como pode ser observado no Código 12, o comando INSERT inseriu na tabela agenda o nome Ricardo Olivo e o número Neste exemplo dois valores foram inseridos nas colunas nome e número definido na tabela agenda DELETE O comando DELETE é utilizado para remover registros de um tabela. Pode remover registros de uma tabela ou de uma tabela particionada. Para o comando ser executado, o 37

38 desenvolvedor deve possuir permissões para o comando DELETE, dentro do banco de dados. Pode-se observar a sintaxe do comando no código 13 (ORACLE, 2013). Código 13: Exemplo do comando DELETE No código 13 é exemplificado como é realizada a remoção dos dados de uma tabela, nesta instrução somente os registros das tabelas são removidos, mantendo a tabela em questão. Para exclusão do registro, na linha 1 é necessário informar o nome da tabela em nome_tabela e, conforme informado a linha 2, é feita a inclusão de uma cláusula WHERE, necessária para que a exclusão obedeça as condições impostas pela própria cláusula UPDATE O comando UPDATE tem como finalidade alterar valores de campos já existentes na tabela. Assim como nos outros comandos, é necessário ter permissão para utilizar esse comando, configurada dentro da base de dados. Sua sintaxe funciona como demonstrada no Código 14 (DATABASE LANGUAGE SQL, 1992). Código 14: Exemplo do comando UPDATE. Fonte: Elaborado pelo autor. No código 14 encontra-se uma demonstração de como é realizado o comando UPDATE em uma tabela no banco de dados. Através desta instrução, somente os campos que atendam a condição definida na clausula WHERE serão atualizados. Para alteração dos registros em uma tabela é necessário definir o nome da tabela que será modificada (Linha 1) em nome_tabela, a coluna ao qual terá o seu valor alterado (Linha 2) em CAMPO, seguido do novo valor e a cláusula WHERE (Linha 3) necessária para que a alteração obedeça as condições impostas na Linha 4. 38

39 DROP O comando DROP serve o propósito de excluir uma tabela, uma constante ou um esquema. É possível também utilizar o comando DROP CASCADE, que irá remover adicionalmente todos os objetos dependentes da tabela. A sintaxe dele pode ser visualizada no código 15 (ORACLE, 2013). Código 15: Comando DROP. Fonte: (DATABASE LANGUAGE SQL, 1992). p. 291 O primeiro exemplo do código é o comando DROP, aninhado dentro do comando ALTER (Linha 3). Através deste comando, a constraint 33 TNC2 da tabela T2, será removida, juntamente com todos os objetos que são dependentes dela. O próximo comando (Linha 5), é utilizado para remover a tabela da base de dados, podendo ser utilizado o CASCADE para remover seus dependentes SELECT A clausula SELECT corresponde a uma operação matemática relacional. Conforme a condição descrita após a clausula WHERE o banco de dados da aplicação irá buscar os valores que respeitam o relacionamento especificado. Também são utilizados o FROM e o JOIN para criar as relações. O asterisco pode ser usado para buscar todos os campos da tabela, como no exemplo do código 16(DATABASE LANGUAGE SQL, 1992). Código 16: Exemplo do comando SELECT 33 Restrição da tabela 39

40 No Código 16 demonstra-se o comando SELECT na base de dados, realizando a seleção de todas as colunas pertencentes a uma tabela específica. Para execução da consulta é necessário à definição das colunas (Linha 1) em *, selecionando todos os atributos da tabela denominada nome_tabela. Na Linha 2, define-se a cláusula WHERE, necessária para que a consulta obedeça às instruções, neste exemplo, a consulta trará somente os registros que a coluna chamada nome_coluna for igual a zero. O comando SELECT, através da busca de informações através das relações das tabelas que existem em algum banco, pode se tornar um comando bastante complexo. Além de comandos, nele podem ser utilizadas funções, operandos, subcomandos e cláusulas não obrigatórias. A utilização dele em aplicações WEB é bastante comum, principalmente em momentos onde é necessária a busca de uma validação, ou alguma informação TIPO DE DADOS DA TABELA Em SQL, os dados podem ser armazenados em diferentes tipos de estruturas, como observado na tabela 4, o tipo define as operações que poder ser executadas com determinado dado. Os tipos no SQL são (PATRICK, 2002): Inteiros: integer, int, smallint e tinyint; Reais: float, double, real, numeric; Caracteres: char; Texto: varchar, text; Data: date. Tipo de Dados Longitude Descrição BINARY 1 byte Para consultas sobre tabela anexa de produtos de banco de dados que definem um tipo de dados Binário. BIT 1 byte Valores Sim/Não ou True/False BYTE 1 byte Um valor inteiro entre 0 e 255. COUNTER 4 bytes Um número incrementado automaticamente (de tipo Long) 40

41 CURRENCY 8 bytes Um inteiro escalável entre ,5808 e ,5807. DATETIME 8 bytes Um valor de data ou hora entre os anos 100 e SINGLE DOUBLE 4 bytes 8 bytes Um valor em ponto flutuante de precisão simples com uma classificação de *1038 a *10-45 para valores negativos, *10-45 a *1038 para valores positivos, e 0. Um valor em ponto flutuante de dupla precisão com uma classificação de *10308 a * para valores negativos, * a *10308 para valores positivos, e 0. SHORT 2 bytes Um inteiro curto entre -32,768 e 32,767. LONG 4 bytes Um inteiro longo entre -2,147,483,648 e 2,147,483,647. LONGTEXT LONGBINARY TEXT 1 byte por caractere Segundo se necessite 1 byte por caractere De zero a um máximo de 1.2 gigabytes. De zero 1 gigabyte. Utilizado para objetos OLE. De zero a 255 caracteres. Tabela 4: Tipos de dados em SQL Fonte: (PATRICK, 2002) Como listado na Tabela 4, os tipos de dados em SQL são separados em cinco grupos: Inteiros, reais, caracteres, texto e data. Cada um desses tipos tem uma longitude, que nada mais é que o número de bytes ocupado pelo tipo UTILIZAÇÃO DINÂMICA DE QUERIES SQL A utilização dinâmica de queries SQL é uma técnica para gerar e executar comandos SQL em tempo de execução. É útil quando codifica-se programas de uso flexível, como 41

42 sistemas de consulta ad hoc 34, ou seja, programas que devem ser executados em tempos de execução, como por exemplo instruções de definição de dados (DDL), ou em casos que não é possível prever em tempo de compilação o texto completo de um comando SQL (ORACLE, 2013). Pode ocorrer também no uso desta técnica a vulnerabilidade do SQL Injection. Um caso menos conhecido é a utilização da sessão NLS 35, no caso do Oracle, conforme exemplo visualizado no Código 17. NLS é utilizado para configurar uma série de dados, utilizados para formatação de data, hora, números e moeda (ORACLE, 2013). Código 17: Utilização dinâmica de queries SQL. Fonte: Adaptado de (ORACLE, 2013) 36 Como observado no Código 17, através do SYSDATE(Linha 19), existe uma vulnerabilidade, devido ao fato do atacante conseguir mudar o valor da variável através da sessão NLS, com um simples comando: ALTER SESSION SET NLS_DATE_FORMAT='"'' OR service_type=''merger"';(oracle, 2013). O conceito de utilização dinâmica de queries em SQL é uma ferramenta que torna o desenvolvimento flexível, mas isso pode gerar uma queda de desempenho. Por outro lado, 34 Na programação o significado é um código que execute diferentes funcionalidades, sem uma estruturação prédefinida. 35 National Language Support 36 Disponível em: < Acesso em 16/junho de

43 com a utilização dinâmica de queries, o código fica muito mais claro e organizado, reduzindo o tempo de manutenção do código por parte do programador. 3.3 HTML O HTML é uma aplicação SGML 37, conforme o padrão internacional ISO 8879, e é utilizado para demonstrar informações através do navegador WEB (W3C, 2013). A estrutura da HTML foi definida na RFC 2616, referenciada neste trabalho, e é utilizada para demonstrar informações na WEB desde 1990 (FIELDING ET AL., 1999). A exibição destes dados é feita através de tagsets, que podem definir diferentes estruturas para a demonstração dos dados. É recomendável que todo o código HTML seja codificado, já evitando algumas vulnerabilidades relacionadas ao ataque XSS. Ou seja, caracteres especiais, utilizados para a definição das tagsets, podem facilitar a inserção de scripts na aplicação (OWASP, 2013B). O HTML é um código visível por navegadores, ou seja, o usuário final tem acesso as informações que estão contidas no código HTML. É necessário dificultar o acesso, através das recomendações da OWASP, utilizando técnicas para codificar o código da aplicação. Através desses cuidados, são escondidos alguns dados que não devem ser visualizados. Neste trabalho, o escopo está concentrado na segurança da utilização do PHP com o SQL. Grande parte destes dados é enviada via formulário da aplicação utilizando técnicas GET e POST através da linguagem PHP. Devido a este fato, é necessário o estudo dos tipos de formulário HTML, para a compreensão dos ataques possíveis TIPOS DE FORMULÁRIO Um formulário HTTP é feito para uma troca de informações do usuário com a aplicação. Através dele, podem ser usados campos para preenchimento, botões, checkbox, bem como outras formas de reter alguma informação para a aplicação. A Figura 2 mostra um exemplo de formulário HTML. 37 SGML Standart Generalized Markup Language 43

44 Figura 2: Exemplo de um formulário de login. Fonte: Elaborado pelo autor Na Figura 2 é possível observar um exemplo de formulário simples, com uma caixa de texto e uma caixa de senha. Após o usuário digitar os dados, as informações serão validadas através do PHP, e em seguida deverão ser enviadas ao bando de dados da aplicação. (OWASP, 2009B). A troca de informações entre o cliente e o servidor, através dos formulários ou mesmo utilizando outra funcionalidade, pode ser feita de duas formas: através do método GET, ou o método POST. Existem diferenças entre os dois métodos, mas ambos fornecem a comunicação eficaz entre o lado cliente e servidor (W3C, 2013). Para entender a troca de informações é necessário então, estudar os dois métodos em particular. Esta parte da aplicação está associada com a necessidade de validar as informações passadas, seguindo as normas da OWASP, bem como a análise da utilização dos métodos para diferentes situações METODOS GET Para requisitar dados do servidor, foi criado o método GET. Através dele, a requisição dos dados é enviada pela URL do navegador, após o caractere? e então separa-se 44