php desenvolvimento seguro

Desenvolvimento Seguro com PHP

Palestrante: Flávio Gomes da Silva Lisboawww.fgsl.eti.br


http://www.fgsl.eti.br/

“Com um grande poder, vem uma grande responsabilidade”.


Poder e Responsabilidade

“Ben Parker avisou uma vez seu jovem sobrinho Peter Peter, cujo alter-ego super-herói é o Homem-Aranha, que “com um grande poder, vem uma grande responsabilidade”.

Assim é com a segurança em aplicações PHP. O PHP fornece um rico conjunto de ferramentas com imenso poder – alguns tem argumentado que talvez seja muito poder – e este poder, quando usado com cuidadosa atenção aos detalhes, permite a criação de aplicações complexas e robustas.

Por outro lado, sem essa atenção para os detalhes, usuários maliciosos podem usar o poder do PHP para seus próprios interesses, atacando aplicações de várias formas.”

Introdução

Zend PHP 5 Certification Study Guide


Falta de segurança: mito do PHP

A maior fraqueza na maioria dos programas PHP não é inerente a linguagem em si, mas meramente um problema de código escrito desconsiderando a segurança.

Por essa razão, você sempre deve investir um pouco de tempo considerando as implicações de um certo pedaço de código, para ter certeza do dano possível se uma variável não esperada for submetida ao mesmo.

Introdução

Manual do PHP: www.php.net


Conceitos e PráticasToda Entrada está DoenteLista Branca versus Lista NegraFiltro de EntradaTratamento de SaídaRegister Globals

Segurança de WebsiteFormulários FalsificadosCross-Site ScriptingCross-Site Request Forgeries

Segurança de Banco de DadosSegurança de SessãoSegurança do Sistema de Arquivos

Remote Code InjectionCommand Injection

Algumas Dicas Importantes

Agenda


Toda Entrada está Doente

►Se o dado se origina de uma fonte externa, ele não pode ser confiável.

►Não temos certeza de os dados contém caracteres que podem ser executados no contexto errado.

►Dados de todas as matrizes superglobais, exceto $_SESSION devem ser considerados doentes.

CONCLUSÃO: Todo dado deve ser filtrado.

Conceitos e Práticas

Zend PHP 5 Certification Study Guide


Lista Branca versus Lista Negra

►Lista Negra→ Menos restritiva.→ Há um conjunto específico de palavras que são consideradas

inapropriadas.→ Qualquer palavra que não conste da lista é permitida.→ Listas negras devem ser modificadas continuamente, e

expandidas quando novos vetores de ataque tornam-se evidentes.

►Lista Branca→ Mais restritiva.→ Identifica somente os dados que são aceitáveis.→ Mantém controle sobre os parâmetros que mudam e não os deixa

aos caprichos de pretensos atacantes.

CONCLUSÃO: Listas brancas oferecem mais proteção contra ataque do que listas negras.



Filtro de Entrada

Uma vez que toda entrada é doente e não pode ser confiável, é necessário filtrar sua entrada de modo a garantir que a entrada recebida seja a esperada.

Para fazer isto, use uma abordagem de lista branca.

Filtrar com uma abordagem de lista branca coloca o controle firmemente em suas mãos e assegura que sua aplicação não receberá dados maliciosos.

Você deve forçar o usuário a fornecer dados corretos e então tentar limpar e sanitizá-los por conta própria.

Funções: addslashes(), ctype_*(), html_entity_decode(), htmlentities(), strip_tags(), stripslashes(), trim(), entre outras.



Tratamento de Saída

Assim como a filtragem de entrada protege sua aplicação de dados maliciosos e nocivos, o tratamento de saída protege o cliente e o usuário de comandos potencialmente perigosos.

A saída deve ser tratada porque os clientes – navegadores Web, servidores de banco de dados, e assim por diante – freqüentementeexecutam uma ação quando encontram caracteres especiais.

Funções: addslashes(), ctype_*(), html_entity_decode(), htmlentities(), strip_tags(), stripslashes(), trim(), entre outras.



Register Globals

Se configurada como On todas as variáveis provenientes de literais de consulta, formulários postados, sessões armazenadas, cookies, e assim por diante, estão disponíveis como o que parecem ser variáveis nomeadas localmente.

Se as variáveis não forem inicializadas antes do uso, é possível para um usuário malicioso configurar variáveis de script e comprometer uma aplicação.

Tira do programador a noção de origem dos dados.

Tira do interpretador da linguagem a noção de origem dos dados.

Desabilitada por padrão à partir da versão 4.2.0 e na versão 6 será eliminada.



Formulários Falsificados

Há várias formas de falsificar formulários, o mais fácil deles é simplesmente copiar um formulário alvo e executá-lo de um lugar diferente.

Falsificar um formulário torna possível para um atacante remover todas as restrições do lado do cliente impostas pelo formulário de modo a submeter toda e qualquer forma de dados para sua aplicação.

Submissões de formulários falsificados são difíceis de prevenir.

CONCLUSÃO: Nunca dependa somente da validação do lado do cliente.

Segurança de Website


Cross-Site Scripting (XSS)

É um dos mais comuns e mais conhecidos tipos de ataque.

Explora a confiança do usuário na aplicação e é geralmente um esforço para roubar informações do usuário, tal como cookies e outros dados de identificação pessoal.

Todas as aplicações que mostram a entrada são um risco. Exemplo: fóruns, blogs, etc.

Pode ser contornado com o tratamento da saída.



Cross-Site Request Forgeries (CSRF)

É um ataque que tenta fazer com que uma vítima envie sem saber requisições HTTP, normalmente para URLs que requerem acesso privilegiado e usar a sessão existente da vítima para determinar o acesso.

A requisição HTTP então força a vítima a executar uma ação particular baseada no seu nível de privilégio, tal como fazer uma compra ou modificar ou remover uma informação.

Sua aplicação necessita da habilidade de determinar se uma requisição foi intencional e legítima ou forjada e maliciosa.

Pode ser contornado com o uso de um token randômico armazenado em sessão, que seja gravado nos formulários.



SQL Injection

Ocorre quando um usuário malicioso experimenta obter informações sobre um banco de dados através de um formulário.

Depois de conseguir conhecimento suficiente – geralmente das mensagens de erro do banco de dados – o atacante estará equipado para explorar o formulário para quaisquer possíveis vulnerabilidades através de injeção de SQL em campos do formulário.

CONCLUSÃO: Filtre todos os dados que possam fazer parte de declarações SQL.

Segurança de Banco de Dados


Session Fixation

É possível configurar o identificador de sessão manualmente através de um literal de consulta, forçando o uso de uma sessão particular.

Obtido geralmente pela criação de um link para sua aplicação e a adiçãodo identificador que o atacante deseja dar a qualquer usuário que clicar no link.

Enquanto o usuário acessa seu site através da sessão, ele pode fornecer informações sensíveis ou mesmo credenciais de login. O propósito do ataque é obter um alto nível de privilégio.

CONCLUSÃO: Cada vez que um nível de acesso de usuário muda, é necessário regenerar o identificador de sessão. PHP faz disso uma tarefa simples com session_regenerate_id().

Segurança de Sessão


Session Hijacking

Este é um termo genericamente usado para descrever quaisquer meios pelos quais um atacante obtenha um identificador de sessão válido (ou que forneça um de sua própria autoria).

Pode ser contornado pela verificação de vários cabeçalhos da requisição enviados pelo cliente, através de parâmetros que não se alterem.

Segurança de Sessão


Remote Code Injection

Ocorre quando um atacante é capaz de fazer sua aplicação executar código PHP de seu escolha.

Pode ser contornado com filtragem de dados.

Segurança de Sistema de Arquivos


Command Injection

O PHP provê grande poder com as funções exec(), system() e passthru(), bem como o operador ‘ (acento agudo).

Elas não devem ser usadas levianamente, e é importante tomar grande cuidado em garantir que atacantes não possam injetar e executar comandos de sistema arbitrariamente.

Pode ser contornado com filtragem de dados.

Funções: escapeshellcmd() e escapeshellarg().

Segurança de Sistema de Arquivos


Mensagens de Erro são para o Desenvolvimento

Desligue display_errors na produção.

Use log_errors e error_log.



Use require ao invés de include

require gera erros fatais e interrompe a aplicação. include reporta o erro e

prossegue com a execução.



Criptografe os Dados

Funções: MD5, SHA1, mcrypt, etc



Desligue magic_quotes_gpc

Afeta a portabilidade (está ligada, está desligada?)

Performance: todos os dados sofrem escaping.

Inconveniência. Gera caracteres de escape onde não é necessário (por exemplo, e-mail).

Será removido no PHP 6.



http://www.php.net/manual/pt_BR/security.php

Onde obtenho ajuda?

http://www.php.net/manual/pt_BR/security.php


Sugestão de Leitura


Perguntas

?www.fgsl.eti.br

http://www.fgsl.eti.br/


Fim

Obrigado

php desenvolvimento seguro

Technology