universidade do estado de santa catarina centro … · 7 1. introduÇÃo ao longo do processo do...
TRANSCRIPT
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
2013
2
LISTA DE ILUSTRAÇÕES
Figura 1: Linha do tempo da linguagem PHP. ......................................................................... 12
Figura 2: Exemplo de um formulário de login. Fonte: Elaborado pelo autor .......................... 44 Figura 3: Processo padrão de fluxo dos dados da aplicação WEB ........................................... 48
3
LISTA DE TABELAS
TABELA 1: ESTATÍSTICAS DOS ERROS PHP ENCONTRADOS NA WEB FONTE:
ADAPTADO DO NVD( NATIONAL VULNERABILITY DATABASE)................................... 26
TABELA 2: TIPOS DE VARIÁVEIS PHP. FONTE: MELO, DE E NASCIMENTO (2007,
P.52). ......................................................................................................................................... 31
TABELA 3: SUPERGLOBAIS PHP. FONTE: (PHP, 2013D) ............................................... 32
TABELA 4: TIPOS DE DADOS EM SQL FONTE: (PATRICK, 2002) ................................ 41
4
LISTA DE CÓDIGOS
Código 1: Exemplo de código respeitando as normas. Fonte: (PEAR, 2013c). ....................... 18 Código 2: Exemplo da norma para estruturas de controle com testes lógicos longos. Fonte:
(PEAR, 2013c). ........................................................................................................................ 18 Código 3: Exemplo da divisão das condições por variáveis. Fonte: (PEAR, 2013c). ............. 19 Código 4: Exemplo da divisão das condições ternárias. Fonte: (PEAR, 2013c). .................... 19 Código 5: Exemplo de alinhamento entre as funções. Fonte: (PEAR, 2013d). ....................... 20 Código 6: Exemplo do alinhamento entre as igualdades. Fonte: (PEAR, 2013D). .................. 20
Código 7: Exemplo da disposição da definição da função. Fonte; (PEAR, 2013F). ............... 21 Código 8: Exemplo dos comentários de cabeçalho. Fonte: (PEAR, 2013l). ............................ 23 Código 9: Exemplo de código vulnerável para o SQL Injection. Fonte: (WASSERMANN;
SU, 2007). ................................................................................................................................. 33 Código 10: Exemplo de utilização do prepared statement. Fonte: Elaborado pelo autor. ....... 34
Código 11: Exemplo de Stored procedures no PHP. Fonte: Adaptado do site oficial do PHP.
.................................................................................................................................................. 35
Código 12: Exemplo do comando INSERT ............................................................................. 37 Código 13: Exemplo do comando DELETE ............................................................................ 38 Código 14: Exemplo do comando UPDATE. Fonte: Elaborado pelo autor. ............................ 38 Código 15: Comando DROP. Fonte: (DATABASE LANGUAGE SQL, 1992). p. 291 ........ 39
Código 16: Exemplo do comando SELECT............................................................................. 39 Código 17: Utilização dinâmica de queries SQL. Fonte: Adaptado de (ORACLE, 2013) ...... 42
Código 18: Utilização da Whitelist Fonte: OWASP,2009 ........................................................ 50 Código 19: Exemplo SQL Injection Fonte: (PHP, 2013c) ....................................................... 52 Código 20: Exemplo Cross Site Scripting Fonte: (OWASP, 2013B) ...................................... 54
5
SUMÁRIO
LISTA DE ILUSTRAÇÕES .................................................................................................... 2
LISTA DE TABELAS .............................................................................................................. 3
LISTA DE CÓDIGOS .............................................................................................................. 4
1. INTRODUÇÃO ................................................................................................................. 7
2. CONCEITOS ..................................................................................................................... 9
2.1 DEFINIÇÃO DE PROGRAMAÇÃO WEB ............................................................ 9
2.2 HISTÓRICO DA LINGUAGEM PHP E SQL ..................................................... 10
2.2.1 PHP .................................................................................................................... 10
2.2.2 SQL .................................................................................................................... 12
2.3 PROGRAMAÇÃO SEGURA ................................................................................. 13
2.3.1 NORMAS .......................................................................................................... 14
2.3.2 GUIA DE BOAS PRÁTICAS .......................................................................... 16
2.3.2.1 Identação e comprimento da linha .............................................................. 17
2.3.2.2 Estruturas de controle .................................................................................. 17
2.3.2.3 Chamadas de funções ................................................................................... 19
2.3.2.4 Definições de classes ...................................................................................... 21
2.3.2.5 Definições de funções .................................................................................... 21
2.3.2.6 Arrays ............................................................................................................. 22
2.3.2.7 Comentários .................................................................................................. 22
2.3.2.8 Código de inclusão ........................................................................................ 22
2.3.2.9 Tags de código PHP ...................................................................................... 22
2.3.2.10 Bloco de comentários no cabeçalho ............................................................. 22
2.3.2.11 Convenção de nomenclatura ........................................................................ 23
2.3.2.12 Formato de arquivos ..................................................................................... 24
2.4 CONTEXTUALIZAÇÃO PHP E SQL .................................................................. 24
2.5 CONSIDERAÇÕES PARCIAIS ............................................................................ 27
3. ESTUDO DAS FERRAMENTAS ................................................................................. 28
3.1 PHP ........................................................................................................................... 28
3.1.1 TRATAMENTO DE DADOS ......................................................................... 28
3.1.2 TIPOS DE DADOS ........................................................................................... 29
3.1.3 TECNICAS DE PROGRAMAÇÃO ............................................................... 32
3.2 SQL ........................................................................................................................... 36
3.2.1 OPERAÇÕES BÁSICAS ................................................................................. 36
6
3.2.1.1 INSERT .......................................................................................................... 37
3.2.1.2 DELETE ........................................................................................................ 37
3.2.1.3 UPDATE ........................................................................................................ 38
3.2.1.4 DROP ............................................................................................................. 39
3.2.1.5 SELECT ......................................................................................................... 39
3.2.2 TIPO DE DADOS DA TABELA ..................................................................... 40
3.2.3 UTILIZAÇÃO DINÂMICA DE QUERIES SQL .......................................... 41
3.3 HTML ....................................................................................................................... 43
3.3.1 TIPOS DE FORMULÁRIO ............................................................................ 43
3.3.2 METODOS GET .............................................................................................. 44
3.3.3 MÉTODOS POST ............................................................................................ 46
3.4. CONSIDERAÇÕES PARCIAIS ................................................................................ 47
4. ANÁLISE ......................................................................................................................... 48
4.1 Tipos de Dados ......................................................................................................... 49
4.2 Tratamento de dados ............................................................................................... 49
4.2.1 Whitelist ............................................................................................................. 50
4.2.2 Blacklist .............................................................................................................. 51
4.2.3 Sanitize ............................................................................................................... 51
4.3 SQL Injection ............................................................................................................ 52
4.4 Restrições de HTML ................................................................................................ 53
4.4.1 Cross Site Scripting ........................................................................................... 53
4.5. Considerações Parciais ................................................................................................ 55
5. CONSIDERAÇÕES FINAIS ......................................................................................... 56
REFERÊNCIAS ..................................................................................................................... 58
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
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.
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 IDS1/IPS
2. Os atacantes então, ao invés de atacarem
estas redes mais protegidas, passaram a atacar computadores individuais através da WEB3,
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 4e 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
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.
2.2.1 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 50.000 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
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 2004. Também foram lançadas algumas outras funcionalidades, como melhoria de
suporte a XML6, 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
12
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.
2.2.2 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 SEQUEL9, o qual mais tarde viria
a ser rebatizado de SQL10
. 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 1974.
Era um trabalho em testes e, portanto, não utilizado comercialmente (Chamberlin et al., 2008
9 Structured English Query Language – Uma das primeiras versões do SQL.
10 Structured Query Language – Nome utilizado atualmente para a linguagem de dados relacional.
1995 - Criação da primeira
versão do PHP/FI
1997 - Lançada a segunda
versão do PHP/FI
1997- Lançada a
versão PHP 3.0
1998 - PHP 3.0 utilizada por 10% dos servidores
1999 - Desenvolvida a Zend Engine
2000 - A partir da
Zend Engine, foi lançada a versão PHP
4.0
2004 - PHP 5.0 lançado juntamente com o Zend
2.0
13
apud VOGT, 2008). Logo após a criação do SEQUEL, a Oracle iniciou o desenvolvimento
da aplicação RDBMS11
, 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.
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 OWASP12
, 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.
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.
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 PDO13
(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 e-mail, em determinada
variável, é necessário algum mecanismo para validar se o usuário está passando, de fato, um
e-mail.
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.
2.3.2 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 1999. 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.
17
Normas para o desenvolvimento em PHP;
A PECL15
, 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 krb516
, ou ferramentas para
codificação do código, como o BLENC17
. 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:
2.3.2.1 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 diffs18
, patches19
, histórico na SVN20
, 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).
2.3.2.2 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.
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).
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ários21
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.
2.3.2.3 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.
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.
21
2.3.2.4 Definições de classes
A única norma, é que a chave para iniciar classe deve constar em uma nova
linha(PEAR, 2013e).
2.3.2.5 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
Style22
, 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”
22
2.3.2.6 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).
2.3.2.7 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).
2.3.2.8 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).
2.3.2.9 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).
2.3.2.10 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).
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.
2.3.2.11 Convenção de nomenclatura
Se for necessário a definição de variáveis globais, seus nomes devem começar com um
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
caps23
, 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.
2.3.2.12 Formato de arquivos
Devem ser utilizados o ISO-8859-1 ou UTF-8 para codificação dos caracteres. Utilizar
o Unix formating, ou seja, as linhas devem terminar com o line feed24
. 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
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 namespace25
nas versões
anteriores a versão 5.3.0 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.
26
Ano
Total de
vulnerabilidades Porcentual dentro da WEB
1999 156 17.45
2000 395 38.73
2001 1065 63.51
2002 1596 74.03
2003 474 31.04
2004 638 26.03
2005 1617 32.79
2006 3333 50.44
2007 3101 47.61
2008 2481 44.05
2009 2320 40.47
2010 1254 27.03
2011 901 21.71
2012 1018 19.25
2013 148 7.62 Tabela 1: Estatísticas dos erros PHP encontrados na WEB
Fonte: Adaptado do NVD26( 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: < http://web.nvd.nist.gov/view/vuln/statistics-
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 2013.
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.
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 Scripting27
(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.
3.1.1 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
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ção28
.
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.
3.1.2 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.
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 -2.147.483.648 a 2.147.483.647 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.
31
Ex: $iteracao = null;
Resource Não possui 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 1.3.2.11, 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.
32
$_GET Variáveis enviadas via método HTTP GET.
$_POST Variáveis enviadas via método HTTP POST.
$_FILES Variáveis enviadas via upload de formulários.
$_COOKIE Variáveis armazenadas em cookies 29
do
navegador.
$_SESSION Variáveis da sessão aberta.
$_REQUEST Variáveis contidas em $_GET, $_POST, e
$_COOKIE.
$_ENV Variáveis do ambiente de execução.
Tabela 3: Superglobais PHP. FONTE: (PHP, 2013d)30
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.
3.1.3 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: <http://php.net/manual/en/language.variables.superglobals.php>. Acesso em 18/maio de 2013.
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
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 PDO31
.
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 5.0
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 PHP32.
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: < http://php.net/manual/en/mysqli.quickstart.statements.php>. Acesso em 20/maio de 2013.
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.
3.2.1 OPERAÇÕES BÁSICAS
Os programas do SQL funcionam através da utilização de dados lógicos. Ou seja, é
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 2.2.1.1 até a seção
2.2.1.5 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.
3.2.1.1 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 tabela-
objeto. 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 9921-1234. Neste exemplo dois valores foram
inseridos nas colunas nome e número definido na tabela agenda.
3.2.1.2 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
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.
3.2.1.3 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.
39
3.2.1.4 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.
3.2.1.5 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
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.
3.2.2 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)
41
CURRENCY 8 bytes Um inteiro escalável entre 922.337.203.685.477,5808 e
922.337.203.685.477,5807.
DATETIME 8 bytes Um valor de data ou hora entre os anos 100 e 9999.
SINGLE 4 bytes
Um valor em ponto flutuante de precisão simples com
uma classificação de - 3.402823*1038 a -1.401298*10-
45 para valores negativos, 1.401298*10- 45 a
3.402823*1038 para valores positivos, e 0.
DOUBLE 8 bytes
Um valor em ponto flutuante de dupla precisão com uma
classificação de - 1.79769313486232*10308 a -
4.94065645841247*10-324 para valores negativos,
4.94065645841247*10-324 a 1.79769313486232*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 1 byte por
caractere De zero a um máximo de 1.2 gigabytes.
LONGBINARY Segundo se
necessite De zero 1 gigabyte. Utilizado para objetos OLE.
TEXT 1 byte por
caractere 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.
3.2.3 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
42
sistemas de consulta ad hoc34
, 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 NLS35
, 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: < http://docs.oracle.com/cd/E11882_01/appdev.112/e10472/dynamic.htm>. Acesso em
16/junho de 2013.
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 SGML37
, 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.
3.3.1 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
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.
3.3.2 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
45
as variáveis através do “&”. Algumas características são inerentes deste método:
(W3SCHOOLS, 2013A)
Solicitações GET podem ser armazenadas em cache.
Solicitações GET permanecem no histórico do navegador.
Solicitações GET podem ser marcadas.
Solicitação GET nunca deve ser usada quando se lida com dados sensíveis.
Solicitações GET possuem restrições de comprimento.
Solicitação GET deve ser utilizada apenas para recuperação de dados.
Pode-se concluir que o método GET possui funcionalidade para manipulação de
dados relacionados à navegação, que tornem a página mais dinâmica. Mas existem alguns
cuidados relacionados à validação destes dados que devem ser observados, principalmente
quando são informações internas da aplicação ou do usuário. Existem alguns problemas que
ocorrem devido a exibição dos dados utilizados através do método GET (OWASP, 2012B) :
Devido à visualização dos dados através da URL, são facilmente manipuláveis
em comparação com outros métodos de transmissão dos dados.
É mais provável que ocorra um ataque de XSS, através da execução de uma
URL feita para a vítima.
Apesar da visualização dos dados, é necessário ressaltar que a utilização destes para
o intuito navegação não afeta a segurança, desde que estes sejam validados e não possuam
nenhuma interação com funcionalidades que manipulem o banco. Para esse objetivo, é mais
prático a utilização do método GET, desde que haja o bom senso por parte do desenvolvedor
da aplicação.
Portanto, não deve-se utilizar o método GET para enviar dados relacionados ao
banco de dados da aplicação. Caso contrário, cria-se uma vulnerabilidade para a SQL
Injection. Se os dados enviados pela URL forem usados em alguma QUERY, fica
relativamente fácil para o atacante enviar algo a fim de burlar a SQL. Outro caso que pode
acontecer, é a utilização destes dados para o ataque Cross-Site Scripting. Para utilização do
método GET, é recomendável apenas a utilização de dados que sejam utilizados para facilitar
a navegação, e que não sejam usados para manipular informação e processamento. (OWASP,
2009).
46
Uma alternativa mais segura para a transmissão de informações confidenciais, é o
método POST, que diferentemente do GET, envia o dado para ser processado no servidor.
Através deste, os dados não ficam visíveis na URL da aplicação, escondendo dos usuários
informações sigilosas para o funcionamento da aplicação.
3.3.3 MÉTODOS POST
O método POST é um dos muitos métodos de solicitação suportados pelo protocolo
HTTP usado pelo World Wide Web. O método de solicitação POST é projetado para solicitar
que um servidor web aceite os dados fechados no corpo da mensagem de solicitação para o
armazenamento. Esse método envia os dados colocando-os no corpo da mensagem, deixando
a URL separada dos dados que serão enviados, com isso é possível enviar qualquer tipo de
dados por esse método. Com isso, definem-se algumas características deste método
(W3SCHOOLS, 2013b):
Solicitações POST nunca são armazenadas em cache.
Solicitações POST não permanecem no histórico do navegador.
Solicitações POST não podem ser marcadas.
Solicitações POST não têm restrições quanto ao comprimento dos dados.
O POST foi designado com a função de prover um método padrão para operações de
banco de dados, controle dos recursos existentes dentro da aplicação, proporcionar dados que
sejam um resultado de um envio de informações através do formulário. É através deste
método que o desenvolvedor da aplicação WEB deve incluir, atualizar ou mesmo remover
informações do banco de dados da aplicação (FIELDING ET AL. , 1999).
Cada um desses métodos tem suas características e o seu uso mais apropriado. Em
resumo, para pesquisar ou passar dados não confidenciais, com o intuito de navegação
dinâmica para outra parte da aplicação, é aconselhável o uso do método GET, caso haja a
necessidade de enviar dados para a manipulação em um banco de dados, o método usado
deverá ser o POST.
47
3.4. CONSIDERAÇÕES PARCIAIS
Ao longo do capítulo foram visualizadas as ferramentas e algumas vulnerabilidades
que precisam ser previstas. É nítida que a integração entre as ferramentas: PHP, HTML, e o
SQL necessitam estar em constante processo de validação, normatização, e também a escolha
certa de métodos e funcionalidades para atingir objetivos específicos. Para o PHP utilizado
juntamente com o HTML, é necessário sempre a validação dos dados, a codificação na
transmissão destes, e a utilização de versões recentes e funcionalidades que estejam de acordo
com as normas atuais de segurança. Já para a utilização do PHP com o SQL, é mandatória a
utilização de ferramentas, no caso citado o PDO, para a construção e passagem de parâmetros
para os comandos SQLs que serão utilizados no banco.
Com estes cuidados, é possível analisar que existe um processo padrão, que
provavelmente mudará muito pouco com o passar do tempo. A aplicação sempre precisa,
validar os dados, transmitir de maneira segura, realizar a validação dos dados novamente do
outro lado, demonstrando o padrão de sempre validar os dados que entram em qualquer parte
da aplicação, e por fim, utilizar técnicas que testem a lógica da SQL, façam uma nova
validação da entrada dos dados nos comandos SQL, e então após todo o processo, é possível a
execução e manipulação das informações contidas no banco. O processo é bem definido, e o
que mudará com o passar do tempo, são as técnicas utilizadas para a realização do processo.
No capítulo 3 são analisadas as técnicas atuais, e o processo de segurança previsto no
trabalho.
48
4. ANÁLISE
Após a compreensão das técnicas utilizadas para a programação segura, proteção dos
dados e do aprofundamento com relação às ferramentas PHP e SQL utilizadas neste trabalho,
fazem-se necessário a sua análise. A etapa de análise consistirá na avaliação das possíveis
vulnerabilidades encontradas na programação PHP/SQL, abordando os aspectos de tratamento
de dados, SQL Injection, tipos de dados, restrições de HTML e cross site scripting.
É possível analisar neste ponto, que existe um processo de segurança inerente a
aplicação WEB, que sempre deve ser seguido, independentemente das técnicas empregadas
pelo desenvolvedor. A aplicação sempre deverá filtrar os dados recebidos de fora, através do
tratamento voltado para o tipo de dado esperado, transmitir dados de maneira codificada para
outras partes da aplicação, de maneira que o usuário não consiga enxergar as informações
confidenciais, e estes, quando recebidos pela parte da aplicação, deverão ser revalidados para
ver se estão coerentes com os dados esperados, e só então, serão empregados em técnicas que
verifiquem se não existem alterações lógicas da SQL, ou mesmo para a utilização em código
HTML. Pode-se visualizar o processo na Figura 3.
Figura 3: Processo padrão de fluxo dos dados da aplicação WEB
Conforme a figura 3 é possível a visualização dos dados vindos de uma fonte externa
da validação, passam por uma validação inicial pela aplicação, são tratados, ou transformados,
49
caso necessária a retransmissão são revalidados e tratados, para então, finalmente serem
inseridos dentro de algum comando SQL. Todos os pontos citados neste processo, serão
avaliados no decorrer deste capítulo, seguindo as regras definidas neste fluxo para, validação,
tratamento e execução dos dados de uma aplicação e, a utilização deste conjunto tem por
objetivo a prevenção e minimização das vulnerabilidades no software.
Através do estudo do guia de boas práticas listadas no item 2.6.2 e também das normas
descritas pela OWASP definidas no item 2.6.1, são avaliados casos reais e facilmente
encontrados no dia a dia no desenvolvimento de aplicações. O estudo desses casos tem por
objetivo avaliar a causa e o impacto das vulnerabilidades no sistema desenvolvido, tendo o
foco na minimização dessas ocorrências e estabelecendo regras para não persistência desses
problemas.
4.1 Tipos de Dados
A filtragem pelos tipos de dados garante que as informações repassadas para aplicação
sejam mais seguras, ou seja, ao desenvolver um formulário é necessário no nível de aplicação
uma padronização para que as informações digitadas pelo usuário sigam um padrão. Por
exemplo, garantir que um campo numérico permita somente a entrada de dados do tipo
integer, ou que um campo do tipo email valide a entrada dos dados conforme a padronização
de um campo deste mesmo tipo.
Aplicando as metodologias disponibilizadas pela OWASP e as normas para definição
dos tipos de dados cria-se uma proteção inicial para passagem de informações no sistema
desenvolvido. Após a padronização e definição dos tipos de dados, faz-se necessário o
tratamento dos dados, garantindo que após o repasse dos dados do usuário para aplicação os
mesmos sejam tratados e utilizados com segurança, reduzindo a incidência de
vulnerabilidades.
4.2 Tratamento de dados
As vulnerabilidades encontradas no tratamento dos dados estão relacionadas a uma
validação inapropriada dos mesmos e também a forma ao qual esses dados são passados para
a aplicação. Conforme visto no capítulo 2, foram já explanados três tipos de testes para evitar
a ocorrência de vulnerabilidades, sendo eles: Integridade, Validação e Regras de Negócio, e
50
também foram definidas algumas regras descritas pela OWASP, que tem por para manter a
integridade dos dados, essas questões são primordiais para o entendimento e aplicação do
tratamento de dados, pois em conjunto com as regras que serão descritas, formam uma
padronização e diminuem a incidência de ataques e vulnerabilidades no código.
Dentre as regras definidas para manter a integridade dos dados, existem três
estratégias para seu tratamento, que possuem como objetivo a redução do impacto das
vulnerabilidades no código, são elas: Whitelist, Blacklist e Sanitize (OWASP, 2009). O estudo
desses procedimentos é importante devido ao fato da validação e tratamento dos dados
estarem presentes em todos os tipos de desenvolvimento de um software, sendo primordial
para os desenvolvedores que necessitam de uma aplicação segura e sem vulnerabilidades.
4.2.1 Whitelist
A primeira regra trata-se da validação Whitelist, esta técnica tem por objetivo verificar
se os dados fazem parte de um conjunto de restrições conhecidas, ou seja, se os dados
repassados pelo usuário pré-estabelecem as condições impostas pela aplicação (OWASP,
2009). Nesta técnica é realizada a listagem das regras para obtenção dos valores, por exemplo,
se o dado coletado for um telefone, a primeira regra a ser estabelecida é que esta variável
receba somente números inteiros com tamanho máximo de 8 caracteres para o Brasil.
Código 18: Utilização da Whitelist Fonte: OWASP,2009
Como pode ser observado no Código 18, é utilizada a técnica para verificação de um
número de código postal, nesta validação é analisado se o campo informado pelo usuário é
diferente de null, se o tamanho corresponde a um código postal e se a sua sintaxe está correto,
caso contrário o campo ficará em branco. Ou seja, são avaliadas somente as regras padrões
para a formação do código-postal, conforme definido nas regras da Whitelist.
Pode-se analisar que, esta técnica é considerada a mais ideal para aplicações que
necessitam da garantia de que o dado repassado siga somente as regras impostas na Whitelist.
(OWASP, 2009). Realizando uma analogia ao método utilizado para as regras de firewall,
quando se cria uma regra de permissão, as demais regras não listadas são automaticamente
negadas, ou seja, a utilização de uma Whitelist para o tratamento dos dados fará com que
51
todas as regras não tratadas sejam negadas, bloqueando que qualquer tipo de dado diferente
do padrão definido seja repassado para aplicação.
4.2.2 Blacklist
Conhecida como Blacklist, a segunda regra trata-se de uma técnica onde são listados
todos os conjuntos de possíveis dados incorretos. Essa técnica é considerada arriscada, pois a
listagem pode tornar-se infinita e, para manter esse tipo de validação é necessário sempre
manter uma estratégia para que a listagem esteja sempre atualizada. Esta abordagem pode ser
assemelhada a atualização padrão de um antivírus, onde somente ao identificar a falha/vírus
são distribuídas as devidas atualizações (OWASP, 2009).
A utilização deste método para o tratamento de dados não é considerado o ideal,
devido ao fato de que as regras definidas na Blacklist serão negadas, ou seja, caso houver
alguma regra ainda não conhecida pelo desenvolvedor, a mesma será permitida para o
usuário, ocasionando vulnerabilidades no código e reduzindo a segurança da aplicação. Nesse
caso, o desenvolvedor deverá analisar todas as possíveis formas de bloqueio para o dado, e
caso necessário, sempre manter atualizada a Blacklist para que não haja a incidência de
vulnerabilidades no software.
4.2.3 Sanitize
O método Sanitize trata-se de uma regra para filtragem dos dados, ao invés de aceitar
ou rejeitar a entrada, os dados são alterados para um formato aceitável. Existem dois tipos de
filtragem, sendo eles o Sanitize utilizando as regras Whitelist e o Sanitize com a utilização de
uma Blacklist (OWASP, 2009).
Os caracteres que não fazem parte de uma Whitelist podem ser eliminados e
bloqueados já na passagem dos dados. Por exemplo, se o dado esperado é um numero de
telefone, são retirados todos os caracteres que não são dígitos, mantendo somente os números
informados pelos usuários. Na utilização da Blacklist é possível eliminar ou traduzir
caracteres, porém esta estratégia necessita manutenção e normalmente pode estar incompleta
(OWASP, 2009).
A utilização do método de Sanitize utiliza a lógica descrita no tópico 3.1 de análise dos
tipos de dados e é utilizada juntamente com as regras Whitelist ou Blacklist. Pode-se analisar
52
que para utilização deste método a escolha ideal seria a utilização juntamente com a Whitelist,
devido às mesmas justificativas declaradas no tópico 3.2.1.
4.3 SQL Injection
As consultas SQL definidas em um código podem ser manipuladas e passadas
despercebidas quando não há o tratamento correto desses comandos na aplicação. O SQL
Injection ocorre quando um atacante manipula a variável de entrada da consulta criando ou
alterando esta mesma variável, tendo por objetivo coletar informações, sobrescrever e até
mesmo excluir dados (PHP, 2013C).
Código 19: Exemplo SQL Injection Fonte: (PHP, 2013C)
Conforme demonstrado no Código 19, se o atacante alterar o conteúdo da variável
$offset (Linha 3) para 0; e acrescentar qualquer tipo de consulta SQL, será possível ter acesso
as informações do banco e permitirá ao atacante coletar qualquer tipo de informação,
ocasionando uma vulnerabilidade no código. Uma técnica simples utilizada para garantir que
não ocorra esse tipo de ataque é, acrescentar o sinal de comentário “–“ ao final na instrução
SQL, fazendo com que tudo que for definido após a variável se torne um comentário (PHP,
2013C).
A utilização da técnica prepared statements da extensão PDO na linguagem PHP trata
as informações com o objetivo de aumentar, porém não eliminar, a segurança contra o SQL
Injection. As utilizações das técnicas disponibilizadas pela PDO reduzem a ocorrência de
vulnerabilidade tornando o código mais confiável e eliminando as ocorrências de ataques do
tipo ao qual foi mostrado no Código 19.
Outra técnica utilizada para a prevenção deste tipo de ataque é a stored procedures,
citada no capítulo 2, está técnica também torna o código mais confiável, porém torna-se
trabalhoso para o desenvolvedor criar diretamente no banco de dados as funções para
tratamento dessas consultas, para aplicações onde são utilizados diversos tipos de base de
53
dados, deverá ser criada as funções para todos eles, tornando mais trabalhoso e demorado para
implementação. A utilização da técnica prepared statements é a ideal devido ao fato de ser
menos trabalhoso o seu tratamento para os diversos tipos de bancos e de possuir a
flexibilidade para trabalhar com os comandos SQL diretamente no código PHP.
Neste tópico, foi realizada a análise das formas de prevenção do SQL Injection,
avaliando as técnicas existentes definidas pela OWASP, e que possuem o objetivo de
minimizar a incidência de uma vulnerabilidade. Porém, torna-se necessário o estudo das
restrições de HTML que também estão estreitamente relacionadas à passagem de
informações, tratamento de dados e as ocorrências de ataques do tipo SQL Injection.
4.4 Restrições de HTML
Como medida para prevenção de vulnerabilidades no PHP e SQL, é necessário o
tratamento do código HTML tendo o objetivo de prevenir ataques via SQL Injection, Cross
Site Scripting e também realizando o tratamento de dados a partir do HTML. As restrições de
HTML se limitam basicamente ao tratamento realizado diretamente no código, tendo o
objetivo de prevenir, padronizar e estabelecer uma segurança inicial no código.
Para prevenir ataques que resultem em SQL Injection, além da implementação dos
métodos descritos no item 3.3, é necessário tratar via HTML o envio do formulário utilizando
o método POST para variáveis que manipulem consultas SQL ou que façam qualquer tipo de
visualização e alteração no sistema. A utilização do método GET deve ser utilizada somente
para facilitar a navegação e não para manipulação de informações ou processamento de dados
na aplicação.
Após analisar o principal método para tratamento do código HTML, que tinha por
objetivo tornar a aplicação segura no quesito código HTML para envio de formulários, é
necessário avaliar outro tipo de ataque conhecimento atualmente, o Cross Site Scripting.
Como prevenção deste tipo de ataque, deve ser utilizado o envio das variáveis via método
POST e também, para casos em que seja necessária a utilização do método GET, o método
usual é a codificação da URL dificultando o ataque através deste método.
4.4.1 Cross Site Scripting
54
Conforme visto no capítulo 2, o ataque conhecido como Cross Site Scripting tem como
objetivo executar comandos JavaScript em uma aplicação injetando o código malicioso
através de um campo texto na aplicação ou através da url utilizando o método GET no
HTML. Como prevenção para esse tipo de ataque, é sugerida a utilização do método POST ou
então o tratamento da URL para codificação e decodificação das informações repassadas.
A OWASP define algumas regras para prevenção do Cross Site Scripting, essas regras
possuem o objetivo de tratar o código javascript com o objetivo de prevenir que ataques do
tipo cross site scripting ocorram. Dentre as principais regras definidas para prevenção deste
tipo de ataque (OWASP, 2013B):
Nunca inserir dados não confiáveis, a não ser em locais onde é realmente necessário.
Codificar os caracteres de HTML quando colocados dentro das tags
HTML.
Codificar os caracteres de HTML que serão atribuídos dentro dos
atributos das tags HTML.
Codificar os dados antes de inserir dentro de variáveis Javascript.
Codificar caracteres de dados que serão colocados dentro da folha de
estilos do HTML.
Codificar dados que serão inseridos dentro de parâmetros da URL.
Validar código HTML através de bibliotecas desenvolvidas para a
função
Para todas essas codificações é necessário utilizar os caracteres do tipo
HEX, que convertem caracteres especiais para outros caracteres.
Após a visualização das regras definidas pela OWASP, pode-se analisar que as regras
identificadas anteriormente, de validação dos dados pelo seu tipo, podem ser empregadas
neste caso. Caso inicialmente a validação seja realizada verificando se o tipo de dado trata-se
de um HTML, ou javascript ou CSS, empregando as regras de tratamento de dados, será
possível minimizar a ocorrência de casos cross site scripting.
Código 20: Exemplo Cross Site Scripting Fonte: (OWASP, 2013B)
55
Conforme mostra o Código 20 acima, os dados não confiáveis não devem ser inseridos
dentro de tags, conforme podemos analisar na linha 1, ou dentro de comentários como
definido na linha 2. Na linha 1, é utilizada a tag script e, conforme definido pela OWASP, não
se deve colocar informações dentro da mesma caso não seja codificada da maneira adequada.
4.5. Considerações Parciais
No decorrer do capítulo foi realizada uma análise direcionada aos principais pontos no
desenvolvimento de uma aplicação onde, torna-se necessário a aplicação de padronizações,
métodos ou procedimentos que visam a minimização de vulnerabilidades em um software.
Foram analisados os tipos de dados e como manter uma padronização, o tratamento de dados
e os tipos de tratamento conforme a especificação da OWASP, baseando-se nas normas e
guias de boas práticas já citadas no capítulo anterior.
O principal ponto aprofundado nesta pesquisa foi a análise ao tratamento de ataques
do tipo SQL Injection, pode-se avaliar como esse tipo de intrusão ocorre e os principais
métodos utilizados para prevenção e minimização dessas possíveis manipulações no código.
Também foram analisadas as formas de restrição HTML e os principais métodos para
prevenção do Cross Site Scripting, objetivando a análise total do processo definido na
introdução deste capítulo.
56
5. CONSIDERAÇÕES FINAIS
Após a realização das análises das técnicas de segurança recomendadas pela
OWASP, pode-se fazer uma citação dos objetivos empregados inicialmente no trabalho. O
objetivo geral do trabalho, e os objetivos específicos, foram atingidos através da
fundamentação, estudo e análise das técnicas recomendadas pela comunidade. Através de
todas estas técnicas é possível para uma aplicação se tornar segura e as análises realizadas
auxiliam o processo de escolha no desenvolvimento da aplicação. Um dos principais fatores
para o sucesso do objetivo foi devido à quantidade de detalhes exposta pela comunidade para
os desenvolvedores, de maneira gratuita e simples de ser encontrada. A comunidade OWASP
oferece uma série de tópicos e artigos relacionados a partes especificas das aplicações WEB,
tornando o trabalho de pesquisa cientifica prático para encontrar o escopo de determinado
assunto.
Através da comunidade OWASP, foi possível obter a classificação de normas,
obrigatórias ou recomendadas, a partir dos tipos de ataques na WEB classificados por SQL
Injection,ou Cross site scripting. A comunidade descreve as técnicas de forma abrangente,
sem a utilização de linguagens especificas, porém sempre especificando validações que os
dados devem percorrer através do código.
As impressões obtidas através da execução do trabalho, são que existem várias
maneiras eficientes e práticas para o desenvolvimento seguro da aplicação. As próprias
ferramentas dispostas neste trabalho fornecem frameworks e recomendações de utilização de
métodos atuais, de forma que a aplicação se manterá sempre atualizada e segura se o
desenvolvedor seguir de perto esses patches de atualizações.
Uma das principais dificuldades encontradas ao longo do trabalho, estão relacionadas
a falta de preocupação da comunidade oficial da ferramenta PHP, PEAR, de orientar o
desenvolvedor a seguir normas voltadas para a segurança da aplicação. Apesar de haver
alguma documentação voltada para isso, foi um conteúdo muito pequeno se comparado a
comunidade OWASP. As ferramentas voltadas para a segurança existem, e estão
disponibilizadas na comunidade oficial, porém falta uma orientação mais detalhada para
facilitar o trabalho do desenvolvedor e do pesquisador.
Apesar do sucesso com relação aos objetivos, o trabalho foi feito com o objetivo de
abranger de forma genérica os assuntos relacionados a segurança da aplicação WEB,
principalmente voltada pra a injeção de código SQL, ou SQL Injection. Para trabalhos futuros,
57
poderiam ser aprofundados vários aspectos abordados que ficaram expostos apenas como uma
breve introdução, como por exemplo, o tratamento de segurança relacionado ao XSS, o
aprofundamento das técnicas de codificação para a passagem dos parâmetros através dos
métodos de requisição, ou mesmo a abordagem mais especifica das teorias empregadas no
framework PHP PDO.
58
REFERÊNCIAS
Jacyntho, AZEVEDO. Processos para Desenvolvimento de Aplicações Web , 2008.
Disponível em: <ftp://ftp.inf.puc-rio.br/pub/docs/techreports/09_23_jacyntho.pdf>. Acesso
em: 24 mar. 2013
BATTISTI, J. Livro SQL Server 2005 Administração & Desenvolvimento: Curso Completo.
2005.
KLINE, K. SQL - O Guia Essencial. 2010.
KLINE, K. E., HUNT, B. SQL in a Nutshell. O'Reilly Media, Inc. 2009
MACINTYRE, P. O melhor do PHP. [s.l.] Alta Books, 2010.
MELO, A. DE; NASCIMENTO, M. PHP profissional. São Paulo: Novatec, 2007.
O Desenvolvimento de Aplicações WEB, 1997. Disponível em:
<http://www.rnp.br/newsgen/9710/n5-3.html>. Acesso em: 24 mar. 2013.
PATRICK, J. Sql Fundamentos. . Acesso em: 7 abr. 2013.
PHP: A História do PHP – Manual, 2013. Disponível em:
<http://php.net/manual/pt_BR/history.php.php>. Acesso em: 24 mar. 2013A.
PHP: Introduction – PDO, 2013. Disponível em:
<http://www.php.net/manual/en/intro.pdo.php>. Acesso em: 24 mar. 2013B.
VOGT, V. WHATEVER HAPPENED TO SQL STANDARDS?, 2008. Disponível em:
<https://portfolio.du.edu/portfolio/getportfoliofile?uid=129671> Acesse em: 19 abr.
OWASP . Guide to Authentication, 2009A. Disponível em:
https://www.owasp.org/index.php/Guide_to_Authentication. Acesso em: 19 abr. 2013
OWASP. Data Validation, 2009B. Disponível em:
<https://www.owasp.org/index.php/Data_Validation#Where_to_include_business_rule_valid
ation>. Acesso em: 19 abr. 2013.
OWASP. Guide Table of Contents, 2007. Disponível em:
https://www.owasp.org/index.php/Guide_Table_of_Contents. Acesso em: 19 abr. 2013.
OWASP. SQL Injection Prevention Cheat Sheet, 2012A. Disponível em:
<https://www.owasp.org/index.php?title=SQL_Injection_Prevention_Cheat_Sheet>. Acesso
em: 19 abr. 2013.
OWASP. Top 10 2007-Injection Flaws, 2013. Disponível em:
<http://www.owasp.com/index.php/Top_10_2007-Injection_Flaws>. Acesso em:
10 mar. 2013.
59
PEAR. Coding Standards, 2013A. Disponível em:
<http://pear.php.net/manual/en/standards.php>. Acesso em: 19 abr. 2013.
PEAR. Indenting and Line Length, 2013B. Disponível em:
<http://pear.php.net/manual/en/standards.indenting.php>. Acesso em: 19 abr. 2013.
PEAR. Standards Control, 2013C. Disponível em:
<http://pear.php.net/manual/en/standards.control.php>. Acesso em: 19 abr. 2013.
PEAR. Function Calls, 2013D. Disponível em:
<http://pear.php.net/manual/en/standards.funcalls.php>. Acesso em: 19 abr. 2013.
PEAR. Class Definition, 2013E. Disponível em:
<http://pear.php.net/manual/en/standards.classdef.php>. Acesso em: 19 abr. 2013.
PEAR. Function Definitions, 2013F. Disponível em:
<http://pear.php.net/manual/en/standards.funcdef.php>. Acesso em: 19 abr. 2013.
PEAR. Arrays, 2013G. Disponível em: <http://pear.php.net/manual/en/standards.arrays.php>.
Acesso em: 19 abr. 2013.
PEAR. Comments, 2013H. Disponível em:
<http://pear.php.net/manual/en/standards.comments.php>. Acesso em: 19 abr. 2013.
PEAR. Standards Including, 2013I. Disponível em:
<http://pear.php.net/manual/en/standards.including.php>. Acesso em: 19 abr. 2013.
PEAR. Standards Tags, 2013J. Disponível em:
<http://pear.php.net/manual/en/standards.tags.php>. Acesso em: 19 abr. 2013.
PEAR. Standards Header, 2013L. Disponível em:
<http://pear.php.net/manual/en/standards.header.php>. Acesso em: 19 abr. 2013.
PEAR. Standards Naming, 2013M. Disponível em:
<http://pear.php.net/manual/en/standards.naming.php>. Acesso em: 19 abr. 2013.
PEAR. Standards File, 2013N. Disponível em:
<http://pear.php.net/manual/en/standards.file.php>. Acesso em: 19 abr. 2013.
LUIZ, EMERSON. Normas de códificação PHP PSR e dos Frameworks representados, 2012.
Disponível em: <http://www.fititnt.org/padrao/php-psr.html>. Acesso em: 19 abr. 2013.
PHP: mysql_real_escape_string – Manual, 2013C. Disponível em:
<http://php.net/manual/pt_BR/function.mysql-real-escape-string.php>. Acesso em:
19 abr. 2013.
FERRARA, A. PHP: rfc:password_hash [PHP Wiki], 2012. Disponível em:
<https://wiki.php.net/rfc/password_hash>. Acesso em: 19 abr. 2013.
60
PHP: Runtime Configuration – Manual, 2013D. Disponível em:
<http://www.php.net/manual/en/filter.configuration.php>. Acesso em: 19 abr. 2013.
PHP: The Right Way, 2013. Disponível em:
<http://www.phptherightway.com/#web_application_security>. Acesso em: 19 abr. 2013.
SYMANTEC. Symantec Internet Security Threat Report, 2007. Disponível em:
<http://eval.symantec.com/mktginfo/enterprise/white_papers/b-
whitepaper_exec_summary_internet_security_threat_report_xiii_04-2008.en-us.pdf>. Acesso
em: 14 maio. 2013
TROEL. Comparison of different SQL implementations, 2012. Disponível em:
<http://troels.arvin.dk/db/rdbms/>. Acesso em: 14 maio. 2013.
OWASP. About The Open Web Application Security Project, 2013A. Disponível em:
<https://www. owasp.org/index.php/About_OWASP#The_OWASP_Foundation>. Acesso
em: 14 maio. 2013.
W3SCHOOLS. HTML Forms and Input, 2013A. Disponível em:
<http://www.w3schools.com/html/html_forms.asp>. Acesso em: 26 maio. 2013.
W3SCHOOLS.HTTP Methods GET vs POST, 2013B. Disponível em:
<http://www.w3schools.com/tags/ref_httpmethods.asp>. Acesso em: 26 maio. 2013.
FIELDING ET AL. HTTP/1.1: Method Definitions, 2013. Disponível em:
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html>. Acesso em: 26 maio. 2013.
PHP Best Practices: a short, practical guide for common and confusing PHP tasks, 2013.
Disponível em: <https://phpbestpractices.org/>. Acesso em: 26 maio. 2013.
PHP. Tratando Formulários – Manual, 2013E. Disponível em:
<http://php.net/manual/pt_BR/tutorial.forms.php>. Acesso em: 26 maio. 2013.
Using the POST method in a PHP form, 2013. Disponível em: <http://www.html-form-
guide.com/php-form/php-form-post.html>. Acesso em: 26 maio. 2013.
Segurança da Informação: Tratando Dados Em Php, 2008. Disponível em:
<http://pt.pdfsb.com/readonline/5a6c6c4c65514231584852364148746855513d3d>. Acesso
em: 26 maio. 2013.
HALL, T. ALL, ANY and SOME Comparison Conditions in SQL, 2013. Disponível em:
<http://www.oracle-base.com/misc/site-info.php>. Acesso em: 26 maio. 2013.
W3C. Conformance: requirements and recommendations, 2013. Disponível em:
<http://www.w3.org/TR/html401/conform.html#deprecated>. Acesso em: 18 jun. 2013.
ORACLE. DELETE, 2013. Disponível em:
<http://docs.oracle.com/cd/E11882_01/server.112/e26088/statements_8005.htm#SQLRF0150
5>. Acesso em: 18 jun. 2013.
61
W3C. Facts About W3C, 2013 . Disponível em:
<http://www.w3.org/Consortium/facts#history>. Acesso em: 18 jun. 2013.
IBM solidDB 6.3 and IBM solidDB Universal Cache 6.3 Information Center, 2013.
Disponível em:
<http://publib.boulder.ibm.com/infocenter/soliddb/v6r3/index.jsp?topic=/com.ibm.swg.im.sol
iddb.sql.doc/doc/relational.databases.html>. Acesso em: 18 jun. 2013.
ORACLE. INSERT, 2013. Disponível em:
<http://docs.oracle.com/cd/E11882_01/server.112/e10592/statements_9014.htm#i2111652>.
Acesso em: 18 jun. 2013.
ORACLE. PL/SQL Dynamic SQL, 2013. Disponível em:
<http://docs.oracle.com/cd/E11882_01/appdev.112/e10472/dynamic.htm>. Acesso em: 18
jun. 2013.
WASSERMAN, G.; SU, Z. The Essence of Command Injection Attacks in Web
Applications, 2013. Disponível em:
<http://www.cs.ucdavis.edu/~su/publications/popl06.pdf>. Acesso em: 18 jun. 2013
MICROSOFT. Structured Query Language (SQL), 2013. Disponível em:
<http://msdn.microsoft.com/en-gb/library/windows/desktop/ms714670(v=vs.85).aspx>.
Acesso em: 18 jun. 2013.
OWASP. Testing for Exposed Session Variables (OWASP-SM-004), 2012B. Disponível
em: <https://www.owasp.org/index.php/Testing_for_Exposed_Session_Variables_(OWASP-
SM-004)>. Acesso em: 18 jun. 2013.
OWASP. XSS (Cross Site Scripting) Prevention Cheat Sheet, 2013B. Disponível em:
<https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_S
heet>. Acesso em: 18 jun. 2013.
ANSI. Information Technology - Database Language SQL (Proposed revised text of DIS
9075) , 1992. Disponível em:
<http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt>. Acesso em: 18 jun. 2013.
Stoneburner & Hayden, Engineering Principles for Information Technology Security (A
Baseline for Achieving Security), Revision A - SP800-27-RevA.pdf. , 2004. Disponível em:
<http://csrc.nist.gov/publications/nistpubs/800-27A/SP800-27-RevA.pdf>. Acesso em: 21
jun. 2013