Palestra no GTS 15

No próximo dia 14 de Maio estarei palestrando no GTS! O evento é realizado pelo Grupo de Trabalho em Segurança de Redes, do CGI.Br e é gratuito.

A palestra irá acontecer as 14 hrs. Irei apresentar as principais falhas e técnicas para correções em aplicações baseadas em Adobe Flash.

Mais informações sobre o evento podem ser conferidas aqui: https://gts.nic.br/reunioes/gts-15

Aguardo vocês lá!

Versão 5 do SDL (Microsoft Security Development Lifecycle)

Acaba de ser lançado uma nova versão do guia da microsoft para implementação de um processo de segurança em desenvolvimento. Neste post do blog do SDL você pode ter mais detalhes das alterações e aqui baixar o arquivo.

O que eu mais gostei de ver no guide foram algum pontos que sempre mencionamos em análises e que geralmente não são tratados por desenvolvedores:

Página 23 - Strong log-out and session management

Proper session handling is one of the most important parts of Web application security. At the most fundamental level, sessions must be initiated, managed, and terminated in a secure manner. If a product employs an authenticated session, it must begin as an encrypted authentication event to avoid session fixation.

•    A session identifier/token must never be transmitted via the URL to avoid side-jacking via the referrer header or browser history.
•    All session data must be maintained on the server, not the client, to avoid tampering.
•    Sessions must be completely terminated on the server side via logout and timeout mechanisms. When multiple sessions are tied to a single authentication event, all of the sessions tied to that event must be terminated by logout/time-out.
The following items must be met as part of the exit criteria for this recommendation:
•    When multiple sessions are tied to a single user identity, they must be collectively terminated on the server side at timeout or logout.
•    Authentication events must invalidate unauthenticated sessions and create a new session identifier.
•    Logout functionality is available on every page.
•    Session state, outside of a single identifier, is maintained on the server and not accepted from the user (including via cookie or header).
•    Session tokens are not present in the URI.
•    Timeout functionality is present and timeout thresholds are documented along with the rationale.

Página 28 - Avoid EXEC in stored procedures

Using stored procedures helps to mitigate the SQL injection threat to a great extent since type checking is available for parameters. If the attacker supplies input that does not match the type constraints, the stored procedure will throw an exception. In the vast majority of the cases, this exception should be properly handled within the application.
However, if the stored procedures perform string manipulation in their code and then execute that query using the "exec @sql" construct, incorrect handling of user input can produce the same SQL injection vulnerability as would be seen at the application layer.

EXEC and EXECUTE are prohibited in T-SQL stored procedures except in the case where they are used to call other stored procedures. Using EXEC to call ad-hoc SQL is not allowed. For example, the following is allowed:

EXEC('MyStoredProc')

But the following is prohibited:

EXEC('SELECT * FROM Foo')

Note that there are some situations in which it is impossible to write a parameterized T-SQL query. For instance, you cannot specify table names or column names as parameters. Similarly you cannot parameterize the operands of some operators, such as the IN operator.
If your product falls into one of these situations or any other case in which you believe the only reasonable option is to use EXEC with ad-hoc SQL, investigate an alternative design or implement appropriate escaping logic to mitigate SQL injection attacks.

Exit criteria for this requirement is that stored procedures contain no calls to EXEC or EXECUTE (except for calls to EXEC other stored procedures).

Página 32 - HTTPOnly Cookies

To mitigate the risk of information disclosure with a cross-site scripting attack, a new attribute was introduced to cookies for Internet Explorer 6 SP1 and is now in use in all current browsers. This attribute specifies that a cookie is not accessible through script. By using HTTP-only cookies, a Web application reduces the possibility that sensitive information contained in the cookie can be stolen via script. Watcher, a Web security testing tool, can help you meet this recommendation.
All HTTP-based applications that use cookies must specify HttpOnly in the cookie definition for all cookies not explicitly required by legitimate scripts in the Web page. For example:

Set-Cookie: USER=123; expires=Wednesday, 10-Feb-2010 23:12:40 GMT; HttpOnly"

Página 33 - ClickJacking defense

For each page that could contain user controllable content, you should use a "frame-breaker" script and include the HTTP response header named X-FRAME-OPTIONS in each authenticated page. The Watcher tool may be of use in meeting this recommendation. The exit criteria for this recommendation is as follows:

1. A "frame-breaker" script is included in each authenticated page to prevent unintentionally framing.

2. The X-FRAME-OPTIONS header has been added to all authenticated page HTTP responses that should not be framed (for example, DENY) or is utilized to only allow trusted sites to frame site content (for example, the current site with the use of SAMEORIGIN).

Se em versões anteriores algumas pessoas criticavam por não atender claramente as características de aplicação web, a cada nova versão este cenário vem sendo melhorado.

Cursos no YSTS 4.0

Mais conhecida pela organização do evento You Sh0t the Sheriff (YSTS), a STS Produções está ofertando uma série de treinamentos em Segurança da Informação, através de criteriosa seleção do conteúdo e dos instrutores.

Estarei ministrando os cursos que estão sendo ofertados em parceria com o Conviso Security Labs. Confira aqui os detalhes e não perca a oportunidade de aprendizado e networking.

O uso de ferramentas de Bug Tracker no tratamento de vulnerabilidades

Ao implementar processos de desenvolvimento seguro, geralmente nos deparamos com problemas considerados pelo senso comum como básicos e essenciais para a produção de software, o que é o caso da ausência de uma ferramenta de bug tracker. Neste post, descrevo a implementação de uma ferramenta destinada a preencher este ponto e customizada para auxiliar o processo de gestão e correção de vulnerabilidades em softwares.

A ferramenta escolhida é o Mantis (http://www.mantisbt.org/), uma vez que é de fácil customização e instalação, porém qualquer outro produto que possa ser utilizado no processo de bug tracking e possibilite a criação de campos customizados pode ser adotada no mesmo princípio.

Características do Mantis

O Mantis é uma terramenta Open Source desenvolvida em PHP e que tem suporte a diversos bancos de dados, tais como MySQL e Postgres, além de contar com recursos completos para suportar o processo de gestão na correção de problemas encontrados no processo de desenvolvimento de software.

Instalando o Mantis

Para a instalação do Mantis as etapas abaixo apresentadas devem ser cumpridas de forma seqüencial:

1. Execute o download do pacote de instalação à partir do endereço http://www.mantisbt.org/download.php.
2. Descompacte este pacote no diretório de publicação que será utilizado no Servidor de Aplicação.
3. Acesse a URL do web site publicado.
4. Na tela de configuração apresentada, informe os parâmetros referentes ao banco de dados que será utilizado e execute a instalação seguindo as instruções que serão fornecidas.
5. Configure o servidor de e-mail que será utilizado pelo Mantis no arquivo: config_defaults_inc.php que será instalado no diretório raiz do web site.

Com estas configurações o Mantis estará funcionando e pronto para ser utilizado, porém para garantir a aplicação de alguns protocolos de segurança adicionais, sugiro que sejam cumpridos os pontos abaixo apresentados:

1. Apague o diretório admin do diretório raiz do site.
2. Crie um novo usuário e apague o usuário padrão administrator, cuja senha padrão é root. :-)
3. No arquivo config_defaults_inc.php altere a diretiva “$g_allow_signup = ON” para OFF, uma vez que assim será removida a possibilidade de solicitação do usuário que aparece como padrão na página de acesso.

Dica: O funcionamento do Mantis depende muito do envio de e-mails, inclusive para os processos de criação e validação dos usuários, não esqueça de configurar um smtp para suportar esta finalidade e caso você precise testar o processo localmente, uma uma boa pedida é o Papercut que simula o envio e recebimento de e-mail no seu computador.

Customizando o Mantis para suportar um processo de gestão de vulnerabilidade

1 – A primeira etapa é criar as tags para definir qual o tracker será utilizado. No menu, escolha a opção Manager=>Manage Tags e crie as tags:

• Bug
• Feature
• Support
• Vulnerability
• Security Service

2 – Em seguida, é necessário definir os campos personalizados, o que é realizado pela escolha da opção Manager=>Manage Custom Fields no menu, seguida da criação dos campos personalizados abaixo relacionados, onde os campos “lista” e “texto” são obrigatórios:

• Security Impact – Booleano
• Compliance Impact – Booleano
• Privacy Impact – Booleano
• Vulnerability Category – Lista
• Identified By – Lista
• Identification Method – Lista
• Identification Method Source – Lista
• Report – Texto
• Requested Security Activity - Lista

Conteúdo dos Campos Lista

1 - Vulnerability Category:

• Authentication
• Authorization
• Input Validation
• Output Encoding
• Error Handling
• Session Management
• Logging

2 - Identified By:

• Development Team
• Security Team
• Third Party Assessor
• Client
• External Researcher
• Attacker
• Operations Team

3 - Identification Method:

• Code Review
• Penetration Testing
• Architecture Review
• Design Review
• Other

4 - Identification Method Source:

• Automated Tool
• Human
• Unknown

5 - Requested Security Activity:

• Requirements Review
• Architecture Review
• Design Review
• Code Review
• Penetration Test
• Third Party Assessment
• Final Security, Compliance and Privacy Assessment

Utilizando o BugTracker para suportar o tratamento de vulnerabilidades

A ferramenta de Bug Tracker será utilizada para suportar o processo de documentação e auxiliar na integração das equipes responsáveis pelo desenvolvimento, análise da segurança, assim como na gestão destas equipes. O primeiro passo é entender o que representa cada estado do BugTracker, a imagem a seguir apresenta os status que o Mantis utiliza:

Entendo o Mantis

A imagem a seguir apresenta a aplicação de cada um dos status no tratamento da vulnerabilidade e a utilização dos campos customizados que foram citados :

Esta abordagem foi adotada com base no post de Nick Coblentz, respeitando as regras da licença Creative Commons e autorizado pelo autor.

Php Security - Nem tudo que é publicado deve ser seguido

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.

Tratando o Top 10 da OWASP em aplicações .Net

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.

OWASP Top 10 e aplicações .Net - Tech-Ed 2007

View more presentations from Conviso IT Security.

Conteúdo da apresentação na Hacker to Hackers Conference 2009

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.

Playing Web Fuzzing - H2HC 2009

View more presentations from Conviso IT Security.

Conteúdo da apresentação na Php Conference 2009

No último dia 27 de Novembro eu tive a oportunidade de realizar uma apresentação técnica sobre o funcionamento e utilização do PHPIDS para proteger aplicações php. A apresentação foi complementada com várias demonstrações e o público interagiu bastante. Obrigado a todos os que compareceram.

Protegendo Aplicações Php com PHPIDS - Php Conference 2009

View more presentations from Conviso IT Security.

OWASP AppSec Brasil 2009 - Um Sucesso!

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?

Microsoft Hello Secure World

A Microsoft disponibiliza um ambiente onde é possível fazer laboratórios explorando as seguintes vulnerabilidades:

• XSS (Cross Site Scripting)
• SQLi (SQL Injection)
• Canonicalization Attack
• CSRF (Cross Site Request Forgery)
• Integer Overflow/Undeflow

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!

Playing Web Fuzzer

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.

Protegendo aplicações em php com PHPIDS

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/

AppSec Brasil 2009 - CHAMADA PARA PARTICIPAÇÃO

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:

• Segurança de aplicações web
• Otimização de gastos com segurança
• SQL Ownage
• ferramentas.
  

Mini-cursos

A Conferência contará também com 5 mini-cursos:

• Gestão de Riscos de Segurança Aplicada a Web Services
• Segurança Web: Técnicas para Programação Segura de Aplicações
• Segurança Computacional no Desenvolvimento de Web Services
• Tecnologias de Segurança em Web Services
• Hands on Web Application Testing using the OWASP Testing Guide.
  

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

• Inscrições e informações sobre a conferência: http://www.camara.gov.br/appsecbrasil2009
  
• Comunidade TI-Controle: http://www.ticontrole.gov.br
  
• Câmara dos Deputados: http://www.camara.gov.br

SDL (Secure Development Lifecycle) - Tão simples quanto parece?

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:

• Compliance é o mínimo do requerido, não espere que esta demanda justifique o processo de segurança em desenvolvimento;


• Identifique de que maneira a sua organização é afetada pela insegurança de software;


• Tenha ciência que a maioria dos impactos relacionados a incidentes envolvendo falhas de software impacta indiretamente a organização e os valores são intangíveis. A famosa fórmula de ROI pode não lhe ajudar nestes cenários;


• Envolva todos no processo, não seja apenas o auditor que aponta as falhas e cobra uma solução;


• Não trate um processo de SDL como um projeto que você desenvolve meia dúzia de documentos e está feito. Busque a melhoria contínua, crie e acompanhe métricas que possam viabilizar e melhorar o processo.

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

Uma alternativa ao SSL

Muitas vezes necessitamos criptografar o tráfego de dados sensíveis em aplicação, a melhor opção para estes casos é usar SSL. Obviamente que o SSL deve ser bem implementado, pois muitas vezes ele é mal implementado e possibilita que algumas vulnerabilidades sejam exploradas.

Infelizmente implementar SSL em todos os ambientes nem sempre é responsabilidade do desenvolvedor, geralmente ele depende de uma área responsável por infraestrutura. Quando não existe um bom relacionamento entre as áreas e/ou um estudo de requisitos antes de colocar uma aplicação em produção, a aplicação acaba indo para produção sem o SSL e consequentemente exposta as vulnerabilidades pertinentes a data tampering.

Uma alternativa para desenvolvedores é um plugin chamado JCryption para o framework javascript JQuery. O plugin possibilita que seja criptografado as requisições POST e GET. Ele não substitui o SSL, mas pode "quebrar o galho" em algumas requisições.

A implementação é simples, basta seguir os exemplos da página do plugin.

Hardening de sessões em ambiente Java

É bastante comum eu encontrar problemas em sessões de aplicações baseadas no ambiente Java. Estes problemas geralmente não são conhecidos por desenvolvedores, pois eles deixam todo o processo de criação e gestão de sessão a cargo do servidor de aplicação. A grande maioria dos servidores de aplicação Java não suportam ou não trazem por padrão as configurações adequadas para garantir a segurança destas sessões.

Neste post eu pretendo apresentar a solução para cada um dos problemas que eu encontro em análises que eu realizo. Todas as soluções dependem de codificação e devem ser feitas pelo desenvolvedor.

1 - Falta da flag HTTPOnly nos cookies de sessão

Como já podemos verificar em outro post aqui no blog, a falta da flag HTTPOnly nos cookies de sessão é um facilitador para ataques client-side que buscam sequestrar sessão de usuário, pois sem a flag é possível capturar o ID de Sessão via javascript. Mais informações podem ser obtidas na referência da OWASP.

Como tratar este risco

Para tratar este risco é preciso reescrever o cookie mantendo os dados originais e incluindo a flag HTTPOnly.

response.setHeader("Set-Cookie",
                   "originalcookiename=originalvalue;
                   HTTPOnly");

2 - Falta da Flag secure nos cookies de sessão

É importante que a flag secure seja setado em todo cookie de sessão. Isto irá garantir que um cookie gerado em uma conexão HTTPS (Conexão Criptografada) irá trafegar apenas por uma conexão tunelada via HTTPS. A falta desta flag permite que o cookie seja trafegado via HTTP (Texto Claro) e possa ser capturado por usuários mal intencionados que estejam capturando pacotes em rede. Mais informações podem ser obtidas na referência da OWASP.

Como tratar este risco

O tratamento deste risco é semelhante ao do HTTPOnly, basta reescrever o cookie e incluir a flag secure. Não esqueça de manter a flag HTTPOnly ao reescrever o cookie para incluir a flag secure.

response.setHeader("Set-Cookie",
                   "originalcookiename=originalvalue;
                   Secure;HTTPOnly");

3 - Session Fixation

Com esta vulnerabilidade o ID de sessão pode ser capturado por um ataque client-side e ser "forçado" seu uso em uma requisição. Isso possibilita burlar o sistema de autenticação da aplicação. Mais informações podem ser obtidas na referência da OWASP.

Como tratar este risco

Para tratar este risco é necessário recriar a sessão após a autenticação. Um exemplo de código é dado pelo Lucas Ferreira no seu site sobre segurança em Java.

O código abaixo mostra como abandonar uma sessão a criar outra após a autenticação:

public class ExampleLoginServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
     throws ServletException, IOException {
     if( //autenticação bem sucedida ) {
        request.getSession().invalidate();
        HttpSession session = request.getSession(true);
        session.setAttribute("AUTHENTICATED", new Boolean(true));
        response.sendRedirect("PageRequiringAuthentication.jsp");

No caso de aplicações Struts 2, o código abaixo é mais apropriado:

if(//autenticação bem sucedida)  {

     /* Renovação do identificador de sessão */
     ((SessionMap)this.session).invalidate();
     this.session = ActionContext.getContext().getSession();

     session.put("AUTHENTICATED", new Boolean(true));

     return SUCCESS;
  }

  else
     return ERROR;
}

É importante que desenvolvedores entendam que para garantir a seguranca de uma aplicação, é preciso configurar adequadamente todos os ativos que a suportam, como: Banco de Dados e Servidor de Aplicação. Um bom código sem uma infraestrutura adequada pode levar ao comprometimento da aplicação.

OWASP AppSec Brasil 2009 - CFP Deadline

Estamos na última semana para submissão de propostas de palestras para o AppSec Brasil 2009. Mais informações na página do evento: http://www.owasp.org/index.php/AppSec_Brasil_2009_%28pt-br%29

Ajudem-nos a espalhar o CFP e a solicitar o envio de propostas interessantes para o evento.

Fiddler, uma boa opção para teste de app web

Hoje ao analisar uma aplicação que só funcionava adequadamente no Internet Explorer, eu percebi o quanto sou dependente de alguns plugins do Firefox (HTTP Live Header, Tamper Data, Firebug, HTTPFox, entre outros). Eu realizo muitos testes manuais e eles são essenciais nestas análises, o Internet Explorer também possui alguns plugins, mas eu ainda não tive a oportunidade de testá-los.

Como eu precisava de uma opção rápida, optei pelo Fiddler. Já fazia um bom tempo que eu não o utilizava, a última vez foi para testar o Watcher, quando foi lançado há alguns meses atrás.

O fiddler, atualmente na versão v2.2.2.2.2 Beta (isso mesmo, eu não me enganei na quantidade de números 2), é um sniffer bem completo e que possui uma série de plugins que ajudam muito na depuração e identificação de falhas em aplicações web. Com uma interface bastante apurada você pode mapear claramente a aplicação e inclusive documentar requisições usando a opção Comment. Para utilizar o Fiddler basta iniciá-lo e configurar o seu Internet Explorer para usar o proxy no endereço IP 127.0.0.1 (Localhost) na porta 8888.

Bom, vamos ao que interessa, as extensões que o Fiddler possui. Uma bem interessante e que lembra muito o modo de teste do Ratproxy (análise passiva) do Google, é o Watcher. Esta extensão se acopla ao Fiddler e realiza uma série de testes de segurança da aplicação.

O modo de instalação do Watcher é bem simples, basta extrair os seguintes arquivos do pacote de instalação: Watcher.dll e WatcherCheckLib.dll no diretório scripts que se encontra no diretório: %userprofile%\My Documents\Fiddler2\Scripts no Windows XP e %userprofile%\Documents\Fiddler2\Scripts. Após a extração dos arquivos no diretório adequado é só reiniciar o Fiddler que irá aparecer uma aba chamada: Security Auditor.

Como utilizar o Watcher?

Na aba Security Auditor insira o domínio da aplicação que você deseja testar.

Após definir o domínio é só clicar em Save Config e navegar na aplicação usando o Internet Explorer configurado para navegar usando o Fiddler como proxy.

Após navegar por toda a aplicação que você deseja testar, clique na aba Results do Watcher e confira a análise realizada.

O que eu achei bem interessante no Watcher foi a possibilidade de incluir, alterar as mensagens que ele analisa durante o parser nas respostas a requisições na página. Um que vale a pena gastar um tempo e incluir palavras chaves é o teste que procura por palavras chaves em comentários no código.

Ah! Quem utiliza o Internet Explorer para testar aplicações e quer sugerir plugins, ferramentas, o comentário está ai pra isto.

[Update 31/08/2009]

Alguns plugins para o Internet Explorer:

Tamper IE: Similar ao excelente Tamper Data do Firefox
Internet Explorer Developer Toolbar: Similar ao Web developer Toolbar do Firefox
HTTP Watch: Similar ao HTTP Live Header do Firefox
IECookiesView: Similar ao CookieEditor do Firefox

Treinamentos You Sh0t the Sheriff 3.0

Este ano a Conviso está novamente patrocinando o evento You Sh0t the Sheriff. Além do patrocínio, este ano na sua terceira edição, o evento irá também oferecer treinamentos nos dias 23 e 24 de Junho.

A conviso irá ministrar dois treinamentos:

• Web Hacking Techniques
• Internet Hacking Techniques

O evento acontece no dia 22 de Junho e espero vocês lá.

Chamada de Trabalhos - OWASP AppSec Brasil 2009

O OWASP solicita propostas de apresentações para a conferência internacional OWASP 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. Esta conferência será promovida e organizada pela Comunidade TI-Controle e pela Câmara dos Deputados.

Buscamos pessoas e organizações que queiram ministrar palestras sobre segurança de aplicações. Em particular destacamos os seguintes tópicos de interesse:

• Modelagem de ameaças em aplicações (Application Threat Modeling)
• Riscos de Negócio em Segurança de aplicações (Business Risks with Application Security)
• Aplicações de Revisões de Código (Hands-on Source Code Review)
• Métricas Aplicadas a Segurança de Aplicações (Metrics for Application Security)
• Ferramentas e Projetos do OWASP (OWASP Tools and Projects)
• Tópicos de Privacidade em Aplicações e Armazenamento de Dados (Privacy Concerns with Applications and Data Storage)
• Práticas de Programação Segura (Secure Coding Practices)
• Programas de Segurança para todo o Ciclo de Vida de alicações (Secure Development Lifecycle Programs)
• Tópicos de Segurança para tecnologias específicas (AJAX, XML, Flash, etc) (Technology specific presentations on security such as AJAX, XML, etc)
• Controles de Segurança para aplicações Web (Web Application Security countermeasures)
• Testes de Segurança de aplicações Web (Web Application Security Testing)
• Segurança de Web Services ou XML (Web Services-, XML- and Application Security)

A lista de tópicos não é exaustiva; outros tópicos podem ser abordados, desde que em consonância com o tema central do evento.

As propostas devem conter:

• Nome do apresentador e dos demais autores
• E-mail e telefone do apresentador
• Curriculum resumido do apresentador e, opcionalmente, dos demais autores
• Título da apresentação
• Resumo e abstract
• Lista de todos os assuntos a serem abordados durante a apresentação
• Qualquer outro material que os autores julguem necessários (Estes materiais ficarão restritos ao comitê de programa)

Cada apresentação terá 45 minutos de duração, seguidos de 10 minutos para perguntas da platéia. Todas as apresentações deverão estar em conformidade com as regras definidas pelo OWASP em seu "Speaker Agreement".

Datas importantes:

A data limite para apresentação de propostas é 11 de julho de 2009 às 23:59, horário de Brasília.

A notificação de aceitação ocorrerá até o dia 7 de agosto de 2009.

A versão final das apresentações deverá ser enviada até o dia 15 de setembro de 2009.

As propostas devem ser enviadas para o e-mail: appsec.brasil@camara.gov.br

Para mais informações, favor consultar as seguintes páginas:

Página da conferência: https://www.owasp.org/index.php/AppSec_Brasil_2009_(pt-br)

Perguntas frequentes: https://www.owasp.org/index.php/AppSec_Brasil_2009_-_FAQ_(pt-br)

OWASP Speaker Agreement (em inglês): http://www.owasp.org/index.php/Speaker_Agreement

Comunidade TI-Controle: http://www.ticontrole.gov.br

Câmara dos Deputados: http://www.camara.gov.br