Segurança em Aplicações Web com PHP

Segurança em Aplicações
Web com PHP

Segurança em Aplicações Web com PHP V Ensol
Gedvan Dias 22 de julho de 2011

Sobre mim
●
Mestre em Informática pela UFPB
●
Professor substituto no IFPB
– C, PHP, Comércio Eletrônico

●
Professor na Faculdade IDEZ
– HTML/CSS/PHP

●
Lexa Sistemas – www.lexasistemas.com.br
– Criação de sites em Drupal

●
Letz – www.letz.com.br
– Rede social para divulgação de eventos


Esta palestra é sobre
●
Segurança em aplicações web
– Boas práticas de programação
– Erros comuns
– Detalhes do PHP
– Tipos de ataques a sites
– Autenticação e autorização
– Foco na implementação com PHP
●
Pode ser aplicado para outras linguagens


Esta palestra não é sobre
●
Segurança de servidores
– Configuração de servidores
– Firewalls
– DNS, FTP, SSH, HTTPS, …
– DoS, IP spoofing, phising, …
– Spam


Segurança e a linguagem PHP
●
Por que PHP?
●
PHP surgiu de forma despretensiosa
●
Acabou se tornando a linguagem server-side
mais utilizada na web
– Facilidade, rapidez, versatilidade, etc.


Segurança e a linguagem PHP
●
Grandes poderes trazem grandes
responsabilidades
●
Programadores inexperientes
●
Autodidatismo é bom, mas...
– Aprendo apenas o que me interessa
– Questões importantes acabam ficando de lado

●
Prazos apertados...


Alguns casos recentes
●
Site Mysql.com tem banco de dados
comprometido [1]
– Ataque via SQL Injection
– Acesso a usuários, senhas, e-mails, etc.

[1] http://www.computerworld.com/s/article/9215249/MySQL_Web_site_falls_victim_to_SQL_injection_attack


●
Sony

Sony Pictures[1]

Sony Japan[2]

Sony Greece[3]

Sony Canada[4]

[1] http://www.bbc.co.uk/news/technology-13642145
[2] http://nakedsecurity.sophos.com/2011/05/24/sony-music-japan-hacked-through-sql-injection-flaw/
[3] http://nakedsecurity.sophos.com/2011/05/22/sony-bmg-greece-the-latest-hacked-sony-site/
[4] http://www.computerworld.com/s/article/9217028/Sony_says_hacker_stole_2_000_records_from_Canadian_site


●
Sites do Governo Brasileiro
– Vários órgãos públicos tiveram seu site atacado
– Portal Brasil, Presidência, Senado, Receita Federal, IBGE,
entre outros
– Ataques de DoS, defacements e alguns roubos de dados


Vamos ao que interessa
Show me the code!


Configurações do PHP
●
register_globals

Variáveis globais são criadas automaticamente a
partir de parâmetros GET, POST, cookies, sessões,
etc.

Desabilitado por padrão a partir do PHP 4.2

Depracated no PHP 5.3


Tratamento de erros
●
Algumas configurações relacionadas a erros:

error_reporting: nível de erro a ser reportado
– E_ALL ou E_ALL | E_STRICT

display_errors: exibir ou não erros na tela
– Em produção, deve ser sempre desabilitado

log_errors: fazer log dos erros em arquivo

error_log: arquivo onde será feito log


Manipulação de erros
●
set_error_handler()

Permite usar uma função própria para o
tratamento dos erros
●
set_exception_handler()

Permite usar uma função para tratar exceções não
capturadas


set_error_handler()


Recomendações
e boas práticas


Programação defensiva
●
“Prevenir é melhor do que remediar”
●
A internet não é um lugar amigável
●
Um plano B pode salvar a sua vida (seu
emprego, sua reputação, etc.)
●
Pense sempre em minimizar os riscos


KISS
●
Keep It Simple, Stupid
●
Evite a complexidade desnecessária
●
Abra mão da “esperteza” em prol da segurança


KISS


Regra de Ouro
Toda entrada deve ser filtrada
e toda saída deve ser “escapada”


Filtro e Validação
●
Você está recebendo o que está esperando
receber?
●
Trate todo o input da sua aplicação
– Dados de formulários
– Parâmetros da URL
– Informações de cookies
– Dados de sistemas externos

●
Validação x Filtro (sanitizing)


Validação x Filtro

CPF 241.775.842-31

filtro/sanitizing validação

24177584231 Erro! Formato inválido!


API Data Filtering
●
Funções para tratar o input usando vários tipos
de filtro/validação
●
Disponível a partir do PHP 5.2
●
Pode substituir totalmente o acesso aos arrays
superglobais
– $_GET, $_POST, $_COOKIE, $_SERVER, $_ENV


filter_input


Escapando a Saída
●
Regra de ouro: … toda saída deve ser
“escapada”
– Pelo menos a toda a saída não confiável

●
O que quer dizer “escapar”?
– Vem do inglês escape
– Nesse contexto, quer dizer que devemos converter
determinados caracteres (ou sequências)

●
Objetivo: manter a integridade da saída


Escapando o HTML
●
A saída mais comum do PHP é o HTML
●
No HTML temos, basicamente:

Tags (abertura, fechamento, atributos)
– Definem a estrutura do documento

Conteúdo das tags (valores, texto)
●
Escape no HTML significa, normalmente,
impedir que hajam tags onde não deveria
haver


Escapando o HTML
●
Funções: htmlespecialchars(), htmlentities()
●
API Data Filtering: filter_input(), filter_var()


Principais Tipos de Ataques e
Vulnerabilidades


SQL Injection
●
Consiste em tentar inserir um trecho de código
SQL em uma query que será enviada a um
banco de dados


SQL Injection


Exploits of a mom


SQL Injection
●
SQL Injection é uma das vulnerabilidades mais
comuns em aplicações PHP
– Felizmente, é muito fácil se proteger contra esse tipo de
ataque

●
Basta escapar os dados enviados nas queries
– Lembra da regra de ouro?
– Ao utilizar banco de dados, as queries são dados de
saída (output) da aplicação
– Portanto, devem ser escapadas


Escapando Valores de Queries
●
Para escapar os valores enviados ao banco,
pode-se usar as funções de cada extensão
– MySQL: mysql_real_escape_string()
– PostgreSQL: pg_escape_string()
– …
– Em último caso, pode-se usar a função addslashes()

●
Interfaces OO e camadas de abstração
geralmente têm um método equivalente
– PDO: quote()


Bound Parameters
●
As camadas de abstração, normalmente,
também tem suporte a parâmetros bound
– O valores são vinculados através de marcadores
– A própria biblioteca faz o escape dos dados

Oferecem uma ótima proteção contra SQL
Injection


Escape de Identificadores
●
Normalmente, apenas os valores precisam ser
escapados
●
Em alguns casos, também é preciso escapar
(ou filtrar) os identificadores
– Nomes de tabelas e campos
– Nos casos onde eles vêm de uma fonte externa

●
No MySQL, os identificadores pode ser escritos
entre crases.
– Ex: SELECT * FROM `tablename`


XSS
Cross-Site Scripting


●
Também é um dos tipos mais comuns de
ataques
●
Toda aplicação que exibe dados recebidos
(input) corre riscos

Se esses dados não forem devidamente filtrados e
escapados, a aplicação estará vulnerável


Cross-Site Script
●
O atacante normalmente explorará essa falha
inserindo tags e código javascript no seu HTML
– Tags <iframe> chamando páginas maliciosas
– Código js para redirecionar o usuário para outras
páginas
– Código js para ler os cookies do usuário e enviá-los para
outros sites
– Código js para alterar as informações do site
(defacement)


●
Para se proteger de XSS, basta fazer o que já
foi dito

Filtrar a entrada, e

Escapar a saída
– htmlentities, htmlespecialchars, etc.



Demonstração


CSRF
Cross-Site Request Forgery


CSRF
●
Como o nome diz, consiste em tentar forjar
uma requisição de um site para outro
●
O atacante usa a própria vítima para fazer a
requisição, sem que ela tenha conhecimento
●
Portanto, é muito difícil identificar se uma
requisição é legítima ou um ataque CSRF


CRSF

Uma linha de código vale mais que mil palavras

(demonstração)


CSRF
●
Então como se defender do CSRF?


GET x POST
●
Antes de tudo

Entenda a diferença entre GET e POST

Funcionamento

Objetivos

Saiba quando usar cada um


GET
●
O método GET deve ser utilizado apenas para
consultas

Exibição de páginas

Listagens

Pesquisas

Downloads, etc.


POST
●
O método POST deve ser utilizado para as
operações

Cadastros

Atualização

Exclusão

Autenticação


GET
●
Não use o GET para realizar operações*
●
Nada que vá modificar os seus dados
●
Dessa forma, os ataques CSRF via GET não
causarão nenhum dano


Operações via GET
●
Às vezes, é necessário realizar operações via
GET
– Ativação de usuário
– Reset de senha

●
Normalmente, o usuário recebe o link por e-
mail
●
Nesses casos, o link deve conter um código
gerado aleatoriamente
– De preferência, com data de expiração


POST
●
Entretanto, ainda estamos vulneráveis a
ataques CSRF via POST
●
Uma solução é utilizar tokens na sessão

Os tokens são gerados de forma aleatória

São armazenados na sessão e incluídos no
formulário

Ao receber a requisição, os tokens da sessão e do
POST são comparados


POST
●
Outras técnicas ainda podem ser utilizadas
para incrementar a segurança

Incluir um tempo de expiração para os tokens

Validar o cabeçalho HTTP_REFERER (embora não
seja 100% confiável)


Request Spoofing


Request Spoofing
●
Request Spoofing é a tentativa de manipular
requisições de alguma forma
●
A forma mais simples é alterar manualmente
os parâmetros em uma URL
●
Também é possível alterar os elementos de um
formulário
– Modificar atributos (maxlength, disabled, readonly,
name, value)
– Inserir ou remover elementos


Request Spoofing
●
Para alterar um formulário, basta simplesmente
salvar a página no seu computador e editá-la
●
Ou utilizar ferramentas como o Firebug, que
permite editar todo o HTML
●
Outras ferramentas permitem até executar
códigos javascript de terceiros
●
Observação
– A saída que você gera na aplicação (HTML + CSS +
Javascript) não é mais sua, é do cliente


Request Spoofing
●
Com um pouco mais de conhecimento, é
possível criar requisições HTTP completas
– Pode ser feito na linha de comando, com o comando
telnet, por exemplo
– Pode-se criar um script em qualquer linguagem que se
conecta ao socket do servidor web
– Existem várias outras formas

●
O HTTP é um padrão aberto e sua aplicação
deve estar pronta para isso


Request Spoofing
●
Como se proteger nessa situação?

Filtrar a entrada …
… e escapar a saída


Arquivos


Exposição de Código
●
Deve-se evitar arquivos PHP com extensão
diferente de .php (ex: .inc)

Ou deve-se ter certeza que estão fora da raiz web

Ou que o Apache está configurado corretamente
para executá-los e não exibi-los


Inclusão de Arquivos
●
Inclusão arquivos errados: index.php?usuario=../../admin
●
Code injection: POST path=http://meusite.com


Command Injection
●
Se a sua aplicação executa comandos do shell,
também é preciso escapá-los
●
Funções

escapeshellcmd

escapeshellarg


Autenticação e Autorização


Autenticação
●
É o processo de identificar um usuário
●
Ou seja, verificar se a pessoa que está
acessando corresponde ao seu usuário
●
Dependendo de sua aplicação, considere o uso
do protocolo HTTPS para a autenticação


Autorização
●
Também é chamado de controle de acesso
●
Consiste em determinar se o usuário está
autorizado a acessar um determinado recurso
– Página, operação, consulta, etc.

●
Normalmente, as informações de autorização
ficam na sessão
●
Para processos críticos, considere fazer uma
nova autenticação


Finalizando...


Dicas finais
●
Crie o hábito de programar de forma segura
●
Em uma equipe, todos os programadores
devem ter os conceitos básicos em mente
●
Estabeleça uma política de segurança
previamente
●
Esteja atualizado


OWASP
●
The Open Web Application Secutiry Project
– Padrões relacionados a segurança
– Levantamento sobre vulnerabilidades e ataque
– Tecnologias e ferramentas
– Notícias, etc.

●
Projeto apoiado por grandes empresas e
universidades

Amazon, IBM, Mozilla, Oracle, etc.


Livros


Links
●
OWASP: www.owasp.org
●
Manual do PHP:
http://php.net/manual/en/security.php
●
PHP Security Consortium: http://phpsec.org/


Obrigado!
gedvan@gmail.com - @gedvan


Segurança em Aplicações Web com PHP

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Segurança em Aplicações Web com PHP

Segurança em Aplicações Web com PHP