| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
Eu estava lendo o livro: Pro PHP Security (Chris Snyder and Michael Southwell) - Apress. É no passado mesmo, eu não li o resto, pois analisando os códigos no começo do livro encontrei algumas falhas, incluindo problemas de design e arquitetura.
1 - Uso de variáveis Super Globals do Php sem sanitização - página 77
<form action="<? $_SERVER['SCRIPT_NAME']" method="post">
<p>
username: <input type="text" name="userName" size="32" /><br />
username: <input type="password" name="userPassword" size="16" /><br />
<input type="submit" name="submit" value="login" />
<p>
</form>
Estas variáveis como qualquer input podem ser manipuladas, o que torna este form vulnerável a XSS (Cross Site Scripting).
2 - Implementação inadequada de salt - página 78
O livro começou bem neste ponto, sugerindo a utilização de salt como recurso para fortalecer os hashs de senha. Mas, como geralmente acontece, a idéia é boa mas a implementação é ruim.
$salt = time();
$hashedPassword = sha1($userPassword . $salt);
O código apresentado sugere gerar um hash no momento da criação baseado em time(). Como comparar este resultado na hora de cada login se o time() tem um valor que não é fixo? Eles sugerem armazenar um hash em um campo na mesma tabela de usuários, junto com o hash da senha.
$query = 'INSERT INTO LOGIN VALUES (' . dbSafe($userName) . ', ' . dbSafe($hashedPassword) . ',' .dbSafe($salt) . ')';
Geralmente o comprometimento dos hashs de senhas acontece por falhas de SQL Injection, portanto se o usuário mal intencionado pega o hash e salt numa paulada só e consegue reverter a senha (óbvio que aqui estamos falando de senhas com baixa complexidade e que podem ser revertidas por base de hashs pré-compilados).
Este é o típico caso onde existe a exceção, se em código compilado e local não é recomendado a senha hard-coded, neste caso em linguagem interpretada como php, asp é mais seguro que quardar no banco, pois para comprometer o salt ele precisa ter acesso aos diretórios do servidor de aplicação.
As páginas seguintes são uma enrolação danada e nada de código, nem vulnerável. Ai fiquei curioso para ver quais eram as sugestões para controles de sessão,uma falha comum em aplicações.
3 - Controle inadequado contra CSRF/XSRF (Cross Site Request Forgery) - Página 402
<?php
$referrer = $_SERVER['HTTP_REFERER'];
if (!empty($referrer)) {
$uri = parse_url($referrer);
if ($uri['host'] != $_SERVER['HTTP_HOST']) {
exit("Form submissions from $referrer not allowed.");
}
}else {
exit('Referrer not found. Please <a href="' . $_SERVER['SCRIP_NAME'] . '">try again</a>.');
}?>
O referer é um recurso do HTTP que informa de onde a requisição está vindo, mas como é coletado usando uma variável Super Global, pode ser manipulado como analisamos no início do post na falha número 1. Controles efetivos para CSRF/XSRF são token de sessão com boa entropia e solicitar uma nova autenticação em operações críticas.
Para forjar um referer e bypassar este controle pode ser usado scripts que geram um referer, exemplo:
<META HTTP-EQUIV="refresh" CONTENT="0;url=[url a ser atacada];">
Não preciso nem falar que não li o livro todo. Não recomendo, o livro não acrescenta praticamente nada em segurança e ainda comete erros grosseiros.
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
Organizando minhas apresentações eu encontrei esta apresentação que eu fiz no Tech-Ed 2007. A idéia da palestra era comparar, mostrar as diferenças entre o OWASP Top 10 2004 e o 2007 e também apresentar alternativas para tratamento das vulnerabilidades apresentadas utilizando os recursos da plataforma .Net.
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
Palestrar na H2HC é sempre uma grande experiência, além de encontrar vários amigos que reencontro nestes tipos de eventos, ainda tenho a possibilidade de conversar discutir sobre assuntos pouco discutidos em meios tradicionais. Este ano eu fiz uma apresentação explorando a técnica Fuzzy para identificar falhas em aplicação Web. Encontrar um auditório cheio as 8hrs. da manhã de um Domingo com chuva e pós a festa da conferência, foi sensacional. Obrigado a todos. Uma pena que a apresentação é bastante voltada para interação, discussão e apresentação de demonstrações sobre o tema, não gosto de muitos slides. ;-(
Mas aguardem, em breve os vídeos serão disponibilizados.
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
Há pouco mais de um ano atrás quando iniciamos as conversas para organizar um evento OWASP no Brasil, as dificuldades não foram poucas, pois os custos não são baixos para realizar um grande evento como a comunidade merece.
Foi então que o meu amigo Lucas Ferreira, como bom mineiro, de repente sem grande alarde ele conseguiu um apoio da Câmara dos Deputados e do TI Controle e conseguiu viabilizar um evento sensacional.
Passado o trabalho da organização, chegou a tão aguarda hora. No dia 27 e 28 aconteceram os Mini-Cursos, muitos inscritos e conteúdo de boa qualidade. Dia 29 e 30 aconteceram as palestras. Após a abertura do evento com a participação de representante da OWASP e políticos, Gary McGraw entrou em cena e deu um show, não, ele não é nenhum astro da música, mas sim um dos maiores especialistas em segurança em desenvolvimento e cativou a platéia como poucos.
Passado o show de Gary, os outros palestrantes manteram o altíssimo nível do evento. Até o Ulisses Castro que foi convocado as pressas, pois 3 palestrantes internacionais tiveram sintomas da gripe H1N1, assumiu o compromisso e deu um show com uma palestra bastante técnica e 100% prática.
Todas as palestras podem ser conferidas nos vídeos disponibilizados pela Câmara:
http://www.owasp.org/index.php/AppSec_Brasil_2009_%28pt-br%29#tab=Arquivos_das_Apresenta.C3.A7.C3.B5es
A AppSec 2010 já está confirmada no Auditório da CpQD e contamos com o apoio da comunidade para realizar mais um grande evento.
Got OWASP?
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
A Microsoft disponibiliza um ambiente onde é possível fazer laboratórios explorando as seguintes vulnerabilidades:
Para explorar os laboratórios online siga estes passos:
1 - acesse o seguinte endereço: http://www.microsoft.com/click/hellosecureworld/default.mspx
2 - Clique no leitor biométrico para entrar nos laboratórios
3 - Instale os plugins necessários
4 - Clique em The V-Lab no lado inferior direito
5 - Escolha o teste que deseja explorar
6 - Enjoy!
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
Nos dias 28 e 29 acontece a sexta edição da Hackers to Hackers Conference. Eu estarei apresentando uma palestra sobre Fuzzing em aplicações Web. Confira os detalhes da apresentação.
Playing Web Fuzzer
A palestra irá mostrar as vantagens e técnicas usadas para identificar falhas em aplicações WEB usando Fuzzer. Para isto serão feitas demonstrações utilizando ferramentas como WebSlayer e JBroFuzz e os recursos do OWASP Fuzzing Code Database Project.
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
Nos dias 27, 28 e 29 Novembro estarei na Php Conference Brasil 2009 apresentando uma palestra sobre PHPIDS, confira os detalhes da apresentação.
Trilha: Segurança
Título: Protegendo aplicação php com PHPIDS
Nível: Avançado
Resumo: Trate ataques SQLi, XSS, dentre outros que compõem ranking de vulnerabilidades como o Top 10 da OWASP (Open Web Application Security Project) em aplicações web desenvolvidas em php usando o PHPIDS.
Descrição: Além de processos e técnicas para desenvolver código seguro é necessário investir em soluções de respostas a ataques. Estas respostas geralmente são realizadas e suportadas por soluções de WAF (Web Application Firewall). O PHPIDS é um Intrusion Detection System e irá identificar e evitar os principais ataques, pode ser integrado a solução como HTML Purifier e Mencached.
Pré-Requisitos: Conhecimentos de php e noções básicas de segurança em aplicações web.
Referências:
http://php-ids.org/
http://htmlpurifier.org/
http://www.danga.com/memcached/
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
Conferência internacional de Segurança de Aplicações, organizada e promovida pela comunidade TI-controle e pelo Centro de Informática da Câmara dos Deputados, em parceria com o OWASP, Capítulo brasil, e com apoio da Universidade de Brasília (UnB).
O Centro de Informática da Câmara dos Deputados e a Comunidade TI-Controle convidam a todos a participarem da Conferência Internacional de Segurança de Aplicações (AppSec Brasil 2009), que ocorrerá na Câmara dos Deputados (Brasília, DF) de 27 a 30 de outubro de 2009.
Haverão mini-cursos nos dias 27 e 28 de outubro, seguidos de sessões plenárias de trilha única nos dias 29 e 30 de outubro de 2009.
Keynotes
Dr. Gary McGraw, CTO da Cigital: O Modelo de Maturidade Building Security In (BSIMM)
Jason Li, Aspect Security: Ágil e Seguro: É possível fazer os dois?
Dinis Cruz, OWASP Board: Apresentação do Projeto OWASP
Kuai Hinojosa, NY University e OWASP: Implementando Aplicações Web Seguras Usando Recursos do OWASP
Palestras
A Conferência contará com palestras técnicas que tratarão diversos aspectos de Segurança de Aplicações. Os temas incluem:
Mini-cursos
A Conferência contará também com 5 mini-cursos:
Local
A Conferência ocorrerá na Câmara dos Deputados, em Brasília. As plenárias serão no auditório Nereu Ramos, no Anexo II e os mini-cursos serão no Centro de Formação, Treinamento e Aperfeiçoamento.
Inscrições
A participação na Conferência será gratuita, mas, devido à limitação de lugares, será necessário inscrever-se previamente.
As inscrições estarão abertas a partir do dia 29/10/2009 na URL: http://www.camara.gov.br/appsecbrasil2009
Informações
Para maiores informações, favor consultar os sites abaixo ou enviar email para appsec.brasil@camara.gov.br
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
Devido a demandas por adequação a padrões, o processo de segurança em desenvolvimento de software é hoje um assunto em alta. Isto me preocupa, afinal, de onde surgiram tantos especialistas? Cheguei a comentar com um amigo: tem mais especialista que aplicação vulnerável.
São inúmeras palestras e promessas milagrosas. Pessoas citam os touchpoints de Gary McGraw e o processo de SDL da Microsoft como se fossem íntimos e tenham implementado em vários cenários e organizações, sem contar a falácia da ISO/IEC 15.408, que muitos acreditam cegamente ser uma proposta para segurança em desenvolvimento.
Tudo isto para buscar ser "cool" e/ou tentar abocanhar uma fatia de um mercado que vem surgindo. A pesquisa, o estudo e disseminação de conhecimento são super importantes, mas que, os que se aventuram pelo tema tenham convicção de uma coisa: não é nenhum pouco simples e fácil implementar e ter bons resultados com processos de SDL.
Wagner, você está traindo "o movimento"? Você não acredita mais em segurança em desenvolvimento?
Muito pelo contrário, acredito e muito, mas sei muito bem o caminho a ser percorrido e as dificuldades que encontrarei. Há pelo menos cinco anos eu estudo e vivencio como consultor, a realidades das organizações frente à segurança de software.
Muitas organizações não conseguem justificar mais uma área de desenvolvimento interno, como irão justificar o investimento em segurança de software? Os sábios logo dirão: Cobre do fornecedor o processo de SDL.
Sim, você pode cobrar do fornecedor, só não se assuste se o seguinte cenário lhe for apresentado: Eu cobro R$ 500,00 por hora de desenvolvimento, com segurança eu preciso incluir um pequeno adicional, fica R$ 600,00 por hora.
Como diria o Zé: não existe almoço grátis! Alguém tem que pagar a conta.
Como equacionar esta dificuldade de justificar e conscientizar as empresas a investir recursos em segurança em desenvolvimento?
Não existe resposta pronta, sugestões como: conscientize, treine, mostre o ROI, etc... Servem para uns e não servem para outros. Se eu pudesse sugerir algo, eu começaria pelo básico, não acredite em soluções milagrosas, não acredite em quem lhe promete entregar o que você não conseguiu a vida toda em um mês de trabalho e ao preço de um almoço.
Um processo como este leva tempo e no mínimo os seguintes aspectos devem ser considerados:
Com estes pontos você terá muito trabalho, a parte fácil é desenhar os fluxos e escrever cartilhas e procedimentos.
[Update - 25 de Setembro] O Fernando Cima escreveu um post com excelentes referências para quem deseja implementar um SDL: Retorno Sobre o Investimento de um Processo Seguro de Desenvolvimento
Comments(24)