Enquanto eu não atualizo o blog, segue slides e vídeos da minha palestra no H2HC 2010.
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/
6 de dezembro de 2010
13 de outubro de 2010
[OFF-Topic] Problemas em faturas da TIM
Eu peço desculpa pelo off-topic, mas eu quero saber se mais pessoas estão com o mesmo problema. Meus problemas com a TIM começaram no ano passado, quando meu celular simplesmente parou de funcionar e acusava que o SIM Card era inválido.
Ao entrar em contato com a central de atendimento fui informado que meu CHIP estava com problema e eu precisava ir até uma loja TIM para trocá-lo. Após várias visitas em lojas TIM eu descobri que não era problema do CHIP e sim que meu aparelho havia sido cancelado por falta de pagamento. Sim! Meu telefone foi cancelado por falta de pagamento e eu não sabia. Em uma loja da TIM a atendente retirou as faturas em atraso. Apareceram várias contas com valores irrisórios, algumas com 1 centavo, isto mesmo, 1 centavo. No total as contas totalizavam menos de R$ 30,00. O detalhe é que eu não sabia destes valores e as contas eram de anos anteriores, isto mesmo, as contas eram de anos anteriores e o meu telefone funcionava normalmente e eu não sabia que devia.
Descoberto o problema, paguei os valores e pasmem, ainda tinha mais carroço-nesse-angu. Apareceram mais coisas, não acusaram outros pagamentos. Para resolver eu tinha que pagar valores que chegavam a aproximadamente R$ 150,00. Paguei os valores e finalmente eu não devia mais nada a TIM.
Bom, agora eu religo meu telefone e problema resolvido. NÃO! Os problemas só começaram! A central de atendimento dizia que meu telefone havia sido cancelado e que eu tinha perdido meu número. Após muitas discussões, reclamações em todos os canais possíveis e 2 meses depois eu consegui religar o meu número antigo.
E a saga continua! Na primeira fatura um susto, um valor assustador tarifando internet e uma multa de R$ 400,00 pelo religamento da linha. Lá vou eu percorrer todos os canais de atendimento da TIM. Após várias reclamações eu consegui que eles revisasem os valores da fatura pois o meu plano tinha internet ilimitada e eu não pagaria uma multa para religar uma linha se eles é que erraram e cancelaram meu celular indevidamente.
Problema resolvido eu tinha meu número e tudo ia muito bem. De repente a uns meses atrás surgiram novas contas com valores altos, cobrando acesso a internet. Lá vou eu contestar as contas novamente, pois o que eu devia de internet era R$ 89,00 referente a um plano ilimitado de internet. Após muitas reclamações e o telefone novamente cancelado por falta de pagamento, a TIM resolve começar a resolver meu problema. Mas sinceramente eu não confio mais, afinal, olha ai as contas que teimam em surgir de anos anteriores, inclusive uma de 1 centavo.
-------------------
Senhor Wagner, referente ao
protocolo de atendimento nº 2010161893074;
Quem teve ou tem problemas semelhantes com a TIM, por favor deixem um comentário.
Abs.
Ao entrar em contato com a central de atendimento fui informado que meu CHIP estava com problema e eu precisava ir até uma loja TIM para trocá-lo. Após várias visitas em lojas TIM eu descobri que não era problema do CHIP e sim que meu aparelho havia sido cancelado por falta de pagamento. Sim! Meu telefone foi cancelado por falta de pagamento e eu não sabia. Em uma loja da TIM a atendente retirou as faturas em atraso. Apareceram várias contas com valores irrisórios, algumas com 1 centavo, isto mesmo, 1 centavo. No total as contas totalizavam menos de R$ 30,00. O detalhe é que eu não sabia destes valores e as contas eram de anos anteriores, isto mesmo, as contas eram de anos anteriores e o meu telefone funcionava normalmente e eu não sabia que devia.
Descoberto o problema, paguei os valores e pasmem, ainda tinha mais carroço-nesse-angu. Apareceram mais coisas, não acusaram outros pagamentos. Para resolver eu tinha que pagar valores que chegavam a aproximadamente R$ 150,00. Paguei os valores e finalmente eu não devia mais nada a TIM.
Bom, agora eu religo meu telefone e problema resolvido. NÃO! Os problemas só começaram! A central de atendimento dizia que meu telefone havia sido cancelado e que eu tinha perdido meu número. Após muitas discussões, reclamações em todos os canais possíveis e 2 meses depois eu consegui religar o meu número antigo.
E a saga continua! Na primeira fatura um susto, um valor assustador tarifando internet e uma multa de R$ 400,00 pelo religamento da linha. Lá vou eu percorrer todos os canais de atendimento da TIM. Após várias reclamações eu consegui que eles revisasem os valores da fatura pois o meu plano tinha internet ilimitada e eu não pagaria uma multa para religar uma linha se eles é que erraram e cancelaram meu celular indevidamente.
Problema resolvido eu tinha meu número e tudo ia muito bem. De repente a uns meses atrás surgiram novas contas com valores altos, cobrando acesso a internet. Lá vou eu contestar as contas novamente, pois o que eu devia de internet era R$ 89,00 referente a um plano ilimitado de internet. Após muitas reclamações e o telefone novamente cancelado por falta de pagamento, a TIM resolve começar a resolver meu problema. Mas sinceramente eu não confio mais, afinal, olha ai as contas que teimam em surgir de anos anteriores, inclusive uma de 1 centavo.
-------------------
Senhor Wagner, referente ao
protocolo de atendimento nº 2010161893074;
Primeiramente
pedimos desculpas pelo ocorrido;
Em resposta ao seu e-mail, após verificações em
protocolos finalizados recentemente, localizamos o protocolo 20101350244874,
que tratava-se de contestação de valores de cobranças de serviços Tim connect Fast
e Tim Wap Fast, A fatura com vencimento em 04/08/2010 tinha o valor de R$ 3.294,95,
o valor atualizado para pagamento é de R$ 481,04, abaixo a numeração do código
de barras para o pagamento a menor:
84630000004-5 81040109080-0 00046587709-0 00775286999-5
Informamos os valores e vencimentos das faturas em aberto:
FATURA 04/03/2009 R$
0,01
FATURA 04/11/2008 R$
9,67
FATURA 04/12/2008 R$
52,75
FATURA 07/10/2010 R$
50,38
FATURA 04/01/2009 R$
1,94
FATURA 04/08/2010 R$
481,04
Total: R$ 595,79
Estamos a sua
disposição através deste canal com um novo registro no site www.tim.com.br
Agradecemos por
utilizar o canal Fale com a Tim
Atenciosamente,
Central de Relacionamento
com clientes
Sonia
www.tim.com.br
Por favor, não responda a esta mensagem,
estamos à sua disposição através deste mesmo
canal Fale com a Tim.
-------------------------------------------------------------
Nome: WAGNER ELIAS
CPF/CNPJ: xxxxxx
Telefone: 11xxxx
E-Mail: xxxx
Estado: SP
Tipo: RECLAMAÇÃO
Assunto: ATENDIMENTO
Mensagem: Boa noite. Eu tenho
algumas reclamações abertas há mais de 5 dias úteis e não tive nenhuma
resposta. Eu continuo com o meu problema e a TIM adotou o silêncio como
resposta. Aguardo uma solução. Grato
-------------------
Quem teve ou tem problemas semelhantes com a TIM, por favor deixem um comentário.
Abs.
24 de agosto de 2010
OSSTMM e ISO/IEC 15.408 dois problemas que nós mesmos criamos
Como assim problemas? OSSTMM é a metodologia referência para Penetration Test e a ISO/IEC 15.408 é a referência para segurança em desenvolvimento de software.
MENTIRA!
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:
É 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.
MENTIRA!
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.
4 de agosto de 2010
Inimigos do Código Seguro
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:
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 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.
28 de julho de 2010
Minha participação no Stay Safe Podcast
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.
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.
24 de julho de 2010
Chamada de trabalhos - OWASP AppSec Brasil 2010
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.
19 de julho de 2010
O Óbvio Ululante
"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.
8 de junho de 2010
Slides da Apresentação no GTS 15 2010 - Explorando falhas em aplicações em Flash
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.
OWASP AppSec Brasil 2010 - Chamada de Mini Cursos
**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/
que deve ser enviado por email para organizacao2010@appsecbrasil.
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.
**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.
Para mais informações, favor consultar as seguintes páginas:
Página da conferência:http://www.owasp.org/index.
OWASP Speaker Agreement (em inglês):http://www.owasp.org/index.
Página do OWASP: http://www.owasp.org
Página da conferência no Easychair: http://www.easychair.org/
Formulário para apresentação de propostas: http://www.owasp.org/images/4/
********* 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.
______________________________
Owasp-brazilian mailing list
Owasp-brazilian@lists.owasp.
https://lists.owasp.org/
**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/
que deve ser enviado por email para organizacao2010@appsecbrasil.
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.
**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.
Para mais informações, favor consultar as seguintes páginas:
Página da conferência:http://www.owasp.org/index.
OWASP Speaker Agreement (em inglês):http://www.owasp.org/index.
Página do OWASP: http://www.owasp.org
Página da conferência no Easychair: http://www.easychair.org/
Formulário para apresentação de propostas: http://www.owasp.org/images/4/
********* 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.
______________________________
Owasp-brazilian mailing list
Owasp-brazilian@lists.owasp.
https://lists.owasp.org/
3 de maio de 2010
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á!
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á!
6 de abril de 2010
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
Página 28 - Avoid EXEC in stored procedures
Página 32 - HTTPOnly Cookies
Página 33 - ClickJacking defense
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.
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.
5 de abril de 2010
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.
31 de março de 2010
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:
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:
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:
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:
Conteúdo dos Campos Lista
1 - Vulnerability Category:
2 - Identified By:
3 - Identification Method:
4 - Identification Method Source:
5 - Requested Security Activity:
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.
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:
- Execute o download do pacote de instalação à partir do endereço http://www.mantisbt.org/download.php.
- Descompacte este pacote no diretório de publicação que será utilizado no Servidor de Aplicação.
- Acesse a URL do web site publicado.
- 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.
- 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:
- Apague o diretório admin do diretório raiz do site.
- Crie um novo usuário e apague o usuário padrão administrator, cuja senha padrão é root. :-)
- 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.
4 de março de 2010
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
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.
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.
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
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:
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.
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.
Assinar:
Postagens (Atom)