Desenvolvendo sistemas seguros com PHP

953 visualizações

Publicada em

Nesta palestra, abordo as principais formas de ataque, assim como diversas dicas de programação com PHP para tornar o seu sistema cada vez mais seguro, assim como também dicas de configurações do php.ini.

Publicada em: Tecnologia
  • Seja a primeira pessoa a gostar disto

Desenvolvendo sistemas seguros com PHP

  1. 1. Desenvolvendo sistemas seguros com PHP FLÁVIO M. DE SOUZA
  2. 2. Flávio M. Souza  Graduado em Análise e Desenvolvimento de Sistemas, vivencia esse submundo da programação desde 2008 tendo o seu primeiro contato através da linguagem JAVA.  Seu Know-how é em automação de processos de empresas, tendo em seu currívulos diversos segmentos como mercantil, imobiliária, construtora, cartório, clínica odontológica entre outros.  Atuamente é Sócio DIretor e Analista de Sistemas da empresa inGETI (Provedora de soluções do SEBRAE/PI), trabalhando no projeto inSySALI (Sistema de gestão do SEBRAE para o programa Agente Local de Inovação), Analista de Sistemas da empresa Aura Consultoria, trabalhando no projeto DiagonalWEB (Sistema comercial na plataforma WEB da construtora Diagonal) e Professor da FATENE.  Possui conhecimento nas tecnologias JAVA SE, PHP, JAVASCRIPT, JQUERY, HTML, CSS, BOOTSTRAP, MYSQL e POSTGRESQL.
  3. 3. Porque os sistemas são vulneráveis  Erros de programação  Erros de configuração  Mudanças não autorizadas  Uso impróprio
  4. 4. O PHP é inseguro  Não, pelo contrário, o PHP sendo utilizado de forma correta é bastante seguro, não é a toa que grandes frameworks utiliza-o como linguagem base.  O PHP por ser uma linguagem de fácil aprendizagem acaba sendo a primeira linguagem de programação para muitos, o que acaba disponibilizando no mercado diversos profissionais inexperientes e imaturos.  Essa imaturidade causa desconhecimento das mais diversas falhas que citaremos neste material.
  5. 5. O PHP é inseguro  Ranking das linguagens de programação mais Utilizadas no mundo.
  6. 6. Tipos de ataques mais utilizados
  7. 7. XSS - Cross-Site Scripting  Permite a injeção de scripts no site atacado,  Em geral por meio de algum campo de input do usuário.  É um ataque ao usuário do site e não ao sistema servidor em si. Isso porque o script injetado nunca será executado no servidor, mas sim nos navegadores dos clientes que visitarem a página infectada.  Essas informações nos dão a primeira dica, JAMAIS DEVEMOS CONFIAR NAQUILO QUE O USUÁRIO DIGITA.
  8. 8. XSS - Cross-Site Scripting  A Solução para este tipo de ataque é escapar as entradas e saídas, dessa forma o texto aparecerá como ele realmente é
  9. 9. CSRF - Cross-Site Request Forgery  Comandos não autorizados são transmitidos de um usuário que confia no website.  Ele executa scripts que copiam informações de cookies armazenados do usuário de outros sites para executar ações como postagens, requisições, executar login, etc.
  10. 10. CSRF - Cross-Site Request Forgery  Como prevenção podemos:  Trabalhar com token nos formulários.  Limitar tempo de vida dos cookies e sessões.  Etc.
  11. 11. SQL Injection  Consiste na inserção de instruções SQL dentro de uma consulta através da manipulação das entradas de dados de uma aplicação.
  12. 12. SQL Injection  Vamos imaginar uma aplicação com um formulário que recebe um nome de usuário, e depois faz uma consulta ao banco de dados:  $sql = "select * from usuarios where nome = '" . $_POST['txt_nome'] . "'";
  13. 13. SQL Injection  O comando SQL é montado a partir de componentes numéricos. Exemplo: pesquisa por uma chave primária de um registro. Neste caso, o atacante também pode tentar manipular o conteúdo de forma a injetar código adicional na string SQL.  $sql = "select * from usuarios where codigo = " . $cod ;
  14. 14. SQL Injection  O PHP fornece uma série de funções para este tratamento, são as funções de escape de caracteres. A maioria dos bancos suportados pelo PHP tem esta função. MySQLi - mysqli::real_escape_string MySQL - mysql_escape_string Postgre - pg_escape_string SQLite - sqlite_escape_string
  15. 15. SQL Injection – Simulando um ataque Primeiro passo - Número de campos da tabela atual  1 ORDER BY 1,2,3... Segundo passo - Descobrir nomes das tabelas  null union all select 1,2,group_concat(table_name) from information_schema.tables where table_schema=database()-- Terceiro passo - Descobrir nomes dos campos  null union all select 1,2,group_concat(column_name) from information_schema.columns where table_schema=database()-- Quarto passo - Descobrir nomes dos usuários  null union all select 1,2,usu_login FROM usuarios-- Quarto passo - Descobrir senhas dos usuários  null union all select 1,2,usu_senha FROM usuarios--
  16. 16. File Upload  Permite que o usuário possa subir qualquer tipo de arquivo para o seu servidor, possibilitando assim a exclusão de arquivos, captura de dados entre uma série de possíveis problemas que você pode ter.
  17. 17. File Upload  Para prevenir, se faz necessário a validação não somente da extensão do arquivo, como também o seu conteúdo.
  18. 18. PHP Injection  Permite a inclusão (include) de arquivos remotos diretamente em seus sistemas, dessa forma ele conseguirá executar scripts dentro de seu servidor.
  19. 19. PHP Injection  Para prevenir você poderá bloquear o include através de URLs no arquivo php.ini, para isso basta configurar a seguinte opção allow_url_include = Off.
  20. 20. Boas práticas de programação para tornar o seu sistema mais seguro
  21. 21. Não passar informações pela URL  Um erro comum de programadores iniciantes é enviar informações através da url utilizando o método GET.  Por padrão, o formulário utiliza o método GET, é preciso configurá-lo através do atributo method=“POST”.
  22. 22. Validações do lado do servidor ou do lado do cliente? Validação do lado do cliente.  O usuário pode interferir nas validações.  Valida em tempo real.  Alguns navegadores não suportam JavaScript. Validação do lado do servidor.  O usuário não consegue interferir nas validações.  Só valida após enviar os dados do formulário.  Funciona em todos os navegadores já que a validação ocorrerá no servidor independente de navegador.
  23. 23. Spoofing de formulários  O Spoofing ocorre quando alguém faz uma postagem de um de seus formulários de algum local inesperado.  Técnica mais utilizada para a prevenção do ataque é o uso de um token.  No momento que é exibido o formulário, um token é gerado e armazenado na sessão, quando o formulário é enviado, é confirmada se a chave enviada é a mesma gravada na sessão.
  24. 24. Mudar o nome da sessão  Quando não informado o nome da sessão, o PHP cria automaticamente com o nome PHPSESSID  Esse nome padrão torna a sessão do usuário vulnerável.  O ideal é que se altere o nome para características próprias de cada usuário como por exemplo Código + Nome + Data d
  25. 25. Verificar origem dos dados  Caso você utilize uma versão mais antiga do PHP, de quando o register_globals ainda funcionava.  O register_globals criava variáveis automaticamente a partir dos arrays superglobais $_GET, $_POST, $_SESSION, $_COOKIE, $_SERVER.
  26. 26. Limitar o tempo da sessão  Embora o usuário tenha saído do site ou até mesmo fechado o navegador, dependendo da forma como está configurada, a sessão permanecerá ativa no servidor.  O ideal é que se limite o tempo da sessão.  O ideal também é que você trate através de eventos para que ao usuário sair do site, aquela sessão automaticamente seja excluída.
  27. 27. Validar upload de arquivos  Usuários maliciosos podem subir arquivos que podem ser executados no servidor e trazer algum dano.  Para evitar esse tipo de ataque, você precisa validar não somente a extensão do arquivo, mas também o conteúdo do mesmo.
  28. 28. Use require ao invés de include  O include, como o próprio nome diz inclui um arquivo dentro de uma página, mas isso não torna obrigatória a presença do mesmo, ou seja, se por algum motivo o arquivo não exista, ele continua com a execução do script.  Já o Require, torna obrigatória a inclusão do arquivo, assim, se por algum motivo o arquivo não existir, ele bloqueia a execução do script.
  29. 29. Verificar nível de acesso em funcionalidades  Não adianta em um sistema usar milhões de ifs e tratar apenas os menus.  O usuário conseguirá acessar qualquer página através do link direto.  Forma correta de se validar nível de acesso é bloquear todas as funcionalidades para todos os usuários e só liberá-las apenas para os usuários autorizados.  Forma errada de se validar nível de acesso, liberar todas as funcionalidades para todo mundo e bloqueá-las apenas para os usuários não autorizados.
  30. 30. Filtrar todas as entradas de dados  Nunca confie no usuário.  Filtre todas as entradas de dados para saber se realmente é o que o seu sistema espera.  O PHP disponibiliza uma função interessante para fazer essa validação ou saneamento, essa função é a filter_input();
  31. 31. Filtrar todas as saídas de dados  Sempre quando for exibir dados, converta os caracteres para realidade HTML.
  32. 32. Monitore os erros de senha  Em caso de mais de três tentativas de senha incorreta, bloqueie o IP de origem, adicione um Captcha como validação adicional, isso dificulta ataques de forca bruta.
  33. 33. Trabalhe formulários com Captcha  Adicione um Captcha como validação adicional, isso dificulta ataques de forca bruta.
  34. 34. Permissões em pasta  Restrinja o acesso às pastas do servidor, ou seja, permissões de execução e escrita somente em pastas apropriadas.
  35. 35. Não armazenar senha em texto puro na sessão  Senhas não devem ser armazenadas sem “cifragem”, sempre armazene senhas criptografadas, assim estaremos protegendo também nossos usuários, numa eventual invasão ao banco de dados.
  36. 36. Não armazenar senha em texto puro no banco de dados Hackers conseguem senhas (em texto puro!) da Microsoft Store indiana http://www.gemind.com.br/11654/microsoft-store-india-senhas-hackers/
  37. 37. PHP Injection  Muitas vezes quando se faz include de forma dinâmica, ou seja, com a página sendo passada através de variáveis, abre-se uma brecha enorme para ataques, pois o usuário mal intencionado pode alterar o valor dessa variável para um arquivo externo que poderá ser executado dentro de seu servidor.  Como prevenção podemos desabilitar no arquivo php.ini o include de arquivos através de url allow_url_include ou simplesmente validar se o arquivo existe is_file em nosso servidor.
  38. 38. Requisições JSON  Requisições que retornam JSON são ótimas de ser utilizadas em nossos sistemas, porém, é de extrema importância que haja uma validação de onde vem essa requisição.  Como se trata de uma requisição, eu não preciso está dentro do servidor para executar a mesma e isso juntamente com um arquivo mal configurado pode permitir que sejam roubadas informações de seus sistemas.
  39. 39. Use Framework  Por fim, é altamente recomendável que você utilize frameworks para desenvolvimento, pois, estes possuem equipes de programadores altamente experientes que já pensaram nisso tudo para você.
  40. 40. Usando o php.ini para tornar o PHP mais seguro
  41. 41. Não exiba erros  No ambiente de produção trabalhe com erros na forma de logs.  Mostrar erros na t  ela pode revelar informações importantes do teu sistema. display_errors=Off log_errors=On error_log=/var/log/httpd/php_scripts_error.log
  42. 42. register_globals  Cria variáveis automaticamente a partir dos arrays superglobais $_GET, $_POST, $_SESSION, $_COOKIE, $_SERVER
  43. 43. register_globals  Desabilitada por padrão a partir da versão 4.2.0 do PHP  Considerada obsoleta a partir da versão 5.3  Não está mais presente a partir da versão 5.4 Register_globals=Off
  44. 44. Desabilite o upload de arquivos  Caso seu sistema não tenha upload de arquivos, desabilite a funcionalidade para que nenhum mal intencionado possa estar subindo arquivos indevidos para o seu servidor. file_uploads=Off
  45. 45. Desabilite a execução remota de códigos  Dessa forma seu sistema não permite que sejam incluídos arquivos externos. allow_url_fopen=Off allow_url_include=Off
  46. 46. Controle o tamanho das requisições POST  Caso seu sistema não trabalhe com muita transferência de dados, não tem necessidade de ter um tamanho alto para a transferência dos mesmos. post_max_size=1K
  47. 47. Controle os recursos que um script pode consumir  Dessa forma você evita o estouro de memória em seu servidor, caso um usuário descubra que existe algum script causando estouro de memória ele pode se aproveitar dessa falha para deixar seu servidor indisponível. max_execution_time = 30 max_input_time = 30 memory_limit = 40M
  48. 48. Desabilitando funções perigosas do PHP  Existem algumas funções que se você não for utilizá-las em seu servidor você deveria desabilitá-las, como é o caso do exec que permite que você execute comandos diretamente para o sistema operacional. disable_functions =exec,passthru,shell_exec,system,proc_open, popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
  49. 49. Para finalizar NENHUM SISTEMA É 100% SEGURO.
  50. 50. Dúvidas???
  51. 51. Referências http://www.cyberciti.biz/tips/php-security-best-practices-tutorial.html http://blog.thiagobelem.net/principais-falhas-de-seguranca-no-php/ http://imasters.com.br/infra/seguranca/seguranca-em-aplicacoes-web-com-php/ http://www.softwarelivre.gov.br/palestras-tecnicas-cisl/palestras-tecnicas-cisl/ apresentacaosegurancaphp.pdf http://blog.thiagobelem.net/principais-falhas-de-seguranca-no-php/ http://www.linhadecodigo.com.br/artigo/673/php-programando-com-seguranca.aspx http://www.pedropereira.net/hardening-php-seguranca-hack/
  52. 52. Flávio M. de Souza flavio@inovup.com.br (85) 8667-2972 Contato

×