Segurança de aplicação e as ferramentas de teste

Lendo o post do Eduardo sobre a recente divulgação de um comparativo entre três ferramentas de teste de aplicações web, resolvi falar um pouco sobre o que penso sobre o tema.

Pra mim o problema todo é comparar bananas com laranjas. As ferramentas realmente não irão substituir a análise humana, são coisas distintas e complementares.

Outro ponto é, o tipo de ferramenta, as ferramentas cumprem o seu papel, o problema é o uso, expectativa que, se tem delas. O erro mais comum é comprar uma ferramenta e achar que ela irá cumprir todos os pontos relacionados a segurança de aplicação. Alguns vendedores podem usar este argumento, mas no geral todas deixam claro qual o seu propósito.

Para se garantir a segurança de uma aplicação várias atividades devem ser executadas. Atividades que eu classifico como antes, durante e depois do desenvolvimento da aplicação.

Antes

• Treinamento e capacitação
• Implementação de um processo que garanta que boas práticas de desenvolvimento sejam seguidas

Durante

• Acompanhamento e validação de requisitos de segurança
• Testes específicos durante o desenvolvimento

Depois

• Testes black-box buscando verificar a eficácia dos controles adotados durante o desenvolvimento

Portanto, as ferramentas funcionam, mas tem seu propósito bem claro. Apenas uma ferramenta de source review não resolve todos os problemas, assim como uma ferramenta de testes black-box também não.

E o ponto fundamental nesta comparação é: mesmo as ferramentas precisam de alguém capacitado para tirar o melhor delas e interpretar seus resultados e transformá-los em ações práticas para melhorar a segurança das aplicações.

Comunicação durante uma crise/incidente

Para muitos falar em público já é complicado, imagina durante uma crise grave envolvendo vítimas? Existem alguns guides sobre o tema, mas este link tem um apanhado bem completo: Golden rules for the crisis spokesperson.

Política de Segurança da Informação, como não fazer

Eu assino o feed do efetividade há muito tempo, sempre gostei do conteúdo, agora hoje fiquei surpreso com um post: Política de Segurança de Informação: um modelo de como não fazer.

No post ele comenta sobre falhas comuns em PSI (Políticas de Segurança da Informação), não esperem uma avaliação técnica, mas sim um apanhado de coisas óbvias e simples que muito profissional de segurança sênior não é capaz de evitar quando desenvolve uma PSI. Recomendo a leitura, mas segue alguns pontos.

"Tranque tanto a infra-estrutura, que trabalhar se torne complicado demais. Complemento do comentário acima. E há um risco adicional: os usuários vão encontrar “jeitinhos”, como o uso de cópias locais, versões antigas e mídias não-autorizadas." Isso aqui é comum entre profissionais de segurança que só viram as coisas nos livros.


"Diga “não” sempre que lhe solicitarem alguma aprovação. Assumindo que você tenha força suficiente para sustentar um comportamento deste tipo, aí quem vai encontrar jeitinhos serão departamentos inteiros, filiais, e outros agregados." Esta é hilária, quem nunca viu aquele cara do comercial, executivo, soltando pérolas: "Segurança é o escambal eu quero é vender".

"Imponha requisitos de segurança sem as ferramentas e treinamento adequados. Vira letra morta, e ainda por cima custa caro. Segurança precisa ser praticada por todos, o que pressupõe ferramentas e educação." Exatamente isto, a maioria das PSI são "compliance" e nunca aumentaram em nada a segurança das organizações.

"Espere que o SSL resolva todas as questões de segurança de seus aplicativos web. SSL é só o mínimo necessário, e o “cadeadinho fechado” no rodapé do navegador não protege contra as falhas na programação ou na arquitetura." Cadeadinho é ótimo, engraçado que até hoje eu vejo "especialista" falando do cadeadinho na televisão.

"Proíba o uso de pen drives, sem delimitar o acesso à Internet. Os mesmos arquivos que podem entrar ou sair via pen-drive podem fazê-lo via uma grande variedade de sites na Internet. Pen drives são uma
ferramenta, mas o que deve ser restrito é trazer ou levar os arquivos não autorizados que se queira impedir. Só proibir os pen drives é incômodo e ineficaz." Esta é para aqueles que querem implementar todo tipo de controle de end-point e acham que estão seguros.

"Adote novas tecnologias antes que elas tenham maturidade suficiente. Folders, livretos, exposições e as conversas dos vendedores devem ser tomados em conjunto com doses saudáveis de consideração" Bota dose de consideração nisso.

"Contrate alguém só porque ele tem um monte de certificações." Ah, não esqueça de pedir os certificados impressos.

"Exija que seus usuários troquem de senha com muita frequência. …e eles adotarão esquemas fáceis de lembrar (e quebrar), ou escreverão as senhas em algum lugar de fácil acesso." Falar sobre política de senhas merece um post a parte, mas no geral é só um copy-paste de uma política pra outra, a senha tem que ter no mínimo trocentos caracteres...Hum o mainframe só aceita 4 e numérico, F&^&^*&^$&^%^%.

"Ignore requisitos legais. Não é razoável: proibir o que uma norma superior permite, permitir o que a lei proíbe, atribuir a si mesmo o poder de realizar verificações ou praticar ações que potencialmente
violem direitos alheios. Mesmo assim muita gente tenta, todos os dias, e se dá mal na hora de colocar em prática." Isso, monitora, coloca keylogger, as máquinas são da empresa e está na política que vai ser monitorado.

"Assuma que os usuários irão ler a política de segurança porque você pediu a eles. Eles só o farão se precisarem muito. Publicar pode ser o suficiente para que eles venham a conhecer as linhas gerais, eventualmente distorcidas pela Rádio Corredor. Para que os usuários conheçam uma política
detalhadamente, é preciso recorrer a outros meios de educação. Na prática, você não pode assumir nem mesmo que toda a equipe de TI, ou que a maioria dos executivos, vá ler a norma." Se você não vai fazer nada para implementar a política, nem escreva, salve algumas árvores.

"Crie políticas de segurança que você não poderá fazer cumprir. Uma norma cujo cumprimento não é (ou não pode ser) exigido pode ser até mesmo pior do que a ausência de normatização, e acaba servindo apenas para punir culpados depois que a porta já estiver arrombada e as vacas
tiverem fugido do estábulo." Quanto mais diretrizes melhor, é mais compliance.

"Assuma que as políticas não se aplicam aos executivos. Se houver exceções, elas devem constar na norma, e não podem comprometer sua eficácia. Pouco adianta todo o restante do esforço se um gerente puder trazer um pen drive de casa para instalar um programa ou compartilhar um arquivo em uma máquina da rede local. Uma variante do mesmo erro: “Assuma que as políticas não se aplicam ao pessoal de TI”." Executivos? Geralmente nem a área de segurança cumpre as diretrizes por eles impostas.

"Deixe seu anti-vírus, IDS e outras ferramentas rodando no piloto automático." Ué, paguei uma grana nas ferramentas pra que?

"Tente aplicar o mesmo rigor a todos os ativos de informação, independente do seu perfil de risco. Fica
bem mais caro do que deveria, atrapalha processos sem necessidade, e prejudica bastante a adoção e internalização pelas pessoas envolvidas" Hum, gestão de riscos? Mas eu já tenho uma PSI.

"Dê a alguém o título de Gestor dos Riscos, mas não lhe dê o poder de tomada de decisões correspondente. Ele terá que optar entre se omitir, ou ser o chato que fica apontando
riscos nas atividades alheias podendo ser ignorado, ou ainda saber que está lá só para levar a culpa" Quem está nesta situação deixa um post no blog. Hum melhor não, vai encher meu blog de conteúdo inútil.

"Ignore o quadro geral, e se concentre nas análises quantitativas. É mentalmente desafiante e muito interessante aplicar os modelos matemáticos de quantificação de riscos, mas eles não podem substituir a visão do todo, e sim complementá-la." ROSI, ROS, uhuhu

"Classifique todos os seus dados como “top secret”. Nivelar por cima, nesse caso, tem praticamente o mesmo efeito que nivelar por baixo." É classificação da informação e não "rotulação" da informação.

Recomendo a leitura, você vai dar boas risadas e ainda pode aprender um pouco sobre PSI. Só não vai ficar deprimido caso se enquadre em muitas das coisas listadas.

Analisando código php encriptado

Stefan Esser publicou informações bem interessantes sobre o core do php. Na última 25C3 ele fez uma apresentação demonstrando como é possível fazer análise em códigos encriptados usando bibliotecas de encriptação de Bytecode como: ZendGuard, ionCube PHP Encoder e SourceGuardian.

Segundo o paper mesmo com técnicas de anti-hooking e decryption é possível analisar o código devido as padrões do bytecode que são mantidos. Leitura altamente recomendada.

u-Con 2009

Em Fevereiro vai acontecer em Recife, mais uma edição de uma das principais conferências sobre hacking/security. Estarei lá ministrando um treinamento de Web Hacking Techniques e a Conviso está apoiando o evento.

Mais informações no site da conferência, como diria meu amigo sp0oker: Happy Hacking!

Twitter?

É eu me rendi a mais uma "ferramenta" geek! Eu conheci o twitter há algum tempo atrás e confesso que achei meio bobo, sem sentido. Conversando com alguns amigos eu fui convencido a olhar com mais calma, afinal, poderia ser mais uma ferramenta para troca de idéias, opiniões, sobre o que eu penso e faço no meu dia-a-dia.

Bom, fui lá e dei-um "Forgot password" e resolvi começar a "twittar" (é assim que se fala?).

Quem quiser acompanhar e claro, apreciar com moderação, é só me incluir (é assim? Calma, estou começando.) acessando a URL: http://twitter.com/welias

Pen-test não morre não, fiquem tranquilos!

No início de Dezembro Brian Chess co-fundador da Fortify escreveu um artigo para o portal CSO Online com o seguinte título: Penetration Testing: Dead in 2009.

Como o título foi extremamente sensacionalista e na minha opinião, as declarações de Chess foram bastante parciais em favor do produto/negócio da Fortify, as interpretações não foram as melhores.

Ivan Arce CTO da Core Security escreveu um outro artigo para o mesmo portal com o título: Twelve Reasons Pen Testing Won't Die

Neste artigo Arce "contra-ataca" Chess e faz uma brincadeira criando o acrônimo, SISSP (School of Information Systems Security Prophets) e descreve de forma muito clara inúmeros motivos para se realizar testes de segurança (pen-tests).

No maior estilo Schopenhauer, Chess, escreveu outro post no blog da Fortify: Penetration Testing is Dead, Long Live Penetration Testing

A minha opinião sobre esta novela toda é: Muda-se o nome, muda-se a "roupagem" mas os testes de segurança sempre deverão ser feitos. Afinal, como será garantido que os produtos mesmo após um bom SDL (secure Development Lifecycle) são realmente seguros como deveriam ser? Como diria Michael Howard: "Ou você testa ou alguém ira testar por você".

SDL e falha de XML Parser do Internet Explorer

Um excelente post no blog Security Development Lifecycle, fala sobre a falha de XML Parser que afeta algumas versões do Internet Explorer da Microsoft.

A falha irá causar algumas mudanças na capacitação dos desenvolvedores, segundo o post o conteúdo dos treinamentos voltados ao SDL (Secure Development Lifecycle) não cobre com clareza a falha que ocorreu.

"Code Analysis and Review

Memory-related TOCTOU bugs are hard to find through code review; we teach TOCTOU issues, and we teach memory corruption issues, and issues with using freed memory blocks; but we do not teach memory-related TOCTOU issues. We will update our training to address this.

Our static analysis tools don't find this because the tools would need to understand the re-entrant nature of the code."

Devido a característica bastante peculiar da falha, muito provavelmente a falha foi encontrada por acaso, pois até mesmo as técnicas de fuzzing (considerada bala de prata por alguns) não conseguiriam identificar facilmente.

"Fuzz Testing

In theory, fuzz testing could find this bug, but today there is no fuzz test case for this code. Triggering the bug would require a fuzzing tool that builds data streams with multiple data binding constructs with the same identifier. Random (or dumb) fuzzing payloads of this data type would probably not trigger the bug, however."

Outro ponto é a questão da compatibilidade entre as versões. Devido a compatibilidade com versões anteriores não é usado ASLR e NX, o que poderia ter amenizado o problema.

"ASLR and NX

Even though Windows Vista and Windows Server 2008 have both ASLR and NX enabled by default, Internet Explorer 7 does not opt-in to these defenses owing to compatibility issues with many common applications. Internet Explorer 8 enables these defenses by default, but an attack could be mounted by calling a component that does not use these defenses, and then by using an attack technique known as heap-spraying get the attacker's code into the non-ASLR and non-NX memory. This is why it's so important to build components for Windows that use all the available Windows defenses. Matt Thomlinson and I wrote an article on this subject, and David LeBlanc and I wrote Writing Secure Code for Windows Vista that covers the subject in much more detail."

Treinamentos em Janeiro

A Conviso IT Security oferece no primeiro trimestre de 2009, os cursos "Internet Hacking Techniques" e "Web Hacking Techniques" em várias capitais brasileiras:

Internet Hacking Techniques

Ensina o processo de análise de vulnerabilidades técnicas em redes de dados, incluindo técnicas para teste de intrusão (pen-test), scan de vulnerabilidades, testes de resistência de senhas e análise do controle de acesso a dados.

Belo Horizonte: 12, 13 e 14 de janeiro
Manaus: 19, 20 e 21 de janeiro
Recife: 21, 22 e 23 de janeiro
Curitiba: 26, 27 e 28 de janeiro

Web Hacking Techniques

Ao entender as principais vulnerabilidades em aplicações web e como evitar que elas sejam criadas, os alunos deste curso aprendem a revisar a segurança das aplicações web, além de serem capacitados em práticas de programação segura e no uso de ferramentas Open Source para testes de segurança e criação de medidas de proteção neste modelo de aplicação.

Belo Horizonte: 15 e 16 de janeiro
Manaus: 23 e 24 de janeiro

Calendário dos Cursos: http://convisosec.com/yahoo_site_admin1/assets/docs/CSTR_Calendario_2009_V2.35175159.pdf

Browser Security Handbook

O Google lançou um book em versão wiki que, descreve várias características de segurança de diversos browsers. A wiki é atualizada constantemente e é um material interessantíssimo para quem deseja conhecer um pouco mais dos "internals" dos browsers.

As informações são valiosas para quem deseja ir além do debug.print/echo POST/GET no desenvolvimento web. Recomendo fortemente a parte 3 - Experimental and legacy security mechanisms.

O conteúdo se mostrou bastante imparcial e não é voltado apenas para o Chrome do Google.

php, Estefan Esser, e a saga

No último dia 04/12/2008 Stefan Esser, divulgou um advisory que anunciava uma falha no método ZipArchive::extractTo() do php 5.2.6. A falha é um Path Traversal e extremamente simples de explorar. Para explorar a falha é necessário que o sistema utilize o método ZipArchive::extractTo() para upload e fazer a descompressão automática (Muitos CMS utilizam isso). Para quem necessita deste recurso o único meio de tratamento é upgrade para versão 2.5.7. Mais detalhes sobre o advisory estão publicadas neste link.

No Domingo 07/12/2008 o mesmo Stefan Esser, fez alguns comentários sobre os backports relacionados a segurança e disse para tomar cuidado com o upgrade, pois o upgrade para a versão 5.2.7 irá quebrar a diretiva de magic_quotes. Qual o problema disto? Acreditem, muitas aplicações dependem única e exclusivamente disto para tratar problemas de SQL Injection e afins.

Já hoje dia 09/12/2008 novamente ele, anunciou um projeto bem interessante que ele vinha trabalhando e disponibilizou a primeira versão para download. O projeto chama ext/usim e permite que você teste o upgrade para versões mais recentes, assim você pode testar se a sua aplicação irá se comportar perfeitamente nesta versão.

Será que até o final da semana ele vai soltar mais uma?

Coisas que me irritam e espero que mudem

Entre um dia corrido e outro, vou anotando algumas coisas. Quem me conhece sabe, minha área de trabalho é cheia de arquivos texto onde escrevo de tudo, uns comandos que estou começando a usar, um script, algumas referências para ler com mais calma e também coisas do dia-a-dia.

Entre as coisas que venho observando há anos e sempre faço uma anotação ou outra é sobre o mercado de segurança da informação. Está certo que eu sou um pouco mais rabugento que a média, mas muita coisa é de irritar, as anotações servem como válvula de escape. As vezes leio algo ou passo por uma situação e a primeira coisa que vem a cabeça é: vou escrever um post e soltar o verbo, mas acabo anotando e observando um pouco mais. É verdade, as vezes escapa e acabo falando demais. Hoje eu decidi falar sobre uma coisa que me incomoda profundamente.

Profissionais que adoram falar sobre código de ética, classificação da informação, política de segurança e plano de continuidade de negócios

Mas Wagner, você sempre defendeu estes pontos? Sim, eu sempre defendi e acho super importante estes pontos, mas, (a quem diga que após um mas sempre vem uma crítica. :) ) eu estou cansado de encontrar "Grandes" profissionais do mercado de segurança da informação que, nunca implementaram nada, não sabem do que falam e se colocam em posição de sênior e superior a todos que não falam as palavras da moda e não lêem revistas de negócio. Vou dar umas dicas para quem deseja ser este profissional altamente desejado e merecedor de bons cargos e salários.

• Gaste boa parte do seu sálario com um bom terno, camisas, abotoaduras e sapatos bem lustrados;


• Leia todos os livros de auto-ajuda e os nacionais de segurança da informação;


• Faça lobby, muito lobby. Vale convidar para fumar charutos (mesmo que você odeie qualquer tipo de coisa parecida com cigarros), degustar vinhos caros (mesmo que você goste mesmo é de uma cerveja bem gelada);


• Fale muito daquela viagem que você fez para Miami e Buenos Aires, isso é chique, (não é tão chique assim, mas é o que você consegue pagar, pois os ternos são caríssimos) os executivos gostam disto;


• Critique a postura alienada dos técnicos que salvam sua pele, garantem o seu salário e lhe passam as informações para montar aquela maravilhosa apresentação "vendendo" sua área. Afinal, o que seria destes técnicos sem todo seu poder de relacionamento inter-pessoal e astúcia com o power point?

E a regra de ouro é: nunca participe de listas de discussões, não tenha um blog, não tenha opiniões fortes. Isso é exposição demais para um "Grande" profissional como você. Vai que alguém descobre que você é um charlatão, que tudo que você aprendeu nos livros é meia dúzia de palavras e conceitos.

Sobre os temas mais citados em gestão de segurança da informação, IMHO é bem simples:

Código de ética: ou você tem ou não tem. Se você precisa a todo momento ficar falando sobre ética é porque você almeja muito e não tem. Vejo muitos profissionais falando o tempo todo, citando, escrevendo, enormes códigos de ética e na primeira oportunidade o "Gersão" surge dentro deles e a ética só vale para os outros;

Classificação da Informação: super importante e um tema muito interessante, mas quem consegue aplicar da forma como os "Grandes" falam? Escrever políticas e colocar rótulos em algumas informações não irá mitigar nenhum risco;

Plano de Continuidade de Negócios: um dos temas que mais me fascina, me dedico bastante a aprender e estudar o tema, porém, na maioria das vezes só tenho contato com BCP (Bullshit Compliance Plan). Tudo não passa de discurso, um monte de papel sem sentido e algum mané dizendo que vai salvar o mundo com este monte de papel.

Eu acredito muito em segurança da informação, já vi muitos casos de sucesso e conheço grandes profissionais, senão fosse isto eu já havia desistido. Ainda sou Brasileiro e não desisto nunca, acredito na "queda das mascaras" e na maturidade do mercado de segurança da informação e no surgimento de mais Profissionais capacitados e capazes de lidar com todos os riscos que nos assolam todos os dias.

[Update] Resolvi deixar uma coisa bem clara, afinal acho que as interpretações foram diversas. Eu não acredito que todas as pessoas que tomam vinho, se vestem impecavelmente e fumam charutos são charlatonas, a mensagem é bem direta: quem é charlatão que se identifique. Como disse ao Lincoln nos comentários, as pessoas podem ser opostas a estas características e serem charlatonas. Muitos gerentes, executivos em geral gostam de tudo que falei e são responsáveis pelo sucesso de muitas áreas e organizações, estão longe de ser charlatões, se preocupam em ser e não em ter. Apreciem o texto com moderação. :)

SQL Injection e as funções de escape no php

Acredito que todos que acompanham este blog e até mesmo quem tenha qualquer contato com desenvolvimento WEB saiba o que é um SQL Injection e o que se deve evitar para combatê-lo, porém, todos os dias eu me deparo com técnicas ineficazes para tratamento de ataques de SQL Injection baseados na dupla php e MySQL.

A maioria destas técnicas para tratamento de SQL Injection fazem referência a funções de escape ou o popular magic_quotes do php, porém poucos devem saber que estas técnicas são ineficazes para evitar este tipo de ataque. A simples adição de uma barra invertida (" \ ") em uma string que contenha um apóstrofo (" ' ") não irá eliminar a possibilidade de exploração de ataques baseados em SQL Injection.

As funções de escape mais conhecidas são addslashes() e mysql_real_escape_string(). Estas funções irão fazer a seguinte transformação em uma string.

String normal = 'admin'
String com escape = \'admin\'

Agora o que poucos sabem é que o MySQL possibilita que você faça consultas de caracteres baseados na tabela ascii. Execute no MySQL a query: select ascii('a'); e você terá a o código da letra a que é 97. Agora faça o oposto, execute a query: select char(97); e você terá o caracter a. Isso quer dizer que podemos representar strings SQL usando os códigos ascii. Se usarmos a função concat() podemos montar uma query inteira usando os códigos ascii.

Execute a seguinte query no MySQL:

select concat(char(39), char(104), char(116), char(116), char(112), char(58), char(47), char(47), char(119), char(97), char(103), char(110), char(101), char(114), char(101), char(108), char(105), char(97), char(115), char(46), char(99), char(111), char(109), char(39))

O resultado será:

'http://wagnerelias.com'

Reparem que na string criada usando a função concat não é representado o apóstrofo (" ' "), com isso as funções de escape não teriam efeito algum. Portanto, cuidado com as funções de escape, muitas vezes elas não irão lhe salvar de um ataque de SQL Injection. Sempre que possível use Bind Variables implementando as Prepared Statements do MySQL.

Palestra - Tratando as vulnerabilidades do Top10 da OWASP

Nesta sexta-feira dia 28/11 eu palestrei na Php Conference! Obrigado pela presença de todos e estou disponibilizando os slides da palestra.

Tratando as vulnerabilidades do Top 10 com php

View SlideShare presentation or Upload your own. (tags: phpconference2008 php)

Pen-test by Adobe or Office

Uma prática horrível invadiu o mercado de pen-test, se é que podemos chamar isso de prática. A técnica consiste no envio de arquivos do office ou arquivos pdf com algum tipo de backdoor. Utilizando pura e simplesmente de engenharia social a empresa contratada para testar os controles de segurança envia um arquivo malicioso que, pode ser um currículo em pdf para o RH. Naturalmente alguém irá abrir o arquivo, e após isso é "OWNADO" e o FUD começa, direito a filme e tudo.

Pergunta: que controle você testou com isso? Você apenas irá saber que precisa de uma campanha de conscientização, não terá nenhum tipo de validação dos controles de perímetro da sua rede.

Testes como esse podem ser usados para testar o nível de conscientização de seus usuários, mas nunca como ferramenta de avaliação de controles técnicos. E lamentavelmente muitos acham isso a última maravilha do mercado de segurança, pois, saibam todos que a técnica já não tinha nada complicado e agora ficou mais prático e banal com a implementação desta feature no metasploit 3.2. vejam os exemplos a seguir:

Criando um pdf com backdoor

Criando um arquivo do word com backdoor

Agora faça o seguinte, procure profissionais sérios e competentes para testar seus controles de segurança, não aceite qualquer coisa.

Palestra H2HC 2008

Estou disponibilizando os slides da minha palestra na H2HC deste ano. No site do evento em breve estará disponível os slides de outros palestrantes.

Extreme Web Hacking - h2hc 2008

View SlideShare presentation or Upload your own. (tags: h2hc)

Hardening de sessão no PHP

Php é criticado, muitas vezes pwned, mas eu gosto. Acho uma linguagem que lhe dá muitas opções, tem uma grande comunidade, possui vasta documentação (ok, eu sei que a maioria das pessoas nem sabe que isso existe) e a maioria dos projetos open source tem algo em php. O meu envolvimento com php veio fuçando em projetos open source.

Lógicamente que devido a sua popularidade e a possibilidade de fazer qualquer coisa, o php acaba protagonizando coisas horríveis. Já ouviram a expressão: "Arma na mão de macaco"? Isso também acontece com php!

Bom, já dei muita desculpa, gosto de php e pronto!

Eu, tenho lidado com sistemas que possuem muitas falhas de segurança devido a problemas de gestão de sessão, por isso decidi escrever algo sobre as sessões do php.

Até um macaco autista consegue trabalhar com sessões no php, basta olhar o manual: Funções para sessão.

Mas como qualquer função ela merece alguns cuidados, um simples session_start e um session_unset não é suficiente caso você queira garantir a integridade dos dados da aplicação.

A primeira coisa que deve ser feita é realizar algumas configurações que irão aumentar a segurança da gestão de sessão do php. Os seguintes itens devem ser alterados no php.ini:

O nome da sessão

default: session.name = PHPSESSID
hardening: session.name = Uma string que você determinar

Path onde será armazenado a sessão no servidor

default: session.save_path = Diretório de armazenamento Temporário da Máquina(tmp)
hardening: session.save_path = Defina um diretório onde as configurações de permissão foram alteradas e somente o acesso pela aplicação é permitido.

Cookies mais seguros

Apesar da possibilidade de desenvolver algo "cookieless" é mais prático e eficaz fazer algumas configurações para aumentar a segurança dos cookies.

Uma boa prática é você não permitir que seja acessada por javascript o cookie de sessão, ataques de XSS podem ser evitados. Para isso determine que o cookie será acessado apenas por HTTP.

default: session.cookie_httponly = 0
hardening: session.cookie_httponly = 1

Se você possui o recurso de HTTPS, force o envio apenas por HTTPS.

default: session.cookie_secure = 0
hardening: session.cookie_secure = 1

A gestão de sessão usa algoritmos de hash para gerar os IDs de sessão. Por default o php usa o algoritmo md5 (128 bits), mas como já deve ser conhecimento de todos, ele já não é o mais confiável. Então altere o algoritmo de hash para SHA-1 (160 bits).

default: session.hash_fuction = 0
hardening: session.hash_fuction = 1

Com estas configurações você já vai ter mais segurança nas sessões do php, existe outras functions que podem ser alteradas, consulte o manual.

Você já garantiu um pouco mais de confiança as sessões, mas também é necessário cuidado ao manipular/usar os recursos de sessão. algumas dicas são:

• Se possível determine o tempo que o cookie de sessão expira o mais baixo possível;


• Use a seguinte sequência sempre que iniciar uma sessão:

session_destroy();
session_regenerate_id();
session_start();

Isso irá garantir que a sessão será destruída e um novo id será gerado sempre que você iniciar uma sessão.

Não seja um macaco com uma arma na mão, use os recursos da linguagem.

Testes de Segurança de Software (Tech-Ed 2008)

A minha palestra sobre segurança em desenvolvimento no tech-ed me surpreendeu! Primeiro, pelo número de pessoas, mesmo acontecendo no mesmo horário que a do Steve Riley, a sala lotou. Segundo, pelo interesse dos participantes. Ano passado tinhamos 3 palestrantes falando sobre segurança em desenvolvimento e poucas pessoas participaram. Estou disponibilizando os slides da minha palestra!

Testes de Segurança de Software (tech-ed 2008)

View SlideShare presentation or Upload your own. (tags: testessegurança)

Uma captcha diferente

Não sou um grande fã das implementações de CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart). Geralmente elas são tão complexas quanto o acrônimo. São um terror para algumas pessoas. Acessibilidade é péssima!

Agora eu achei essa solução interessante, letras grandes e qualquer pessoa consegue facilmente "resolver", ainda temos o problema de acessibilidade com deficientes visuais que utilizam softwares para leitura, mas é mais interessante que as tradicionais. A solução chama-se grapcha e se baseia na biblioteca Graphviz. Você tem que começar a ler o desafio de start a stop. Dê uma olhada no gráfico gerado pela palavra Wagner.

Clickjacking

Na última conferência AppSec promovida pela OWASP em New York, Jeremiah Grossman e Robert Hansen aka RSnake, sacudiram a conferência após o cancelamento da apresentação onde eles iriam mostrar uma prova de conceito de uma vulnerabilidade que ficou conhecida como Clickjacking (sequestro de clique).

Basicamente a vulnerabilidade possibilita que alguém mal intencionado inclua um botão falso, que leva o usuário a clicar em um link que ele acha ser confiável, mas está sendo manipulado. Eles disponibilizaram um vídeo onde é possível visualizar o PoC. Prestem atenção no ponteiro do mouse!

Clickjacking Camjack Demonstration from Jeremiah Grossman on Vimeo.

Segundo os pesquisadores, é possível explorar a falha por características dos browser e do flash player. Uma solução alternativa para o problema é utilizar o plugin No-Script.