Cuidados com o EventValidation

EventValidation é uma técnica que foi adicionada na versão 2.0 do ASP.NET e que permite validar o evento que se originou no cliente e que foi renderizado por alguma controle ASP.NET.

É muito comum em aplicações Web habilitar ou desabilitar um determinado controle do formulário. Isso pode as vezes acontecer por causa de uma condicional que, na maioria das vezes, é por causa das permissões do usuário corrente, pois ele não tem acesso aquela determinada funcionalidade. Com isso, imagine que tenhamos um botão no formulário e que as vezes estará habilitado, as vezes não. Como a página é renderizada no cliente, ele tem total acesso ao código fonte gerado; isso quer dizer que ele pode facilmente manipular as informações de postback para o servidor/página de onde originou a resposta e, conseqüentemente, ter acesso ao botão que, no momento, está desabilitado.

Para exemplo, imagine que o botão tenha sido ocultado (Visible = False). Agora, voce pode manipular a página (HTML), adicionar o botão, salvar e página e, finalmente, clicar no botão que foi adicionado. Se a propriedade EnableEventValidation da diretiva da página estiver definda como True (o padrão), uma exceção do tipo ArgumentException será disparada:

Invalid postback or callback argument.  Event validation is enabled using <pages enableEventValidation=”true”/> in configuration or <%@ Page EnableEventValidation=”true” %> in a page.  For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them.  If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.

Agora, se por algum descuido voce desabilitou o EventValidation, o evento Click (server-side) deste botão será disparado, mesmo que voce o ocultou quando a página foi processada e enviada para o cliente. Mesmo que voce não adicione o HTML responsável pelo botão na página, voce poderia facilmente montar uma requisição via objetos HttpWebRequest/HttpWebResponse e no body da requisição, definir os campos, inclusive o campo que foi ocultado e, para isso, podemos utilizar o Fiddler para interceptar a requisição/resposta e entender como montá-la.

Anúncios

Fiddler e Localhost

Para aqueles que usam o Fiddler com IE 7 e não estão conseguindo capturar as requisições e respostas quando estão utilizando proxy, eis aqui uma dica que encontrei no próprio site da ferramenta:

IE7 and the .NET Framework are hardcoded not to send requests for Localhost through any proxies, and as a proxy, Fiddler cannot intercept such traffic.

The workaround is to use your machine name as the hostname instead of Localhost or 127.0.0.1. So, for instance, rather than hitting http://localhost:8081/mytestpage.aspx, instead visit http://machinename:8081/mytestpage.aspx.  Alternatively, you can use http://localhost.:8081/mytestpage.aspx (note the trailing dot after localhost).

…Or, you could Customize your Rules file like so:

static function OnBeforeRequest(oSession:Fiddler.Session){
  if (oSession.host.ToUpper() == “MYAPP”) { oSession.host = “127.0.0.1:8081”; }
}

…and then just hit http://myapp, which will act as an alias for 127.0.0.1:8081.

Fonte: http://www.fiddler2.com/Fiddler/help/hookup.asp