A idéia

A WebFight nasceu da minha necessidade de lidar com um número grande de informações que uma aplicação web pode gerar. Como eu quero continuar analisando os detalhes de cada requisição e não adotar um web security scanner, decidi criar uma ferramenta que automatizasse a análise de um log de proxy. Assim eu continuo analisando os detalhes manualmente, mas ganhando muito tempo na análise do log.

A ferramenta

A idéia foi fazer um parser do log do Burp e a partir deste parser criar módulos para realizar as análises. A estrutura da ferramenta é resumida no fluxo a seguir:

A ferramenta é facilmente estendida criando módulos e as seguintes análises já estão implementadas:

• Apresenta todas as requisições e seus parâmetros para que sejam realizados testes fuzzing e de validação de dados
• Apresenta todos os status codes, possibilitando identificar erros 500; Redirects 30x; Conteúdo estático 0
• Apresenta as requisições fora do escopo da análise para identificar integrações, ou requests a outros domínios
• Realiza um fingerprint a partir da análise de headers e informações da aplicação
• Apresenta todos os cookies de sessão e a existência de cookies de sessão passados como parâmetro em requisições GET
• Cria PoC em arquivos html de todas as requisições com parâmetros para que seja testado CSRF
• Faz grep e identifica objetos DOM (password; hidden; file upload; iframe; etc...)
• Apresenta todos os comentários em client-side (HTML e javascript)
• Identifica arquivos javascript e javascripts no corpo da página apresentando o conteúdo com syntaxhighlight e realiza análise sintática no javascript apresentando Sink e Sources potencialmente perigosos
• Identifica arquivos swf; realiza download; desassembla o swf e faz grep buscando características potencialmente vulneráveis em flash
• Apresenta todas as respostas em JSON
• Apresenta todos as diretivas de cache nos headers Pragma e Cache-Control
• Apresenta as diretivas de segurança de headers CSP; HSTS e X-Frame-Options
• Apresenta o base64 do header authorization (autenticação básica de HTTP)

A Interface

A interface também facilita bastante a análise por classificar as análises e possibilita que se pesquise e filtre os registros apresentados.

Demo

Aguardo feedback e requisição de outras análises. Faça um clone do Git na página do Projeto e participe da lista de discussão.

A dica número 8: Diminua Cookies e Headers

Nesta dica ele apresenta uma referência que recomenda a separação de conteúdo estático do dinâmico e que no conteúdo estático não seja enviado Cookies.

Esta recomendação não só ajuda a melhorar o desempenho das páginas como pode evitar que seu Cookie seja interceptado em ataques contra a sessão da sua aplicação. É comum páginas configuradas para utilizar HTTPS possuírem objetos como imagens; javascripts; css; no seu conteúdo e estes arquivos estarem em diretórios onde não está configurado o HTTPS. Sendo assim mesmo uma página HTTPS pode deixar "vazar" os Cookies em requisições HTTP para carregar arquivos estáticos.

Para uma garantia a mais, recomendamos que sites com HTTPS insiram em seus Cookies a flag secure. E em breve será comum o uso do header HTTP HSTS (HTTP Strict Transport Security). Recomendo a leitura do guia da OWASP para TLS.

E sobre headers, alguma recomendação?

É muito comum os headers servirem como base para um mapeamento da aplicação, informando dados sobre o seu funcionamento, versão e tecnologia, portanto, valide se realmente são necessários estes headers, caso não sejam, retirando eles você aumenta o desempenho e não propaga informações que podem ajudar a comprometer a sua aplicação.

E agora que você pode usar a segurança como argumento para aumentar o desempenho, será que vai?

Para começar quero deixar um link para algumas palestras que eu e o time da Conviso realizamos em alguns eventos: http://www.conviso.com.br/recursos_pt/apresentacoes/

Em breve outros posts sobre segurança em aplicações.

http://www.conviso.com.br/html5-seguro-ou-inseguro/

Estou escrevendo alguns posts para o blog e tenho escrito bastante no blog da Conviso: http://www.conviso.com.br/category/blog/

Mas como, se muitos profissionais da área afirmam que este é o caminho? Exatamente por isto que eu credito este problema a nós mesmos profissionais que atuamos na área.

Hoje a maioria dos clientes coloca como critério para projetos de segurança em desenvolvimento a aderência a ISO/IEC 15408 e para Penetration Test a utilização de alguma metodologia como OSSTMM. Colocam porque durante anos os profissionais pregaram e divulgaram tais informações. O pior, na grande maioria das vezes quem divulga nunca aplicou e muitas vezes se quer conhece o padrão. Muitos profissionais amparam todo o seu discurso, argumentos em chavões, mentiras ditas tantas vezes que acabam virando verdade.

Por que OSSTMM não é referência para Penetration Test?

O primeiro grande desafio é ter o documento completo, a OSSTMM está em desenvolvimento há anos e nunca se teve conhecimento de toda metodologia, abordagem proposta. Todo o desenvolvimento é baseado em puro marketing, mesmo pagando a taxa pelo suposto método completo, ele sempre está incompleto e em desenvolvimento. E vou falar, eles sofrem de um problema sério de falta de produtividade, este cenário permanece por anos.

Bom, vamos falar da parte que existe. A documentação não apresenta fases que sejam viáveis para um Penetration Test, ele apresenta um número grande de coisas que devem ser analisadas e não passa disto. Um outro ponto que é difícil de se implementar na prática é uma abordagem quantitativa chamada rav. Esta abordagem prevê que seja analisado os controles e pontuado de acordo com um critério que, após o cálculo usando a fórmula apresentada, irá determinar uma pontuação ao ambiente. De acordo com a pontuação o ambiente é considerado mais ou menos seguro.

Abordagem quantitativas são a eterna busca de gestores na área de tecnologia, busca louvável, mas em Penetration Test isto é ineficaz e inútil. Sim, o propósito de um Penetration Test é identificar fragilidades que possam levar ao comprometimento do ambiente e não ser uma análise de riscos. A análise do Penetration Test irá apresentar uma análise qualitativa e servirá como uma das n variáveis de uma análise de riscos quantitativa. Está análise irá determinar qual o controle deve ou não ser implementado de acordo com o risco associado ao ambiente e o custo envolvido na solução versus o impacto que pode causar no ambiente.

Resumindo, OSSTMM não pode servir de referência para realização de um Penetration Test. O profissional que executa estes projetos com freqüência desenvolve seu próprio método levando em consideração as características do mercado que atua e a necessidade de organizar e apresentar os resultados esperados pelo cliente. Já escrevi algumas idéias sobre metodologia em Penetration Test e também recomendo a leitura do documento SP 800-115 (Thecnical Guide to Security Testing) do NIST.

Por que a ISO/IEC 15.408 não é referência para segurança em desenvolvimento?

Existem vários motivos que levam ao entendimento claro de que a ISO/IEC 15.408 ou Commom Criteria não é para segurança em desenvolvimento, mas o Geraldo Fonseca no Twitter deu uma descrição breve e que para mim é perfeita:

"@gfonseca_  @welias  cc/15408 é framework de avaliação, não de desenvolvimento. É para avaliar o "fato consumado", e não para ajudar a criar algo seguro."

É exatamente isto, ela não propõe ou valida nenhum método para se conseguir chegar ao desenvolvimento de um código seguro. Ela apresenta apenas alguns critérios que um produto de software deve ter para que possa ser acreditado por laboratórios credenciados. Define características que um software deve ter. Mas como eu chego lá? Procuro lá na ISO/IEC 15.408 e me diz.

Bom, se você leu pode responder que ela não apresenta nada disto. Para se conseguir um software seguro é preciso ter um processo maduro e implementar práticas de segurança em código, testes e principalmente um trabalho de conscientização e treinamento dos profissionais envolvidos. 

Um post do Fernando Cima comenta sobre o relatório "State of the Art of Software Security Assurance" do Departamento de Defesa americano e o papel da ISO/IEC 15.408. Eu também escrevi um artigo para revista da ISSA.

Não que eu queira jogar uma bomba de fumaça, mas é necessário orientar as pessoas, pesquise neste cara aqui e verifique se você encontra alguma referência internacional que associe o uso da ISO/IEC 15.408 como base para desenvolvimento seguro.

Pesquisou? Pois é, não encontrou nada.

Agora procura em português. Bingo! Existem várias citações a ISO/IEC 15.408 para desenvolvimento seguro. Este "fenômeno" eu credito a este livro: SEGURANÇA NO DESENVOLVIMENTO DE SOFTWARE

Mas o propósito do livro é claro: Como desenvolver sistemas seguros e AVALIAR A SEGURANÇA DE APLICAÇÕES DESENVOLVIDAS COM BASE NA ISO 15.408

Ah! Ai é outra história! A maioria das pessoas virá especialista apenas lendo a capa de um livro, ou no melhor dos casos, fazendo como o Pateta do Walt Disney que lê o início e o fim do livro.

O que me chamou a atenção no livro é que ao invés de tentar apresentar trechos de códigos, técnicas de secure coding ele apresenta idéias e tópicos que todo programador deve levar em consideração.

E uma coisa que gostei foram alguns pontos que ele apresenta como inimigos do Secure Code:

Ignorance

Isto mesmo, ele apresenta a ignorância como um dos inimigos da segurança de código. Eu acredito nisto! A grande maioria dos desenvolveres cometem erros de segurança por desconhecimento. Ele desenvolve um bom código, que funciona, mas que tem uma falha de segurança. Mas um bom código pode ser inseguro? Sim! Ele pode inserir falhas de arquitetura, privacidade mesmo desenvolvendo um código de excelente qualidade.

Por este motivo é fundamental que seja disponibilizado material de estudo e um trabalho de conscientização constante.

Mess

Exatamente, muitos ambientes de desenvolvimento são uma verdadeira bagunça. Os desenvolvedores não adotam nenhuma prática de teste, integração contínua e algumas vezes nem o básico, como controle de versão.

O desenvolvimento de código de qualidade e seguro depende da adoção de práticas de desenvolvimento e organização. Eu já escrevi sobre Bug Tracking e incluo como uma excelente prática a adoção de ferramentas que implementem o processo de integração contínua.

Deadlines

Prazos são um problema sério em desenvolvimento de software e isto naturalmente afeta a segurança. Com a definição de prazos apertados o planejamento, análise e inspeção de código é deixado de lado e entra em cena as soluções mirabolantes e a popular POG (Programação Orientada a Gambiarra) ou a XGH (eXtreme Go Horse) que tem como principal característica:

1- Pensou, não é XGH.

XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

Salesmen

Vendedores, sempre eles. Vendem o que não podem entregar e depois o desenvolvedor precisa desenvolver um sistema ruim para atingir prazos e orçamentos. E sem contar aquelas features que são um atentado a segurança, mas precisam estar disponíveis pois foram vendidas ao cliente.

São pontos bem comuns, mas que afetam e muito o desenvolvimento de um bom código.

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.

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.

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.

Mas aguardem, em breve os vídeos serão disponibilizados.

• 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!

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

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.

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.

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

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

A Conferência será promovida pelo OWASP Brasil com o suporte da Comunidade TI-Controle para tratar os diferentes assuntos relacionados a Segurança de Aplicações, tais como:

• Desenvolvimento seguro
• Segurança e arquitetura de software
• Processos de desenvolvimento de sistemas seguros
• Ferramentas para análise de segurança de aplicações
• Bibliotecas e frameworks de segurança para aplicações web
• Auditoria e testes de segurança em aplicações
• Metodologias gerenciais para melhoria da segurança no desenvolvimento de software
• Análise de ataques a aplicações
• Avaliação de riscos de negócio em aplicações web
• Segurança de web services

A Conferência terá dois dias de treinamentos (27 e 28 de outubro) seguidos de dois dias de palestras (29 e 30 de outubro). As chamadas de trabalho serão divulgadas neste fim de semana. A página com as informações relacionadas está disponível na Wiki da OWASP.