segunda-feira, 10 de dezembro de 2012

Desenvolvi minha aplicação em Ruby on Rails, estou seguro?

O framework para desenvolvimento de aplicações web Ruby on Rails já vem por padrão com proteções contra alguns tipos de ataques e oferece vários  métodos que auxliam o desenvolvedor a deixar sua aplicação segura.
Agora, se você me perguntar "estou seguro?" a princípio minha resposta seria "depende!". Neste texto vou considerar que o framework Ruby on Rails, em si, não tem nenhum furo de segurança. "Ah! quer dizer que o framework Rails tem furos de segurança". Não exatamente, mas, vez por outra, aparece uma nova versão que diz que foi consertado ítens de segurança, assim como em qualquer outro framework Java, .Net ou em sistemas operacionais como o Windows e Linux ou em banco de dados e aplicações em geral.
De agora em diante vamos nos preocupar, apenas, na codificação de sua aplicação.
Vamos começar com o exemplo mais básico, mas que muito desenvolvedor costuma errar, veja o código abaixo:
Product.where("name LIKE '%" + params[:name] + "%'")
Duas lições que devem ficar na sua memória sempre e em qualquer linha de código que você criar.
1. Nunca confie em, absolutamente nada, que o usuário vai digitar.
2. Novamente, nunca confie em, absolutamente nada, que o usuário vai digitar.
A partir dessas duas lições, vamos notar que o usuário pode burlar a consulta e inserir comandos SQLs indesejados (SQL Injection). Logo, ao invés de usar concatenação de strings, use a interpolação disponível no framework que, por si só, vai tratar o Injeção de SQL:
name_like = "%#{params[:name]}%"
Product.where("name LIKE ?", name_like)
Mas concatenando strings não é única maneira de fazer Injeção de SQL. Imagine só uma view com esse campo em um formulário:
<select name="report">
    <option value="weekly">Vendas Por Semana</option>
    <option value="monthly">Vendas Por Mês</option>
    <option value="yearly">Vendas Por Ano</option>
</select>
Chamando o método send em uma classe de Model você pode estar dando espaço ao atacante para roubar dados ou até mesmo destruir informações, veja o exemplo sendo passado por parametro a opção escolhida:
Sell.send(params[:report])
Agora imagine se o atacante mudar um "option" por isso:
...
<option value="destroy_all">Vendas Por Semana</option>
...
Ou seja a classe de Model "Sell" executará o método destroy_all que apagará todos os dados da tabela. Para resolver este problema você poderia simplesmente fazer:
allowed_methods = ['weekly', 'monthly', 'yearly']
if allowed_methods.include?(params[:report])
    Sell.send(params[:report]) 
end
Ou seja, apenas os métodos permitidos para exibir relatórios podem ser executados pela classe de Model "Sell".
Programação é algo bastante dinâmico e não podemos nos limitar a estes dois exemplos apresentados aqui, é preciso sempre estar atento a novas oportunidades que um atacante pode explorar. É como já disse antes, e vou repetir:
Nunca confie em, absolutamente nada, que o usuário vai digitar.
Vamos dar uma olhada agora em outro tipo de ataque. Um tipo de ataque que é feito na View de sua aplicação: a Injeção de JavaScript (Cross-Site Script ou, apenas, XSS).
No Rails, qualquer variável com caracteres <, >, ', " e & serão substituídos por &lt;, &gt;, &#x27;, &quot; e &amp;, respectivamente. Desta maneira, sua aplicação fica livre de ataques por Injeção de Javascript.
Primeiramente vou indicar que evite o máximo o uso do método html_safe para variáveis, pois este método autoriza que os caracteres mencionados acima não sejam substituídos, podendo desta forma deixar sua aplicação vulnerável.
Vamos dar um exemplo bem simples e, aparentemente, ingênuo de um formulário que ao ser submetido troca o cor de fundo de uma DIV em uma página web. Exemplo:
<form action="/tests/" method="get">
    <select name="color">
        <option value="#0000FF">Azul</option>
        <option value="#FF0000">Vermelho</option>
        <option value="#00FF00">Verde</option>
    </select>
    <input type="submit">
</form>

<div style='background-color: <%= (params[:color] || "#0000FF").html_safe %>'>
    Um texto qualquer
</div>
Se o atacante mudar uma option para:
...
<option value=""><script>alert('ok');</script>">Azul</option>
...
Com isso a atacante pode mudar qualquer informação da página web ou, pior, redirecioná-lo para um outro site, contendo uma página igual a que você queria mas onde o atacante tem plenos domínios sobre o que você digita em formulários, podendo, inclusive, pegar o número do seu cartão de crédito.
Se você realmente precisar usar o método html_safe use junto com o método content_tag do framework Rails para evitar o surgimento dessas vulnerabilidades, Por exemplo:
...
<%= content_tag 'div', 'Um texto qualquer', :style => "background-color:#{(params[:color] || "#0000FF").html_safe}"  %>
...

Conclusão

Como já foi dito, programação é muito dinâmica, é preciso ficar atento a tudo que pode se tornar vulnerabilidades em sua aplicação. Todos os dados de entrada que o usuário fizer devem ser tratados com atenção especial e ter restrições. Além disso, todos os dados que serão exibidos, também, devem ter atenção especial e devidamente tratados logo antes de sua exibição.
Se você tomar todos esses cuidados, muito provavelmente sua aplicação estará segura contra esses ataques mencionados, seja qual for a linguagem e framework escolhidos.


Autor do Post

Desenvolvedor antenado em segurança de aplicações, louco por tecnologia e sempre disposto a resolver algum problema. Gosta de Rock n' Roll das antigas e de um bom jogo de futebol

Nenhum comentário:

Postar um comentário