⑴ 某个ASP.NET Web应用有一个登录页面，这个登录页面控制着用户是否有权访问应用，它要求用户输入一个名称和密码。

　　 ⑵ 登录页面中输入的内容将直接用来构造动态的SQL命令，或者直接用作存储过程的参数。下面是ASP.NET应用构造查询的一个例子：

　　 System.Text.StringBuilder query = new System.Text.StringBuilder(
　　 "SELECT * from Users WHERE login = '")
　　 .Append(txtLogin.Text).Append("' AND password='")
　　 .Append(txtPassword.Text).Append("'");

　　 ⑶ 攻击者在用户名字和密码输入框中输入"'或'1'='1"之类的内容。

　　 ⑷ 用户输入的内容提交给服务器之后，服务器运行上面的ASP.NET代码构造出查询用户的SQL命令，但由于攻击者输入的内容非常特殊，所以最后得到的SQL命令变成：SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'。

　　 ⑸ 服务器执行查询或存储过程，将用户输入的身份信息和服务器中保存的身份信息进行对比。

　　 ⑹ 由于SQL命令实际上已被注入式攻击修改，已经不能真正验证用户身份，所以系统会错误地授权给攻击者。

　　 如果攻击者知道应用会将表单中输入的内容直接用于验证身份的查询，他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能，欺骗系统授予访问权限。

　　 系统环境不同，攻击者可能造成的损害也不同，这主要由应用访问数据库的安全权限决定。如果用户的帐户具有管理员或其他比较高级的权限，攻击者就可能对数据库的表执行各种他想要做的操作，包括添加、删除或更新数据，甚至可能直接删除表。二、如何防范？

　　 好在要防止ASP.NET应用被SQL注入式攻击闯入并不是一件特别困难的事情，只要在利用表单输入的内容构造SQL命令之前，把所有输入内容过滤一番就可以了。过滤输入内容可以按多种方式进行。

　　 ⑴ 对于动态构造SQL查询的场合，可以使用下面的技术：

　　 第一：替换单引号，即把所有单独出现的单引号改成两个单引号，防止攻击者修改SQL命令的含义。再来看前面的例子，“SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'”显然会得到与“SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'”不同的结果。

　　 第二：删除用户输入内容中的所有连字符，防止攻击者构造出类如“SELECT * from Users WHERE login = 'mas' -- AND password =''”之类的查询，因为这类查询的后半部分已经被注释掉，不再有效，攻击者只要知道一个合法的用户登录名称，根本不需要知道用户的密码就可以顺利获得访问权限。

　　 第三：对于用来执行查询的数据库帐户，限制其权限。用不同的用户帐户执行查询、插入、更新、删除操作。由于隔离了不同帐户可执行的操作，因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。

　　 ⑵ 用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。

　　 ⑶ 限制表单或查询字符串输入的长度。如果用户的登录名字最多只有10个字符，那么不要认可表单中输入的10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。

　　 ⑷ 检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行??之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。

　　 在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器。因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象，例如RegularExpressionValidator，它们能够自动生成验证用的客户端脚本，当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象，你可以通过CustomValidator自己创建一个。

　　 ⑸ 将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。System.Web.Security.FormsAuthentication类有一个HashPasswordForStoringInConfigFile，非常适合于对输入数据进行消毒处理。

　　 ⑹ 检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理。

   HttpRuntime.UnloadAppDomain();

１　在页面级错误事件中，在单独页面中的错误。可以在page_error事件中添加处理逻辑，具体如下：

Private   Sub Page_Error() Sub  Page_Error( ByVal  sender  As   Object ,  ByVal  e  As  System.EventArgs)  Handles   MyBase .Error

         Dim  err  As   String   =   " Error in: "   &  Request.Url.ToString  &   " </p> "  _
                         &   " Stack Trace Below:</br> "  _
                         &  Server.GetLastError.ToString
        Response.Write(err)
        Server.ClearError()
     End Sub

2      在应用程序级的错误事件中，在应用程序中的错误。可以在global.asax文件中的application_error中添加处理  逻辑，具体如下：

  Sub Application_Error() Sub  Application_Error( ByVal  sender  As   Object ,  ByVal  e  As  EventArgs)
  '  在发生错误时激发
         Dim  err  As   String   =   " <h1>Application Error</h1> "  _
                             &   " Error in: "  _
                             &  Request.Url.ToString  &   " </p> "  _
                             &   " Stack Trace Below:</br> "  _
                             &  Server.GetLastError.ToString
        Response.Write(err)
        Server.ClearError()
     End Sub

3     在应用程序配置文件中，为应用程序执行的声明性错误处理，具体如下：

＜system.web>
< customErrors  defaultRedirect ="url"  mode ="RemoteOnly" >
         < error  statusCode ="code"  redirect ="url" ></ error >
         </ customErrors >
＜/system.web>

当页面发生错误时，应用程序也应该让管理员或开发人员知道何时何地出现了错误，一般有两种方法。

1    向Event Log 写入事件

Imports  System.Diagnostics
Sub Application_Error() Sub  Application_Error( ByVal  sender  As   Object ,  ByVal  e  As  EventArgs)
         '  在发生错误时激发
  
         Dim  PageUrl  As   String   =  Request.Path
         Dim  ErrorInfo  As  Exception  =  Server.GetLastError()

         Dim  Message  As   String   =   " Url: "   &  PageUrl  &   " </br> "
        Message  =  Message  &   "  Error:  "
        Message  =  Message  &  ErrorInfo.ToString  &   " </br> "

         Dim  LogName  As   String   =   " MyCustomLog "
         If  ( Not  EventLog.SourceExists(LogName))  Then
            EventLog.CreateEventSource(LogName, LogName)
         End   If

         Dim   Log   As   New  EventLog
         Log .Source  =  LogName
         Log .WriteEntry(Message, EventLogEntryType.Error)
     End Sub

2    发送Email

Sub Application_Error() Sub  Application_Error( ByVal  sender  As   Object ,  ByVal  e  As  EventArgs)
         '  在发生错误时激发
  
         Dim  PageUrl  As   String   =  Request.Path
         Dim  ErrorInfo  As  Exception  =  Server.GetLastError()

         Dim  Message  As   String   =   " Url: "   &  PageUrl  &   " </br> "
        Message  =  Message  &   "  Error:  "
        Message  =  Message  &  ErrorInfo.ToString  &   " </br> "

         Dim  Mymessage  As   New  MailMessage
        Mymessage.To  =   " tianhao960@gmail.com "
        Mymessage.From  =   " tianhao960@gmail.com "
        Mymessage.Subject  =   " ASP.NET Error "
        Mymessage.BodyFormat  =  MailFormat.Text

        Mymessage.Body  =  Message
        SmtpMail.Send(Mymessage)

     End Sub

// Add the style to the header for the body of the page
this.Header.StyleSheet.CreateStyleRule(style, null, "body");
动态加样式表： HtmlLink link = new HtmlLink();
link.Attributes.Add("type", "text/css");
link.Attributes.Add("rel", "stylesheet");
link.Attributes.Add("href", "~/newstyle.css");
this.Header.Controls.Add(link);
动态加meta tags ： // Render: <meta name="keywords" content="Some words listed here" />
HtmlMeta meta = new HtmlMeta();
meta.Name = "keywords";
meta.Content = "Some words listed here";
this.Header.Controls.Add(meta);

// Render: <meta name="robots" content="noindex" />
meta = new HtmlMeta();
meta.Name = "robots";
meta.Content = "noindex";
this.Header.Controls.Add(meta);

// Render: <meta name="date" content="2006-03-25" scheme="YYYY-MM-DD" />
meta = new HtmlMeta();
meta.Name = "date";
meta.Content = DateTime.Now.ToString("yyyy-MM-dd");
meta.Scheme = "YYYY-MM-DD";
this.Header.Controls.Add(meta);

　　尽早缓存；经常缓存　　

　　您应该在应用程序的每一层都实现缓存。向数据层、业务逻辑层、UI 或输出层添加缓存支持。内存现在非常便宜 — 因此，通过以智能的方式在整个应用程序中实现缓存，可以获得很大的性能提高。

　　缓存可以掩盖许多过失　　

　　缓存是一种无需大量时间和分析就可以获得“足够良好的”性能的方法。这里再次强调，内存现在非常便宜，因此，如果您能通过将输出缓存 30 秒，而不是花上一整天甚至一周的时间尝试优化代码或数据库就可以获得所需的性能，您肯定会选择缓存解决方案（假设可以接受 30 秒的旧数据）。缓存正是那些利用 20% 付出获得 80% 回报的特性之一，因此，要提高性能，应该首先想到缓存。不过，如果设计很糟糕，最终却有可能带来不良的后果，因此，您当然也应该尽量正确地设计应用程序。但如果您只是需要立即获得足够高的性能，缓存就是您的最佳选择，您可以在以后有时间的时候再尽快重新设计应用程序。　　

　　页面级输出缓存

　　作为最简单的缓存形式，输出缓存只是在内存中保留为响应请求而发送的 HTML 的副本。其后再有请求时将提供缓存的输出，直到缓存到期，这样，性能有可能得到很大的提高（取决于需要多少开销来创建原始页面输出 - 发送缓存的输出总是很快，并且比较稳定）。　　

　　实现　　

　　要实现页面输出缓存，只要将一条 OutputCache 指令添加到页面即可。　　

　　＜%@ OutputCache Duration="60" VaryByParam="*" %＞　　

　　如同其他页面指令一样，该指令应该出现在 ASPX 页面的顶部，即在任何输出之前。它支持五个属性（或参数），其中两个是必需的。　

　　Duration

　　必需属性。页面应该被缓存的时间，以秒为单位。必须是正整数。　

　　Location

　　指定应该对输出进行缓存的位置。如果要指定该参数，则必须是下列选项之一：Any、Client、Downstream、None、Server 或 ServerAndClient。　

　　VaryByParam

　　 必需属性。Request 中变量的名称，这些变量名应该产生单独的缓存条目。"none" 表示没有变动。"*" 可用于为每个不同的变量数组创建新的缓存条目。变量之间用 ";" 进行分隔。　　

　　VaryByHeader

　　 基于指定的标头中的变动改变缓存条目。　　

　　VaryByCustom

　　 允许在 global.asax 中指定自定义变动（例如，"Browser"）。　　

　　利用必需的 Duration 和 VaryByParam 选项的组合可以处理大多数情况。例如，如果您的产品目录允许用户基于 categoryID 和页变量查看目录页，您可以用参数值为 "categoryID;page" 的 VaryByParam 将产品目录缓存一段时间（如果产品不是随时都在改变，一小时还是可以接受的，因此，持续时间是 3600 秒）。这将为每个种类的每个目录页创建单独的缓存条目。每个条目从其第一个请求算起将维持一个小时。　

　　VaryByHeader 和 VaryByCustom 主要用于根据访问页面的客户端对页面的外观或内容进行自定义。同一个 URL 可能需要同时为浏览器和移动电话客户端呈现输出，因此，需要针对不同的客户端缓存不同的内容版本。或者，页面有可能已经针对 IE 进行了优化，但需要能针对 Netscape 或 Opera 完全降低优化（而不仅仅是破坏页面）。后一个例子非常普遍，我们将提供一个说明如何实现此目标的示例：　

　　示例：VaryByCustom 用于支持浏览器自定义　　

　　为了使每个浏览器都具有单独的缓存条目，VaryByCustom 的值可以设置为 "browser"。此功能已经内置在缓存模块中，并且将针对每个浏览器名称和主要版本插入单独的页面缓存版本。　

　　＜%@ OutputCache Duration="60" VaryByParam="None" VaryByCustom="browser" %＞　

　　片段缓存，用户控件输出缓存

　　缓存整个页面通常并不可行，因为页面的某些部分是针对用户定制的。不过，页面的其他部分是整个应用程序共有的。这些部分最适合使用片段缓存和用户控件进行缓存。菜单和其他布局元素，尤其是那些从数据源动态生成的元素，也应该用这种方法进行缓存。如果需要，可以将缓存的控件配置为基于对其控件（或其他属性）的更改或由页面级输出缓存支持的任何其他变动进行改变。使用同一组控件的几百个页面还可以共享那些控件的缓存条目，而不是为每个页面保留单独的缓存版本。　

　　实现　　

　　片段缓存使用的语法与页面级输出缓存一样，但其应用于用户控件（.ascx 文件）而不是 Web 窗体（.aspx 文件）。除了 Location 属性，对于 OutputCache 在 Web 窗体上支持的所有属性，用户控件也同样支持。用户控件还支持名为 VaryByControl 的 OutputCache 属性，该属性将根据用户控件（通常是页面上的控件，例如，DropDownList）的成员的值改变该控件的缓存。如果指定了 VaryByControl，可以省略 VaryByParam。最后，在默认情况下，对每个页面上的每个用户控件都单独进行缓存。不过，如果一个用户控件不随应用程序中的页面改变，并且在所有页面都使用相同的名称，则可以应用 Shared="true" 参数，该参数将使用户控件的缓存版本供所有引用该控件的页面使用。

　　示例　　

　　＜%@ OutputCache Duration="60" VaryByParam="*" %＞　　

　　该示例将缓存用户控件 60 秒，并且将针对查询字符串的每个变动、针对此控件所在的每个页面创建单独的缓存条目。　　

　　＜%@ OutputCache Duration="60" VaryByParam="none"

　　VaryByControl="CategoryDropDownList" %＞　　

　　该示例将缓存用户控件 60 秒，并且将针对 CategoryDropDownList 控件的每个不同的值、针对此控件所在的每个页面创建单独的缓存条目。　　

　　＜%@ OutputCache Duration="60" VaryByParam="none" VaryByCustom="browser"

　　Shared="true %＞　　

　　最后，该示例将缓存用户控件 60 秒，并且将针对每个浏览器名称和主要版本创建一个缓存条目。然后，每个浏览器的缓存条目将由引用此用户控件的所有页面共享（只要所有页面都用相同的 ID 引用该控件即可）。　　

　　页面级和用户控件级输出缓存的确是一种可以迅速而简便地提高站点性能的方法，但是在 ASP.NET 中，缓存的真正灵活性和强大功能是通过 Cache 对象提供的。使用 Cache 对象，您可以存储任何可序列化的数据对象，基于一个或多个依赖项的组合来控制缓存条目到期的方式。这些依赖项可以包括自从项被缓存后经过的时间、自从项上次被访问后经过的时间、对文件和/或文件夹的更改以及对其他缓存项的更改，在略作处理后还可以包括对数据库中特定表的更改。　

　　在 Cache 中存储数据　　

　　在 Cache 中存储数据的最简单的方法就是使用一个键为其赋值，就像 HashTable 或 Dictionary 对象一样：　　

　　Cache["key"] = "value";　　

　　这种做法将在缓存中存储项，同时不带任何依赖项，因此它不会到期，除非缓存引擎为了给其他缓存数据提供空间而将其删除。要包括特定的缓存依赖项，可使用 Add() 或 Insert() 方法。其中每个方法都有几个重载。Add() 和 Insert() 之间的唯一区别是，Add() 返回对已缓存对象的引用，而 Insert() 没有返回值（在 C# 中为空，在 VB 中为 Sub）。　　

　　示例　

　　Cache.Insert("key", myXMLFileData, new

　　System.Web.Caching.CacheDependency(Server.MapPath("users.xml")));　　

　　该示例可将文件中的 xml 数据插入缓存，无需在以后请求时从文件读取。 CacheDependency 的作用是确保缓存在文件更改后立即到期，以便可以从文件中提取最新数据，重新进行缓存。如果缓存的数据来自若干个文件，还可以指定一个文件名的数组。　　

　　Cache.Insert("dependentkey", myDependentData, new

　　System.Web.Caching.CacheDependency(new string[] {}, new string[]

　　{"key"}));　　

　　该示例可插入键值为 "key" 的第二个数据块（取决于是否存在第一个数据块）。如果缓存中不存在名为 "key" 的键，或者如果与该键相关联的项已到期或被更新，则 "dependentkey" 的缓存条目将到期。　　

　　Cache.Insert("key", myTimeSensitiveData, null,

　　DateTime.Now.AddMinutes(1), TimeSpan.Zero);　　

　　绝对到期：此示例将对受时间影响的数据缓存一分钟，一分钟过后，缓存将到期。注意，绝对到期和滑动到期（见下文）不能一起使用。　　

　　Cache.Insert("key", myFrequentlyAccessedData, null,

　　System.Web.Caching.Cache.NoAbsoluteExpiration,

　　TimeSpan.FromMinutes(1));　　

　　滑动到期：此示例将缓存一些频繁使用的数据。数据将在缓存中一直保留下去，除非数据未被引用的时间达到了一分钟。注意，滑动到期和绝对到期不能一起使用。　

　　更多选项　　

　　除了上面提到的依赖项，我们还可以指定项的优先级（依次为 low、high、NotRemovable，它们是在 System.Web.Caching.CacheItemPriority 枚举中定义的）以及当缓存中的项到期时调用的 CacheItemRemovedCallback 函数。大多数时候，默认的优先级已经足够了 — 缓存引擎可以正常完成任务并处理缓存的内存管理。CacheItemRemovedCallback 选项考虑到一些很有趣的可能性，但实际上它很少使用。不过，为了说明该方法，我将提供它的一个使用示例：　　

　　CacheItemRemovedCallback 示例
　
　　System.Web.Caching.CacheItemRemovedCallback callback = new System.Web.Caching.CacheItemRemovedCallback (OnRemove);

　　Cache.Insert("key",myFile,null,

　　System.Web.Caching.Cache.NoAbsoluteExpiration,

　　TimeSpan.Zero,

　　System.Web.Caching.CacheItemPriority.Default, callback);

　　. . .

　　public static void OnRemove(string key,

　　object cacheItem,

　　System.Web.Caching.CacheItemRemovedReason reason)

　　{

　　AppendLog("The cached value with key '" + key +

　　"' was removed from the cache. Reason: " +

　　reason.ToString());

　　}　　

　　该示例将使用 AppendLog() 方法（这里不讨论该方法，请参阅 Writing Entries to Event Logs）中定义的任何逻辑来记录缓存中的数据到期的原因。通过在从缓存中删除项时记录这些项并记录删除的原因，您可以确定是否在有效地使用缓存或者您是否可能需要增加服务器上的内存。注意，callback 是一个静态（在 VB 中为 Shared）方法，建议使用该方法的原因是，如果不使用它，保存回调函数的类的实例将保留在内存中，以支持回调（对 static/Shared 方法则没有必要）。

　　该特性有一个潜在的用处 — 在后台刷新缓存的数据，这样用户永远都不必等待数据被填充，但数据始终保持相对较新的状态。但实际上，此特性并不适用于当前版本的缓存 API，因为在从缓存中删除缓存的项之前，不触发或不完成回调。因此，用户将频繁地发出尝试访问缓存值的请求，然后发现缓存值为空，不得不等待缓存值的重新填充。我希望在未来的 ASP.NET 版本中看到一个附加的回调，可以称为 CachedItemExpiredButNotRemovedCallback，如果定义了该回调，则必须在删除缓存项之前完成执行。　　

　　缓存数据引用模式　　

　　每当我们尝试访问缓存中的数据时，都应该考虑到一种情况，那就是数据可能已经不在缓存中了。因此，下面的模式应该普遍适用于您对缓存的数据的访问。在这种情况下，我们假定已缓存的数据是一个数据表。　　

　　public DataTable GetCustomers(bool BypassCache)

　　{

　　string cacheKey = "CustomersDataTable";

　　object cacheItem = Cache[cacheKey] as DataTable;

　　if((BypassCache) 　　 (cacheItem == null))

　　{

　　cacheItem = GetCustomersFromDataSource();

　　Cache.Insert(cacheKey, cacheItem, null,

　　DateTime.Now.AddSeconds(GetCacheSecondsFromConfig(cacheKey),

　　TimeSpan.Zero);

　　}

　　return (DataTable)cacheItem;

　　}　　

　　关于此模式，有以下几点需要注意： 　　

　　? 某些值（例如，cacheKey、cacheItem 和缓存持续时间）是一次定义的，并且只定义一次。　

　　? 可以根据需要跳过缓存 — 例如，当注册一个新客户并重定向到客户列表后，最好的做法可能就是跳过缓存，用最新数据重新填充缓存，该数据包括新插入的客户。 　　

　　? 缓存只能访问一次。这种做法可以提高性能，并确保不会发生 NullReferenceExceptions，因为该项在第一次被检查时是存在的，但第二次检查之前就已经到期了。 　　

　　? 该模式使用强类型检查。C# 中的 "as" 运算符尝试将对象转换为类型，如果失败或该对象为空，则只返回 null（空）。 　　

　　? 持续时间存储在配置文件中。在理想的情况下，所有的缓存依赖项（无论是基于文件的，或是基于时间的，还是其他类型的依赖项）都应该存储在配置文件中，这样就可以进行更改并轻松地测量性能。我还建议您指定默认缓存持续时间，而且，如果没有为所使用的 cacheKey 指定持续时间，就让 GetCacheSecondsFromConfig() 方法使用该默认持续时间。 　　

　　相关的代码示例是一个 helper 类，它将处理上述所有情况，但允许通过一行或两行代码访问缓存的数据。请下载 CacheDemos.msi。　　

　　小结

　　缓存可以使应用程序的性能得到很大的提高，因此在设计应用程序以及对应用程序进行性能测试时应该予以考虑。应用程序总会或多或少地受益于缓存，当然有些应用程序比其他应用程序更适合使用缓存。对 ASP.NET 提供的缓存选项的深刻理解是任何 ASP.NET 开发人员应该掌握的重要技巧。

　　之后，在要更换CSS的页面中，使用如下代码