Após o ASP.NET 1.1, a capacidade de verificar automaticamente se há XSS (ataque de script de sites cruzados) para enviar formulários é introduzido. Quando o usuário tenta usar essa entrada para afetar a página para retornar o resultado, o mecanismo ASP.NET acionará um httprequestValidationExceptionin. Por padrão, a página com o seguinte texto será devolvida:
Este é um recurso de segurança muito importante fornecido pelo ASP.NET. Como muitos programadores não têm idéia sobre segurança e nem sabem a existência de ataques como XSS, menos pessoas sabem tomar a iniciativa para protegê -los. Asp.net é seguro por padrão neste momento. Isso permite que os programadores que não sabem muito sobre segurança ainda escrevem sites com certos recursos de proteção de segurança.
No entanto, quando pesquisei o procurador no Google por HttPrequestValidationException ou uma solicitação potencialmente perigosa. O valor da forma foi detectado do cliente, fiquei surpreso ao descobrir que a solução dada pela maioria das pessoas era desativá -la ao definir validaterequest = false na página ASP.NET. Esse recurso não deve se importar se o site do programador realmente não precisa desse recurso. Eu estava tão assustado com a visão. A conscientização sobre segurança deve estar sempre na mente de todo programador.
Por que muitos programadores desejam proibir a validaterequest? Não há necessidade de dizer isso. Outra parte não é que o usuário permita a entrada de caracteres que causam facilmente XSS, mas odeia essa forma de relatório de erro. Não é o usuário.
Para programadores que desejam lidar bem com esta mensagem de erro sem usar a mensagem de erro de exceção do ASP.NET padrão, não desative o validaterequest = false.
A maneira correta é adicionar a função Page_error () à sua página atual para capturar todas as exceções que ocorrem durante o processamento da página sem processamento. Em seguida, dê ao usuário uma mensagem de erro legal. Se a página atual não tiver Page_error (), essa exceção será enviada ao Global.asax's Application_error () para processamento e você também poderá escrever uma função geral de manuseio de erros de exceção. Se nenhuma função de manuseio de exceção for gravada em ambos os lugares, esta página de relatório de erro padrão será exibida.
Por exemplo, é preciso apenas uma peça de código muito curta para lidar com essa exceção. Adicione este código à página Code-Behind da página:
| A seguir, é apresentado um trecho citado: ProtectedVoidPage_error (Objectsnder, EventArgse) { ExceptionEx = server.getLasterRor (); if (exishttPreQuestValidationException) { Response.Write (digite uma string legal.); Server.clearError (); // Se ClearError () não for ClearError (), essa exceção continuará sendo passada para Application_error (). } } |
Dessa forma, este programa pode interceptar a exceção HttPreQuestValidationException e pode retornar uma mensagem de erro razoável de acordo com os desejos do programador.
Esse código é muito simples, então espero que todos os amigos que não tenham permissão para inserir caracteres como usuários, não proibam esse recurso de segurança à vontade. . Pode.
Para os programadores que proibem explicitamente esse recurso, eles devem entender o que estão fazendo e devem verificar manualmente as seqüências de caracteres que devem ser filtradas, caso contrário, seu site desencadeará facilmente ataques de script de sites cruzados.
Como as páginas com o editor de texto rico devem ser tratadas?
Se a página tiver controles com editores de texto ricos, ele inevitavelmente levará ao envio de tags HTML de classe. Nesse caso, temos que validaterequest = false. Então, como lidar com a segurança?
De acordo com o conselho da Microsoft, devemos adotar uma política chamada de política baseada em segurança e explicitamente permitida .
Primeiro, codificamos a string de entrada com httputilidade.htmlencode () e proibem completamente as tags html nele.
Em seguida, substituímos as tags de segurança em que estamos interessados e somos substituídos por substituir (). Por exemplo, se quisermos ter um rótulo, substituí -lo explicitamente.
O código de amostra é o seguinte:
| A seguir, é apresentado um trecho citado: VoidsubMitbtn_Click (Objectssender, EventArgse) ... { // codificando a sequência de entrada, para que todas as tags HTML sejam inválidas. StringBuildersB = NewsTringBuilder ( Httputilidade.htmlencode (htmlinputtxt.text)); // Então permitimos seletivamente <b> e <i> sb.Place (& lt; b & gt;, <b>); sb.Place (& lt;/b & gt;,); sb.Replace (& lt; i & gt;, <i>); sb.Place (& lt;/i & gt;,); Response.write (sb.toString ()); } |
Dessa forma, permitimos algumas tags HTML e proibimos tags perigosas.
De acordo com os conselhos fornecidos pela Microsoft, devemos permitir cuidadosamente as seguintes tags HTML, porque essas tags HTML podem levar a ataques de script de sites cruzados.
A seguir, é apresentado um trecho citado:
|
Talvez a coisa mais incompreensível aqui seja <MG>. No entanto, depois de ler o código a seguir, você deve entender seu perigo.
| A seguir, é apresentado um trecho citado: <imgsrc = javascript: alert ('hello');> <imgsrc = java 
 script: alert ('hello');> <imgsrc = java 
 script: alert ('hello');> |
É possível causar a execução de JavaScript através da tag <MG> para que o invasor possa fazer o que quiser disfarçar.
O mesmo vale para <estilo>:
| A seguir, é apresentado um trecho citado: <styleType = text/javascript> ... alerta ('olá'); </style> |
| A seguir, é apresentado um trecho citado: Erro do servidor no aplicativo '/yourApplicationpath' Uma solicitação potencialmente perigosa. O valor da forma foi detectado do cliente (txtName = <b>). Descrição: a validação de solicitação detectou um valor de entrada do cliente potencialmente perigoso e o processamento da solicitação foi abortado. Ao definir o ValidateRequest = False na Diretiva da Página ou na seção Configuração. Detalhes da exceção: System.Web.httPreQuestValidationException: um valor potencialmente perigoso. .... |