Originally Posted By Elias WagnerRubens,

obrigado pelos comentários.

O post e nem eu me considero verdade absoluta, mas eu continuo não acreditando que usar uma variável global para definir um nome de arquivo e não sanitizar não é uma boa prática. Existem várias referências de falhas que usam do recurso de globals não validadas.

Abs.

Elias, na verdade eu não acho que não seja uma boa prática. Aliás, você está de parabéns em querer sanitizar tudo. Afinal, é muito melhor sanitizar tudo do que não sanitizar nada (e isso acontece aos montes).

Eu, particularmente, procuro refletir sobre as falhas e utilizar tais recursos onde considero realmente necessários. Especialmente por uma questão de processamento desnecessário.

O que soa estranho é quando você critica algo com uma argumentação: “super globais precisam ser sanitizadas sempre”. Com certeza existem muitos casos onde elas precisam, mas outros não.

Acho que um bom livro sobre segurança é aquele que se concentra mais em apresentar a essência das falhas de segurança. E mostra algumas “soluções conhecidas” apenas para ilustrar. Afinal, existem muitas formas para não deixar brechas e todo programador precisa ser critico e ter flexibilidade para avaliar falhas pouco conhecidas também.

Por exemplo: toda linguagem acessada por outra linguagem precisa de tratamentos especiais. SQL é a mais comum, com as SQL injections, mas poucos sabem sobre Mail injection, por exemplo. Enfim, se algum dia eu usar PHP para acessar outra linguagem, tenho certeza que terei que fazer um tratamento especial sobre as variáveis usadas para “montar” o código da outra linguagem. Talvez essa “linguagem” nem exista ainda e a falha não tem um nome popular como “SQL injection” ou “XSS”, mas o importante é já saber como se deparar com ela. A falha é conceitual, não específica.

Abs.

Abs.

obrigado pelos comentários.

O post e nem eu me considero verdade absoluta, mas eu continuo não acreditando que usar uma variável global para definir um nome de arquivo e não sanitizar não é uma boa prática. Existem várias referências de falhas que usam do recurso de globals não validadas.

Abs.

Originally Posted By Elias WagnerRegister Globals habilitado realmente é uma falha grave, inclusive as novas versões já vem desabilitada por default[...]

Elias, não considero register globals uma falha grave. A utilização de register globals PROPICIA o aparecimento de falhas de segurança. E é por este motivo que ele será removido do PHP. Que fique claro que é possível criar código seguro com register globals ativada.

2 – De fato, time não é a melhor função para se gerar o salt. Mas acho que esta é a única coisa inadequada. As principais falhas de segurança relacionadas à autenticação seriam: (i) alguém conseguir descobrir a senha de outra pessoa; (ii) alguém conseguir acessar como outra pessoa sem informar as credenciais adequadas; ou (iii) alguém conseguir testar um pacote de logins/senhas no sistema em busca de um par de valores válidos. O salt está indiretamente ligado apenas ao item (i). Mas, gerando a senha criptografada, já fica complicado obter a senha original, seja com salt ou não. O item (ii) e (iii) são tratados por outros mecanismos. O salt, pra mim, é um detalhe. Por mim pode até intercalar as soluções apresentadas: deixar um pedaço do salt no BD e parte dele ser estático em código. Enfim, é preciso se concentrar nas possiveis falhas, e não apenas no que as pessoas dizem que precisa se preocupar.

3 – Realmente neste ponto o livro errou feio. Referer é definido (opcionalmente) pelo navegador e pode ser burlável. Mas você dizer que todas super globais são editáveis pelo cliente, você se engana também.

Uma coisa eu concordo com você: não podemos seguir tudo aquilo que é publicado. Porém, tenho que admitir que isso também vale para parte de seu texto.

o interessante de um salt por senha é que as hashes calculadas pra quebrar a senha dos outros não vai servir pra _sua_ senha. e também não fica trivial verificar se duas pessoas tem a mesma senha, que é um indício de senha fraquíssima

o ataque que voce parece supor é que as hashes estarão comprometidas, mas o salt estaria em um lugar seguro e inacessível. nesse caso você nem precisa de salt: basta armazenar logo as hashes no suposto lugar seguro e inacessível.

ps: desculpa, mas php security é quase um oxímoro..

Concordo que o uso de um bom salt é essencial e se for complexo o suficiente vai quase impossível reverter a senha com um hash pré-computado.

Em php eu acho mais interessante um salt hard-coded do que em banco de dados.

Esta sim é uma boa abordagem:

“Uma abordagem interessante seria armazenar um pre-salt no banco de dados junto com os demais dados do usuário e aplicar um hmac com uma senha contida em arquivo no servidor a esse pre-salt para gerar o salt verdadeiro.”

Originally Posted By Elias WagnerRegister Globals habilitado realmente é uma falha grave, inclusive as novas versões já vem desabilitada por default. Mas um código deve ser escrito independente das configurações do ambiente.

Se eu ainda escrevesse coisas em PHP, não sentiria dó de colocar um if(ini_get(‘register_globals’)) die(‘Desligue o register_globals seu admin burro’); no começo de cada arquivo .php

Agora eu discordo que é correto armazenar na mesma tabela junto com o hash, como eu disse um SQLi você pega o hash também

Ué, e qual o problema de pegar o hash e o salt com um SQL injection? Se a entropia do salt for boa (salt grande com boa aleatoricidade – que pode ser gerado com mcrypt por exemplo), a probabilidade de encontrar a senha precomputada é ínfima.

De maneira nenhuma concordo com o texto do seu artigo que diz que uma senha hardcoded é mais segura que uma senha encriptada com esquema de salt só porque ela está em um banco de dados e as estatísticas dizem que ataques SQL injection são mais encontrados que LFI e outros. É preciso utilizar criptografia decente sempre, seja onde a a senha estiver armazenada.

O mais adequado nestes casos é armazenar uma string no código ou em um arquivo no server, como o wordpress faz por exemplo. Óbvio que quem configura deve alterar a string padrão.

O que você quis dizer com isso? Armazenar um código em um arquivo no servidor e usar como salt? Se for isso, é extremamente inseguro. Um bom salt é um salt aleatório e totalmente independente para cada usuário diferente. Você poderia fazer hash do código do arquivo no servidor com o nome de usuário, mas mesmo assim não seria tão bom quanto um salt aleatório, pois todos os salts estão sendo tirados da mesma função e não são independentes entre si. Formalmente, teríamos uma grande quantidade de informação mútua entre salts diferentes.

Uma abordagem interessante seria armazenar um pre-salt no banco de dados junto com os demais dados do usuário e aplicar um hmac com uma senha contida em arquivo no servidor a esse pre-salt para gerar o salt verdadeiro.

Mas, sinceramente? Acho desnecessário tanta complicação se o salt usado for realmente bom, segundo os critérios que já citei. É mais provável a incidência de uma falha que permita acesso aos arquivos do servidor que a ocorrência de um salt repetido, dependendo do tamanho do salt.

Não acho uma boa prática sugerir um variável global em uma situação onde ele só precisa informar o nome do arquivo.

Vou tentar montar o ambiente certo para fazer um exemplo da exploração e publico.

Para quem acha que não é necessário validar o $_SERVER['SCRIPT_NAME'] segue aqui uma série de falhas explorando SCRIPT_NAME:

http://osvdb.org/show/osvdb/35502
http://drupal.org/node/324875
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-2431
http://www.milw0rm.com/exploits/3816
http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2010-02/msg00385.html

Muito gente acha que por ser recomendado o SCRIPT_NAME como opção mais segura para o PHP_SELF ele não deve ser validado e isto é incorreto.

Sobre o Salt, concordo que além de armazenar errado a entropia do Salt é baixa, previsível. Agora eu discordo que é correto armazenar na mesma tabela junto com o hash, como eu disse um SQLi você pega o hash também, por exemplo um SQLi como este: http://www.otavioribeiro.com/videos/MSSQL.html

O mais adequado nestes casos é armazenar uma string no código ou em um arquivo no server, como o wordpress faz por exemplo. Óbvio que quem configura deve alterar a string padrão.

Abs.

2) O código de salt do livro não apresenta a vulnerabilidade que você disse. É preciso sim armazenar o salt, todo mundo faz isso. Se você pegar o formato de senha encriptado do /etc/shadow por exemplo, ele vai ter primeiro um identificador do tipo de hash, depois o salt, e depois o hash, concatenados numa mesma string.

O problema no código do livro é outro. O salt é muito previsível, por ser baseado somente no tempo, e isso reduz a complexidade de um ataque por rainbow table, pois é necessário armazenar uma pequena faixa de salts. Se o salt tivesse uma boa aleatoriedade, o espaço de salts possíveis seria bem maior, aumentando a complexidade do ataque.

É claro que é sempre recomendável usar a função crypt do PHP para encriptar senhas, que aliás é capaz de usar hash baseado em blowfish como algoritmo, que é computacionalmente mais complexo que o hash sha1 que ele usou.