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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Segurança em Aplicações Web com PHP

Ähnlich wie Segurança em Aplicações Web com PHP (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (6)

Segurança em Aplicações Web com PHP