Web,ruby, Ajax ou qualquer outra coisa que me venha a cabeça (com prioridade para esta última)

15 dezembro, 2006

Boas práticas - RoR - Segurança

A segurança é um tópico um pouco aborrecido mas que pode tornar-se excitante se fizermos uma grande asneira. Para evitar essas excitações, eis uma lista de verificação para revisão de segurança em modelos, controladores e vistas. Se vir algum buraco (há com toda a certeza vários) faça um comentário e actualizarei a lista.

  • Lista de verificação de segurança para modelos
    • Usar attr_accessible (ou attr_protected se necessário) para identificar explicitamente a identidade de atributos que são acessíveis por .create e .update_attributes. Só porque não expõe um atributo num formulário de alteração não significa que alguém não possa tentar enviar (post) um valor para esse atributo. Prefiro attr_accessible sobre attr_protected porque falha do lado seguro quando são adicionados novos campos ao modelo - tem que expôr explicitamente campos novos.
    • Assegure-se que os inquéritos estão a usar a capacidade de associação de variáveis da Rails para parâmetros e não a concatenação de strings ou a síntaxe da Ruby #{...}.
    • Usar validações para evitar más entradas
  • Lista de verificação para controladores:
    • Tornar métodos de controlador que não sejam acções privados (se possível).
    • Se os métodos de controlador tiverem que ser públicos, identifique-os com hide_action para evitar execução não desejada.
    • Assegure-se que estão a postos os before_filter se necessário na sua infraestrutura de autorização.
    • Mova os inquéritos dos seus controladores para o seu modelo e veja a lista de verificação acima.
    • Verificar o uso de params[:id] - será que pode confiar neles? Verificar a propriedade do registo.
    • Verificar o uso de campos escondidos - um utilizador pode enviar-lhe tudo o que quizer através deles, e assim trate-os como suspeitos tal como params[:id].
    • Usar filter_parameter_logging para evitar a entrada de dados não cifrados sensíveis (palavras de passe, BI, NIF, Cartões de Crédito, etc), nos seus servidores de livro de ponto (logs).
    • Esqueça o seu código de vista por um instante e pense sobre como proteger o seu controlador contra uso malicioso que pode ser sofrido pelos seus métodos expostos. Todos os parâmetros (quer sejam expostos ou não no formulário e sejam ou não visíveis) podem estar sugeitos a ultrapassagem do tamanho esperado, ultrapassagem de qualquer validação baseada no agente utilizador (normalmente um navegador mas nem sempre), ataques com dados mal formados, etc.
  • Lista de verificação para vistas
    • Assegure-se que todos os dados mostrados passam pelo método h(string) ou similar.
    • Eliminar comentários nas suas vistas que não queira que sejam vistos por ninguém.

O que é que falta?

Por omissão a Rails manda todos os parâmetros POST para o livro de ponto (production.log) pelo que deve ser mudado o nível de registo para :warn para evitar o respectivo registo do pedido e os seus parâmetros. Para efectuar esta alteração acrescentar a linha que se segue a config/environments/production.rb:


config.log_level = :warn

Outra possibilidade é, para evitar a perca de informação útil que isto gera, usar um suplemento como o do Kent Sibilev.

Sem comentários: