Validando as suas ViewModels no asp.net mvc com FluentValidation

É comum, quando trabalhamos com asp.net mvc, utilizarmos as anotações presentes em System.ComponentModel.DataAnnotations. Conseguimos um resultado bacana, validamos de maneira simples as nossas view models e o código fica relativamente simples. Um exemplo simples do que eu estou falando é o seguinte:

Imagine que temos o clássico LoginModel, contendo o usuário, senha e a url de retorno após o sucesso no login:

    public class LoginModel
    {
        public string Email { get; set; }
        public string Senha { get; set; }
        public string ReturnUrl { get; set; }
    }

Após identificarmos que os campos Email e Senha são obrigatórios, podemos rapidamente resolver este problema adicionando um [Required] para cada propriedade obrigatória:
Continuar lendo

Anúncios

Testando Controllers com Fluent MVC

Falar em testes de controller pode ser um pouco polêmico. O motivo é simples: nosso controller normalmente não deve fazer muita coisa, possuir regras de negócio, etc. Há quem defenda que controllers não devem possuir nenhum if, etc. Eu concordo em partes. Realmente, normalmente se há algo que precisa ser feito no controller, ele deverá possuir alguma dependência que fará o trabalho, e o controller no final do dia, vai acabar retornando apenas uma view, um json ou algo do tipo. Mas, deixando essa discussão de lado, quando e como eu devo testar o meu controller?
A primeira resposta é subjetiva. Quando você deve testar qualquer código varia da posição da pessoa que está escrevendo os testes. Há quem defenda que todo o código deve ser testado, há quem defenda que não é bem assim, e por ai vai. Eu parto do principio que se há chances de dar qualquer coisa de errado na execução de um trecho de código, teste! A segunda resposta é ampla, e neste post vou falar do Fluent MVC Testing.

Vamos começar pelo mais simples possível. Temos um controller que apenas retorna uma view:
Continuar lendo

Cuidado com os response headers de sua aplicação!

Imagine a seguinte situação: Alguém quer invadir um site/sistema que você fez. Por onde começar? Quando alguém esta pensando em invadir um sistema, informação é ouro! Saber qual servidor está hospedando a aplicação, qual tecnologia foi utilizada para desenvolver, etc. é de grande importância. Quando criamos um projeto em asp.net mvc, por exemplo, e hospedamos no IIS, sem nenhuma configuração, preocupação com segurança, etc. estaremos informando a qualquer um que faça uma requisição ao nosso sistema, informações como qual a versão do iis que o sistema está hospedado, qual a versão do asp.net que utilizamos, etc. Dê uma olhada nessa requisição que foi feita em um sistema em produção de uma grande multinacional:

response headers

Apenas apertando F12 no chrome ou firefox, sabemos que é um sistema desenvolvido em asp.net 4, utilizando o asp.net mvc 5 e hospedado no iis 7. Até ai tudo bem, mas qual o problema? Sabendo que o sistema está hospedado no iis 7.5, basta uma simples pesquisa no google para descobrirmos as vulnerabilidades do servidor, como no exemplo abaixo:

https://www.google.com.br/search?q=cve+iis+7.5

Ao clicarmos no primeiro link do resultado, já podemos descobrir 5 vulnerabilidades conhecidas do iis 7.5. E tudo isso, qualquer um pode descobrir em menos de 1 minuto.

iis cve

Claro que existem diversas maneiras de se descobrir qual é o servidor que está hospedando a aplicação, qual a tecnologia utilizada, etc. Mas quando estamos pensando na segurança de nossa aplicação, são os pequenos cuidados que fazem com que evitemos grandes estragos.

Então vamos ao que interessa. Vamos criar um projeto em asp.net mvc, hospeda-lo no iss local e ver como estão as coisas por default (neste exemplo, estou utilizando o visual studio 2015 comunity, mas pode ser qualquer versão).

Criei um projeto MVC, sem autenticação e o configurei para rodar no iss local (lembre-se que precisa rodar o visual studio como administrador para utilizar esta opção). Ao rodar o projeto, eis que vemos todos os response headers disponíveis por default:

response headers default

Agora vamos lá, como podemos resolver este problema? Alguns são mais simples, alguns nem tanto. Mas o importante é removermos para evitar futuros aborrecimentos.
Continuar lendo

Como evitar mass assignment no asp.net mvc

Para quem não conhece, Mass Assignment é uma vulnerabilidade onde alguém consegue manipular / alterar informações que elas não deveriam ter conhecimento / acesso. Vamos imaginar a seguinte situação: Você possui a seguinte classe:

public class User
{
    public Guid Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
    public bool IsAdmin { get; set; }
}

Agora você quer criar uma página onde os seus usuários poderão alterar as suas informações, que no caso seriam os campos Nome e Email. Não acredito que seria interessante deixar uma opção para o usuário decidir se ele quer ser administrador ou não do sistema.

Agora vamos imaginar que você está utilizando algum ORM, como o Entity Framework por exemplo. Caso você exponha a classe usuário em sua view, e espere em seu controller um usuário, persistindo-o da maneira que ele foi enviado, você está permitindo que qualquer usuário possa manipular qualquer informação persistida na tabela usuário (ou equivalente). Como isso funciona?

Quando utilizamos o binding do asp.net mvc, ele segue algumas convenções para conseguir realizar o parse das informações enviadas em um objeto. O html para alterar o usuário no caso, ficaria com algo parecido com:

<input type="text" name="Name" />;
<input type="text" name="Email" />;

Quando você submeter este formulário, caso você esteja esperando um User no controller, o asp.net mvc saberá que o input com name “Email” deverá ser preenchido na propriedade com o nome equivalente. Caso você confie neste formulário, e persista as informações da maneira como recebeu, você pode estar dando mais controle do que gostaria ao usuário, no caso, estar recebendo a informação IsAdmin como verdadeiro, mesmo que esta opção não estava inicialmente no formulário. Existem diversas formas de fazer isso, afinal, isso é apenas uma requisição http enviando algumas informações para a sua aplicação. Você pode brincar com o Fiddler caso queira, e ver como uma comunicação pode ser frágil quando não tomamos as medidas certas.

Existem algumas maneiras de evitar uma situação dessas, como criando uma Whitelist ou Blacklist com os parâmetros que você receberá, mas acredito que a melhor alternativa sempre será utilizar view models que representem a sua view, no lugar de expor o seu domínio, e neste caso, suas tabelas do banco em uma página html. Existem diversos outros problemas ao acoplar as suas views com os seu domínio que não abordarei neste post.

Bom, por hoje é isso. Muitas vezes, através de uma pequena falha em como implementamos os nossos sistemas, podemos estar correndo sérios riscos.

Abraço 😉

ps: Lembrando que essas questões não valem apenas para o asp.net mvc. E caso você ache que isso é algo que qualquer um pensaria, saiba que até o próprio github já sofreu com esta vulnerabilidade.

Exemplo utilizando AutoMapper e ASP.NET MVC

Como a própria página do AutoMapper fala, o automapper é um “mapeador” de objeto para objeto. Ou seja, ele facilita a sua vida quando você precisa mapear um objeto em outro.
Mas pq alguém iria querer mapear e converter um objeto em outro? Pq normalmente há conflitos entre o seu domínio e a sua view, ou do seu domínio para o seu serviço. Imagina que você possui uma viewmodel Usuário que possui os atributos necessários para a sua view, contendo todas as validações, etc. Ao enviar para o seu serviço, provavelmente você passará o objeto Usuário do seu domínio, e não o seu viewmodel, certo? Sem o automapper, você não teria muito o que fazer, além de provavelmente ter um método dentro da sua viewmodel que retorna o objeto de domínio, fazendo toda a conversão, teste, etc.
O AutoMapper entra ai para facilitar a sua vida, uma vez que você precisará praticamente de uma única linha de código para realizar o mapeamento.
Continuar lendo

ASP.NET MVC Filters – Utilizando o Action Filter

Bom, hoje eu vou falar um pouco sobre os Filters no asp.net mvc. Utilizar Filters é uma maneira de se trabalhar com o pré processamento e o pós processamento do seu controller e actions. Um exemplo clássico é você querer logar a chamada de uma determinada página, ou então restringir o acesso a determinadas áreas do seu sistema. Imagine a situação em que você precisa verificar se o usuário está logado para realizar determinada ação, porém você não quer poluir a sua action com validações, ou pior ainda, ficar duplicando código pelo seu projeto inteiro. Neste e nos próximos posts, falaremos de alguns tipos de filtros:

  • Action Filter
  • Exception Filter
  • Result Filter
  • Authorization Filter

Action Filter – IActionFilter

Com o Action Filter nós podemos interferir no comportamento da nossa action tanto antes como depois da sua execução. Para isso nós utilizamos a interface IActionFilter:

Continuar lendo

NHibernate – One Session Per Request

Ao trabalhar com NHibernate, um dos principais desafios é gerenciar a Session. Podemos abrir a Session a cada consulta, mas isso seria bem custoso, pois em muitos casos precisamos recorrer ao banco de dados diversas vezes, além de perder uma das grandes vantagens do NHibernate que é utilizar o Lazy Load.
Uma maneira comum de se trabalhar com a session seria da maneira que eu mostro neste post, que ficaria mais ou menos assim:

        using (ISession session = NHibernateHelper.OpenSession()) { }

Porém, se trabalhamos desta maneira, e buscamos uma lista de usuários por exemplo. O código ficaria assim:

    public IList<User> GetAll()
    {
        using (ISession session = NHibernateHelper.OpenSession())
        {
            var users = session.CreateCriteria<User>().List<User>();
            return users;
        }
    }

Continuar lendo