When the program is written with parameterized SQL statements can effectively prevent SQL injection, but when the program once formed, and then to modify a large number of database execution statements is not too realistic, on the Web Forms on the input verification is easy to implement method. On the WebForm page, turn on the check property:
Validaterequest= "true"
<%@ page language= "C #" autoeventwireup= "true" codebehind= "Line.aspx.cs" inherits= "Ecospsite.line" validaterequest = "true"%>
But sometimes it is not so good, can only write code to check the user's input, if directly on the page to add a check, the workload is large, and requires a lot of testing work, in the Global.asax to add interception method or more appropriate.
voidApplication_BeginRequest (Objectsender, EventArgs e) { stringPath = This. Request.Path.ToLower (); System.Collections.Generic.List<string> group_sql =Newsystem.collections.generic.list<string>();
Group_sql. AddRange (New string[] { "a.aspx","b.aspx","c.aspx", "D.aspx","e.aspx","f.aspx" });
foreach(stringIteminchgroup_sql) { if(path. EndsWith (item)) {Sqlcheck.checkqueryparamrequest ( This. Request, This. Response); Check the URL for an illegal statement sqlcheck.checkformparamrequest ( This. Request, This. Response); Check for illegal statements in a form Break; } }}
If the input is not validated, the program throws an exception and jumps to the exception handling page
The same approach can be used for processing cross-site scripting attacks on XSS, although the format of the checksum may be different, one is to prevent the execution of malicious SQL statements, and the other is to prevent the execution of malicious scripts. In addition, where the user input is displayed on the key page, it is best to escape the content to ensure that the malicious embedded HTML and SCRITP cannot be executed.
Record a Web site bug fix process (iii): Second round processing (blocking SQL injection, cross-site scripting attack XSS)