Estou lendo o livro: Innocent Code - A Security Wake-Up Call for Web Programmers! O Livro é antigo, de 2004, mas eu ainda não havia tido a oportunidade de ler.

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 Stay Safe Podcast é um podcast sobre segurança da informação produzido por Thiago Bordini e Jordan Bonagura. Fui convidado por eles para bater um papo e a edição já está disponível.

Aqui está disponível a edição que eu participei:
http://www.staysafepodcast.com.br/?p=184

Quero agradecer a oportunidade e quem quiser dar seu feedback, só deixar um comentário.

Começou o Call for Papers do OWASP AppSec Brasil 2010, veja abaixo a reprodução da chamada em  português.

APPSEC BRASIL 2010

CHAMADA DE TRABALHOS

O OWASP (Open Web Application Security Project) solicita propostas de apresentações para a conferência AppSec Brasil 2010, que ocorrerá na Fundação CPqD em Campinas, SP, de 16 a 19 de novembro de 2010. Haverá mini-cursos nos dias 16 e 17, seguidos de sessões plenárias de trilha única nos dias 18 e 19 de novembro de 2010.

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 aplicaçõ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.

Para submeter uma proposta, preencha o formulário disponível em http://www.owasp.org/images/6/68/OWASP_AppSec_Brasil_2010_CFP%28pt-br%29.rtf.zip, que deve ser enviado através da página da conferência no site Easychair: http://www.easychair.org/conferences/?conf=appsecbr2010

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 é 17 de agosto de 2010 às 23:59, horário de Brasília.
• A notificação de aceitação ocorrerá até o dia 8 de setembro de 2010.
• A versão final das apresentações deverá ser enviada até o dia 30 de setembro de 2010.

A comissão organizadora da conferência pode ser contactada pelo e-mail: organizacao2010@appsecbrasil.org

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

• Página da conferência: http://www.owasp.org/index.php/AppSec_Brasil_2010_(pt-br)
• OWASP Speaker Agreement (em inglês): http://www.owasp.org/index.php/Speaker_Agreement
• Página do OWASP: http://www.owasp.org
• Página da conferência no Easychair: http://www.easychair.org/conferences/?conf=appsecbr2010
• Formulário para apresentação de propostas: http://www.owasp.org/images/f/f7/OWASP_AppSec_Brasil_2010_CFP.rtf.zip

ATENÇÃO: Não serão aceitas propostas sem TODAS as informações solicitadas no formulário

Favor divulgar a todos os possíveis interessados.

"O trágico da nossa época ou, melhor dizendo, do Brasil atual, é que o idiota mudou até fisicamente. Não faz apenas o curso primário, como no passado. Estuda, forma-se, lê, sabe. Põe os melhores ternos, as melhores gravatas, os sapatos mais impecáveis. Nas recepções do Itamaraty, as casacas vestem os idiotas. E mais: – eles têm as melhores mulheres e usam mais condecorações do que um arquiduque austríaco."

Nelson Rodrigues - O Óbvio Ululante - 1968

Muitos já pensaram logo: é, ele ficou louco de vez, citando Nelson Rodrigues em um blog de segurança da informação. Não, é apenas o que eu acho sobre a mais óbvia das citações feitas por 8 entre 10 profissionais de segurança da informação.

Mas que citação é esta?

"O elo mais fraco são as pessoas"

Sem contar as variações que citadas por abotoaduras que são mestres em falar o Mesmo-do-Mesmo com tamanha destreza que faz milhares de pessoas o seguirem como se fosse algo digno de um grande mestre.

Sim, falar que pessoas são a parte mais difícil de tratar quando se pensa em segurança da informação é o Óbvio Ululante, afinal em toda ciência que envolva pessoas isto será sempre assim.

Se isto é óbvio por que a maioria dos profissionais baseiam todo seu discurso nesta citação óbvia?

Simples, por ser a verdadeira bomba de fumaça. É aquela mesma que os ninjas usam para desaparecer sem deixar vestígios.

Falando que o problema são as pessoas exime o profissional de pesquisar e discorrer sobre temas que exigem bastante envolvimento e maturação para que se façam entendivel ao ser humano. É fácil dizer que as pessoas não respeitam uma política, mesmo quando ela é mal feita e descabida. Difícil é desenvolver e implementar uma política que seja de senso comum e que as pessoas entendam sua importância e que as pratiquem sem dificuldades.

Por isto você profissional que está iniciando ou já atua em segurança da informação, fuja desta, busque respostas e não engula o óbvio ululante.

Na última edição do GTS eu tive a oportunidade de fazer uma apresentação sobre as falhas comuns em aplicações desenvolvidas em Flash. Aproveitem os slides e fiquem a vontade para comentar e trocar informações.

**APPSEC BRASIL 2010**

**CHAMADA DE MINI-CURSOS**

O OWASP (Open Web Application Security Project) solicita propostas de apresentações para a conferência AppSec Brasil 2010, que ocorrerá na Fundação CPqD em Campinas, SP, de 16 a 19 de novembro de 2010. Haverá mini-cursos nos dias 16 e 17, seguidos de sessões plenárias de trilha única nos dias 18 e 19 de novembro de 2010.

Buscamos pessoas e organizações que queiram ministrar mini-cursos sobre segurança de aplicações. 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 aplicaçõ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.

Para submeter uma proposta, preencha o formulário disponível em
http://www.owasp.org/images/4/43/OWASP_AppSec_Brasil_2010_CFT%28pt-br%29.rtf.zip,
que deve ser enviado por email para organizacao2010@appsecbrasil.org.

Cada mini-curso poderá ter 1 ou 2 dias (8 horas por dia) de duração e deverão estar em conformidade com as regras definidas pelo OWASP em seu "Speaker Agreement". A conferência pagará aos instrutores pelo menos 30% do fatuamente de seus mini-cursos. Cursos que consigam atrair mais que o número mínimo de alunos poderão receber percentagens
maiores (mais detalhes abaixo). Não haverá qualquer outro tipo de remuneração (passagens, hospedagem, etc) para os apresentadores ou autores dos mini-cursos. Caso seja necessário um arranjo diferente, favor entrar em contacto com o comitê organizador pelo email abaixo.

**Remuneração**
Os instrutores e autores dos cursos serão remunerados conforme a quantidade de alunos. Se o curso atrair apenas o número mínimo de alunos, a remuneração será 30% do faturamento. Para cada 10 alunos a mais, a remuneração será acrescida de 5% do faturamento, até um máximo
de 45% do faturamento do curso. Por exemplo, para um curso de 1 dia para uma turma de 10 a 19 alunos, os instrutores e autores receberão 30% do faturamento do curso. Para turmas entre 20 e 29 alunos, a remuneração sobe para 35% do faturamento e assim sucessivamente.

Em casos excepcionais, poderá ser acordado um esquema diferente para remuneração dos instrutores. Possíveis interessados devem entrar em contacto com a comissão organizadora pelo email organizacao2010@appsecbrasil.org

**Valores das inscrições**
Cursos de 1 dia: R$ 450 por aluno
Cursos de 2 días: R$ 900 por aluno

**Mínimo de alunos**
10 alunos para cursos de 1 dia
20 alunos para cursos de 2 dias

**Datas importantes:**
A data limite para apresentação de propostas é 26 de julho de 2010 às 23:59, horário de Brasília.
A notificação de aceitação ocorrerá até o dia 16 de agosto de 2010.
A versão final do material dos mini-cursos deverá ser enviada até o dia 15 de setembro de 2010.

A comissão organizadora da conferência pode ser contactada pelo e-mail: organizacao2010@appsecbrasil.org

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

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

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

Página do OWASP: http://www.owasp.org

Página da conferência no Easychair: http://www.easychair.org/conferences/?conf=appsecbr2010

Formulário para apresentação de propostas: http://www.owasp.org/images/4/43/OWASP_AppSec_Brasil_2010_CFT%28pt-br%29.rtf.zip

********* ATENÇÃO: Não serão aceitas propostas sem TODAS as informações solicitadas no formulário *********

Favor divulgar a todos os possíveis interessados.
______________________________

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

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.