Como o prometido, estou realmente estudando PHP e deixando o ASP, reflexo disso é uma mudança no conteúdo do O Desenvolvedor, que está ficando recheado de posts sobre PHP – com a ajuda do Chris e do Furst.
Depois dos slides sobre as Novidades do PHP 5, hoje trago mais slides, desta vez para falar de Segurança. Essa foi a apresentação do Rafael Jaques no Tchê Linux 2009.
Construindo uma Aplicação PHP à Prova de Balas
A apresentação fala dos tipos de ataque mais comuns e apresenta soluções e boas práticas para elevar a segurança das aplicações desenvolvidas.
E para quem não conseguir ver a apresentação no SlideShare, segue a versão em texto:
- Construindo uma aplicação PHP à Prova de Balas
- Rafael Jaques
- TcheLinux – Porto Alegre – 14/11/09
- “ Buscai primeiro o reino do Senhor e a sua justiça, e todas as demais coisas vos serão acrescentadas” (Mateus 6.33)
- Pauta
- Um pouco sobre segurança
- Conhecendo os meios de ataque
- Outros tipos de ameaça
- Mais alguns cuidados
- Perguntas
- Um pouco sobre segurança 1
- O que é segurança?
- Segurança baseia-se em três pontos:
CONFIDENCIALIDADE INTEGRIDADE DISPONIBILIDADE
- O que é segurança? Não se iluda. Não existem aplicações 100% seguras. Não ouse dizer isso… Você poderá ter sérios problemas.
- O quão segura deve ser a sua aplicação? Você deve encontrar um equilíbrio entre a segurança e a usabilidade do seu sistema. Crie um sistema com pouca segurança e ele será invadido . Crie um sistema com muita segurança e ele será impossível de usar .
- O quão segura deve ser a sua aplicação? Evite investir esforços onde não é necessário. Sempre revise o que você projetou.
- Os custos que envolvem uma aplicação segura Aplicações seguras tendem a custar caro… Aplicações não seguras tendem a custar mais caro ainda…
- Os custos que envolvem uma aplicação segura
- Maior tempo de projeto e pesquisa
- Programação extendida
- Testes mais minuciosos
- Maior uso de hardware
- Maior uso de banda
- Treinamento de pessoal interno
- Treinamento do usuário
Entre os custos envolvidos no desenvolvimento da aplicação, temos os seguintes pontos:
- não sacrifique a usabilidade do projeto
- Conhecendo os meios de ataque 2
- Quais os tipos de ataque que posso sofrer?
- XSS (Cross-site Scripting)
- SQL Injection
- Session Hijacking
- Cookie Theft
Existem diversos tipos de ataque através da internet. Eis alguns:
- Brute Force
- Rainbow Table
- Password Sniffing
- Entre outros…
- XSS Cross-site Scripting O que é? Injeção de código arbitrário em uma página. Como ocorre? Geralmente através de brechas em formulários onde os dados enviados ao servidor não são devidamente filtrados.
- XSS Cross-site Scripting Exemplo
- XSS Cross-site Scripting Exemplo
- XSS Cross-site Scripting Como evitar Existem funções prontas no PHP para filtrar strings. Utilizando-as, além de evitar um XSS, você garante que o usuário conseguirá expressar o que realmente intentou.
- XSS Cross-site Scripting Como evitar
- Funções que você pode utilizar:
- htmlspecialchars()
- htmlentities()
- filter_input()
Leia mais sobre XSS: http://tinyurl.com/mais-sobre-xss
- SQL Injection O que é? Injeção de código SQL arbitrário dentro de uma consulta legítima. Como ocorre? Na maioria das vezes a injeção de código SQL se dá a partir de formulários não filtrados, em que os dados recebidos vão diretamente para dentro da consulta.
- SQL Injection Exemplo
- SQL Injection Exemplo 1" OR 1="1
- SQL Injection Exemplo fulano"# ou fulano" —
- SQL Injection Como evitar Novamente… Filtrando os dados enviados pelo usuário é possível evitar que seja injetado código dentro do seu SQL.
- SQL Injection Como evitar
- Funções que você pode utilizar:
- addslashes()
- mysql_real_escape_string()
Leia mais sobre XSS: http://tinyurl.com/mais-sobre-sql-injection
- Session Hijacking O que é? Quando o invasor obtém acesso à sessão de um usuário autenticado. Como ocorre? Sempre que os dados do cliente são armazenados em sessão é gerado um ID. Caso alguém o descubra, poderá navegar pelo site como se fosse o usuário real.
- Session Hijacking Atenção… Hoje, com as configurações padrão do PHP é bem pouco provável que você sofra um ataque de roubo de sessão no seu site. Para tanto você deve estar atento às seguintes configurações:
- Session Hijacking Atenção… session.use_cookies session.use_only_cookies
- Session Hijacking Exemplo algumapagina.php?PHPSESSID=1234
- Session Hijacking Como evitar Nunca confie 100% no ID de sessão recebido. Você pode fazer algumas verificações redudantes, como comparar o IP e o User-Agent. Em casos mais vitais você pode sugerir ao usuário que utilize cookies, intruindo-o e falando da sua importância para uma navegação mais segura no site. Leia mais sobre Sess. Hijacking: http://tinyurl.com/mais-sobre-sess-hijacking
- Cookie Theft O que é? A tradução literal é “Roubo de Cookie”. Na verdade a literal mesmo é “Roubo de Biscoito”. 😛 Trata-se capturar cookies na máquina da vítima e utilizá-los para acessar o local desejado. Como ocorre? O roubo de cookie pode possuir duas naturezas: XSS e vulnerabilidades no próprio browser.
- Cookie Theft Como evitar O script que foi apresentado anteriormente no exemplo de XSS é responsável por roubar um cookie. Atualmente não são muito comuns falhas de browsers que permitam o roubo de cookies, mas no passado houveram muitos .
- Cookie Theft Como evitar No site do PHP Security Consortium [1] você pode consultar o resumo da newsletter da SecurityFocus [2], que possui sempre anúncio de novas vulnerabilidades encontradas. A partir disso você pode conscientizar os seus usuários caso perceba que os mesmos utilizem um browser vulnerável. [1] http://phpsec.org/projects/vulnerabilities/securityfocus.html [2] http://securityfocus.com/vulnerabilities
- Brute Force Attack O que é? O ataque por força bruta baseia-se na busca exaustiva da informação procurada, através de tentativa e erro com todas as possibilidades existentes. Como ocorre? O usuário mal intencionado acessa o formulário no qual irá tentar o ataque e utiliza um programa, estipulando uma cadeia de caracteres e um tamanho máximo para a frase. O programa irá tentar todas as combinações possíveis até que uma dê certo.
- Brute Force Attack Atenção… Este tipo de ataque é bastante semelhante ao Ataque de Dicionário . A diferença é que o dicionário esgota suas possibilidades mais rápido utilizando apenas palavras existentes e senhas comuns.
- Brute Force Attack Como evitar Existem dois meios bastante comuns de evitar este tipo de ataque: limite de tentativas e limite de tempo entre uma tentativa e outra. Leia mais sobre Sess. Hijacking: http://tinyurl.com/mais-sobre-brute-force
- Rainbow Table O que é? Semelhante ao ataque de força bruta, porém diretamente a um hash (md5, sha1, etc). Como ocorre? É a mistura de um ataque de força bruta com um ataque de dicionário. De posse do hash, o invasor utiliza este ataque para testar combinações que possam gerar o hash procurado até que se chegue à resposta correta.
- Rainbow Table Exemplo Caso o usuário malicioso obtenha acesso aos hashs de senha (apenas visualizar), ele ainda assim terá de descobrir a senha que está ali. O problema está em confiar apenas na criptografia de hashs comuns como md5 e sha1 .
- Rainbow Table Exemplo Vamos pegar como exemplo a palavra abacaxi . O hash md5 referente é 4b96d5c1ff312eea069ddc760794963d . Supondo que obtemos este hash do banco de dados, basta digitá-lo no Google e em alguns segundos estamos prontos.
- Rainbow Table Exemplo
- Rainbow Table Como evitar A técnica mais utilizada e que reduz drasticamente a chance de este ataque dar certo, é “temperar” suas senhas. Ao inserir uma string arbitrária antes de criptografar a senha, este ataque torna-se praticamente inefetivo. À essa string arbitrária damos o nome de salt .
- Rainbow Table Como evitar Digamos que seu salt será rocknroll . Ao aplicar a criptografia na sua string, você deverá concatenar com o seu salt. md5("rocknroll" . $senha) Se a senha for abacaxi teremos o seguinte hash: 0a5cefae5c742e8a914f486db9ea45ef . E pra esse o Google não tem resposta! 😉 Leia mais sobre Rainbow Table: http://tinyurl.com/mais-sobre-rainbow-table
- Password Sniffing O que é? Este ataque baseia-se em capturar na rede um pacote descriptografado com os dados de autenticação de algum usuário. Como ocorre? Monitorando a rede pode-se visualizar todos os pacotes. Todas as requisições via POST e GET normalmente estão abertas à visualização.
- Password Sniffing Como evitar Proteja a sua conexão com SSL. Utilizando este protocolo você irá assegurar que a comunicação entre o cliente e o servidor, mesmo que interceptada, não possa ser decifrada. Utilize sempre o POST (por ser uma forma mais segura) e lembre-se de sempre colocar o protocolo HTTPS .
- Password Sniffing Como evitar Você pode também redirecionar o usuário para a página de login (o formulário em si) sempre com HTTPS. Não existe nenhuma razão técnica para isso, apenas psicológica. O usuário costuma sentir-se mais seguro quando está colocando sua senha em uma página com cadeado. 🙂 Leia mais sobre Sniffing: http://tinyurl.com/mais-sobre-sniffing
- Outros tipos de ameaça 3
- Outros tipos de ameaça
- Includes
- Abuso de formulários
- Diretrizes (register_globlals, display_errors, etc)
- Exposição do phpinfo
Existem outras ameaças que vão além da alçada do programador. Outras podem ser evitadas se alguns cuidados forem tomados.
- Outros tipos de ameaça
- A inclusão de arquivos via include() e require() , embora muito útil, pode ter consequencias muito ruins se não utilizada corretamente.
- É muito comum a inclusão de arquivos recebidos via URL sem que a string seja filtrada.
Includes
- Outros tipos de ameaça
- Outro ponto que você deve estar atento é quanto ao uso de extensões que o seu servidor web não “conheça”.
- Evite extensões do tipo .inc . Se for fazê-lo, prefira algo do tipo meuarquivo.inc.php .
Includes
- Outros tipos de ameaça
- Funções que você pode utilizar para filtrar os dados recebidos e evitar um ataque de XSS ou a exposição do seu código:
- basename()
- file_exists()
Includes
- Outros tipos de ameaça
- Esteja sempre atento ao uso de seus formulários.
- O maior erro que você pode cometer é colocar os possíveis e-mails dentro do seu formulário.
- Isto abrirá uma brecha em que o usuário mal intencionado poderá inserir endereços arbitrários e utilizar o seu formulário como disseminador de SPAM.
Abuso de formulários
- Outros tipos de ameaça
- Algumas diretrizes, quando bem configuradas, podem aumentar a segurança da sua aplicação.
- register_globals
- display_errors
- log_errors
Diretrizes
- Outros tipos de ameaça
- É incrível o número de páginas espalhadas pela web que possuem um arquivo phpinfo.php em sua raiz.
- A primeira ação tomada por um usuário mal intencionado é verificar a existência desse arquivo e de variantes do seu nome como info.php , php.php , etc.
Exposição do phpinfo
- Mais alguns cuidados 4
- Mais alguns cuidados
- Lei do menor privilégio (SQL)
- Ocultação de cabeçalhos HTTP
- Examine sempre os logs
Existem mais alguns cuidados que você pode tomar para assegurar que será mais difícil conseguir realizar um ataque bem sucedido contra a sua aplicação.
- Mais alguns cuidados Lei do menor privilégio (SQL) Sempre que possível, crie mais de um usuário para acesso ao banco de dados. Não é uma boa idéia utilizar o usuário administrador (root) para acessar o banco através do site.
- Mais alguns cuidados Lei do menor privilégio (SQL) Crie usuários que só tenham permissão de leitura e usuários que só tenham permissão de escrita . Caso, devido a algum infortuno do destino, alguém consiga invadir o seu sistema terá apenas permissões limitadas.
- Mais alguns cuidados Ocultação de cabeçalhos HTTP Sempre que você acessa uma página, o servidor envia cabeçalhos HTTP para o seu browser. Dentro deste cabeçalhos podemos encontrar algumas informações interessantes.
- Mais alguns cuidados Ocultação de cabeçalhos HTTP
- Mais alguns cuidados Ocultação de cabeçalhos HTTP Dentro do arquivo httpd.conf do Apache você pode alterar o nível de exposição da versão das aplicações instaladas no seu servidor. Para tanto, você deve alterar a diretiva ServerTokens .
- Mais alguns cuidados Ocultação de cabeçalhos HTTP
- ServerTokens valor_desejado
- Prod: Apache
- Major: Apache/2
- Minor: Apache/2.0
- Min: Apache/2.0.59
- OS: Apache/2.0.59 (Unix)
- Full: Apache/2.0.59 (Unix) PHP/5.2.6
- Mais alguns cuidados Examine sempre os logs Esteja atento aos logs e, se possível, utilize ferramentas de monitoramento de tráfego (como AWStats e Webalizer) para analisar possíveis tentativas de ataque à sua página.
Quer ler mais sobre PHP?