Começando com ASP.NET 5 – arquivos de configuração, console logger

Vamos continuar com o nosso projeto. Vamos agora adicionar logs para o nosso server. É sempre útil vermos os logs enquanto desenvolvemos. Poder ver algum erro, o que está sendo chamado, etc. Para isso, vamos adicionar a dependência de ILoggerFactory em nosso project.json.

"Microsoft.Extensions.Logging": "1.0.0-rc1-final",
"Microsoft.Extensions.Logging.Console": "1.0.0-rc1-final"

E agora podemos adicionar a dependência de ILoggerFactory em nosso método Configure, dentro de Startup.cs:

public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory)
{
    loggerFactory.AddConsole(minLevel:LogLevel.Verbose);
            
    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });
}

Com isso, estamos registrando os eventos no console do nosso servidor. Note que agora ao acessarmos uma página, podemos conferir o que está acontecendo por de baixo dos panos:
Continuar lendo

Começando com ASP.NET 5 – Adicionando o mvc, dependências e middlewares

ASP.NET-5-Middleware-Pipeline-and-Startup-Class

A ideia inicial era escrever apenas um post falando sobre o asp.net 5, e fazer uma aplicação simples tentando mostrar as diferenças para as versões anteriores. Como acabou ficando muito grande, decidi quebrar em pequenos posts. Você pode conferir no post anterior como preparar o ambiente, algumas coisas que mudaram, como criar um projeto, etc. Como eu comecei com um template vazio, vamos implementando aos poucos o que precisamos. Vamos começar adicionando as dependências do Mvc. Adicionar uma referência ficou bem fácil. Basta ir no arquivo project.json e adicioná-la dentro de dependencies

"dependencies": {
    "Microsoft.AspNet.Server.Kestrel": "1.0.0-rc1-final",
    "Microsoft.AspNet.Mvc": "6.0.0-rc1-final"
  }

Agora podemos adicionar o método ConfigureServices dentro de Startup.cs com o seguinte código:

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
}

Continuar lendo

Começando com ASP.NET 5

Primeiramente, feliz natal para todos! Agora vamos ao que interessa! Como muitos devem saber, o asp.net 5 ainda está em desenvolvimento, porém ele já em release candidate. Podemos conferir as previsões para novas versões no github:

Milestone Release week
Beta6 27 Jul 2015
Beta7 2 Sep 2015
Beta8 15 Oct 2015
RC1 Nov 2015
RC2 Feb 2016
1.0.0 Q1* 2016

Mas como já estamos em Release Candidate, muitos bugs já foram corrigidos, as coisas já estão bem parecidas como serão em sua versão final e nada mais justo do que começarmos a ver as diferenças de suas versões anteriores, o que podemos aprender de novo, etc.
Continuar lendo

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

Como criar um keylogger em javascript com apenas 4 linhas de código

Keyloggers são normalmente conhecidos por serem programas de computador que registram tudo o que você digita. O que algumas pessoas desconhecem é a existência de keyloggers em sites vulneráveis. Agora a pergunta que não quer calar: Porque eu deveria me preocupar com um keylogger em javascript se a pessoa que desenvolveu o sistema possui controle sobre o que vai ser carregado ou não, minhas informações pessoais, etc? A resposta é simples, não é quem desenvolveu o sistema que injeta um código desses. Já ouviu falar em man in the middle? ou Cross Site Scripting? Dependendo de onde você está acessando um site, da rede, do seu computador, ou até mesmo do seu ISP, dependendo de como o site/sistema que você está acessando foi desenvolvido, ao logar-se por exemplo no sistema, você pode estar enviando todas as informações digitadas para um outro servidor sem saber. Como isso acontece pode variar, pode ser alguém interceptando a sua requisição e injetando o javascript no response, pode ser um banco de dados que foi comprometido com alguma informação, ou até mesmo um link que você acessa, e sem perceber estava passando uma querystring comprometida. O que quero mostrar aqui é que, com apenas QUATRO linhas de código e um sistema feito sem pensar na segurança pode comprometer todos os seus usuários. Acredito que todo mundo que já programou alguma vez qualquer coisa voltada para web, já se deparou com javascript e está acostumado com eventos, como este:
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