不可否认，SQL注入是现在网站攻击的主要手段，而在我以往做网站中都是利用字符串过滤和错误隐藏来避免这种攻击。这种方法只是从程序可以有效避免一些侵略，但实际如果在你没能力改变代码的情况下该如何防止这样的问题呢？下面我找到的两中办法，都是利用IIS来进行设置的。

UrlScan 3.1
UrlScan 3.1是一个安全方面的工具，微软官方的东西。它会检查所有IIS处理的HTTP请求。UrlScan 可以在有安全问题的HTTP请求到达应用程序之前就阻止这个请求。UrlScan 3.1 是UrlScan 2.5的一个升级版本，支持Windows Vista 和Windows Server 2008系统之上的IIS 5.1, IIS 6.0 和 IIS 7.0。

链接地址：http://www.iis.net/expand/UrlScan 这里还有很多非常有用的IIS扩展，可以看看。

IIS 6 SQL Injection Sanitation ISAPI Wildcard

这个ISAPI dll 也是通过检查HTTP请求避免SQL注入。只兼容windows 2003上的 IIS 6.0。对于Windows XP 上的 IIS 5 不支持。

这是一个开源项目：http://www.codeplex.com/IIS6SQLInjection

批改或隐藏IIS7.5的Server头信息

修改或隐藏IIS7.5的Server头信息

环境是 Windows 2008 Server R2 + IIS7.5

必须保证IIS角色下安装上ISAPI筛选器和IIS6元数据库兼容性。

首先下载 UrlScan 。然后直接安装。安装以后进入IIS管理，功能视图里ISAPI筛选器里应有UrlScan这一行。

全局配置文件

C:\Windows\System32\inetsrv\urlscan\UrlScan.ini

RemoveServerHeader=0          ; 改成1以后不显示Server
AlternateServerName=             ;如果RemoveServerHeader=0可以自己定义

在IIS 6 和 IIS 7 中 移除X-Powered-By xxx 的 HTTP头 的方法如下：

X-Powered-By HTTP头并不只是在Asp.net中存在，其他服务端语言，比如php, 也会包含这个HTTP头,当Asp.net被安装时，这个头会作为一个定制的 HTTP头插入IIS中,因此,我们需要将这个HTTP头从IIS的配置中删除,如果你的网站是在共享的环境下并且没有使用IIS7并使用管道模式，你不 得不为此联系你的空间提供商来帮你移除。(如果你的网站是在IIS7环境下，那你可以通过HTTP Module的形式通过编程来移除)

在IIS6中移除X-Powered-By HTTP头：

启动IIS，展开Website目录

在Website上点击右键并在弹出的菜单中选择“属性”

选择HTTP Header标签，所有IIS响应中包含的自定义的HTTP头都会在这里显示，只需要选择响应的HTTP头并点击删除就可以删除响应的HTTP头，如图：

而在IIS7中移除X-Powered-By HTTP头的方法是:

选择你需要修改的站点并双击HTTP响应头部分

所有的自定义HTTP头全在这里了，删除相应的头仅需要点击右边的”Remove”链接：

Cloaking your ASP.NET MVC Web Application on IIS 7

If you are building and deploying public facing web applications, security has to be one of your key consideration; ensure that you create a security threat model of your application to highlight the flow of data in your application and the possible weak points (Microsoft have a useful tool called Microsoft Security Assessment Tool which can help you with the planning process); ensure that your production environment has been hardened (and that you have run the various tool provided to spot any vulnerabilities in your infrastructure, such as Microsoft Baseline Security Analyzer and tools like CAT.NET and Paros for spotting vulnerabilities in your application code); ensure that your web application protects against Cross Site Scripting (XSS) and Cross-Site Request Forgery (CSRF/XSRF) attacks.

If you can afford the cost, adding an Intrusion Prevention System device to your network adds benefit, but if you can’t afford such a device then a tool such as UrlScan can offer some protection by blocking potentially harmful HTTP Requests. In order to use URLScan effectively you need to put an operational feedback loop in place whereby you use a tool such as LogParser (if you want a nice UI for this command line app, give Visual LogParser a try) to examine your application’s IIS Logs for suspicious activity and add rules to UrlScan and your firewall to block such requests.

Examining IIS Server logs from a high traffic public website or having a network monitoring solution such as Cacti is fascinating and terrifying in equal measures; once you have removed the noise of normal human generated traffic, the sheer volume of remaining non-human traffic generated by bots and spiders is staggering. Once you’ve filtered out all the requests generated by search engine’s crawlers there are a surprising number of other requests being made against your servers the two worst being harvesters (screen scrapers) and bots that perform vulnerability scanning and exploitation. These bots start by fingerprinting your server and then exploit any known vulnerabilities, the HTTP RFC 2068 highlights this possibility:

"Note: Revealing the specific software version of the server may allow the server machine to become more vulnerable to attacks against software that is known to contain security holes. Server implementers are encouraged to make this field a configurable option."

There are two recourses to this situation, firstly you can broadcast a fake web topology, for example if your web platform is WISA (Windows, Internet Information Services, SQL Server, ASP.NET) you can configure your servers to return the response headers of a LAMP (Linux, Apache, MySQL, PHP) platform. Secondly you can cloak this information, so it isn’t broadcasted at all.

By default a WISA platform (running ASP.NET MVC) discloses its identity, by broadcasting the following response header (using Firebug):

You can turn off the X-AspNet-Version header by applying the following configuration section to your web.config:

<system.web>    <httpRuntime enableVersionHeader="false"/>  </system.web>

which results in the X-AspNet-Version being removed:

You can then remove the X-AspNetMvc-Version header by altering your Global.asax.cs as follows:

protected void Application_Start()  {      MvcHandler.DisableMvcResponseHeader = true;  }

which results in the X-AspNetMvc-Version being removed:

But there is no easy way to remove the Server response header via configuration. Luckily IIS7 has a managed pluggable module infrastructure which allows you to easily extend its functionality. Below is the source for a HttpModule for removing a specified list of HTTP Response Headers:

namespace Zen.Core.Web.CloakIIS {     #region Using Directives
using System;     using System.Collections.Generic;     using System.Web;
#endregion /// <summary>     /// Custom HTTP Module for Cloaking IIS7 Server Settings to allow anonymity     /// </summary>     public class CloakHttpHeaderModule : IHttpModule     {         /// <summary>         /// List of Headers to remove         /// </summary>         private List<string> headersToCloak;
/// <summary>         /// Initializes a new instance of the <see cref="CloakHttpHeaderModule"/> class.         /// </summary>         public CloakHttpHeaderModule()         {             this.headersToCloak = new List<string>                                       {                                               "Server",                                               "X-AspNet-Version",                                               "X-AspNetMvc-Version",                                               "X-Powered-By",                                       };         }
/// <summary>         /// Dispose the Custom HttpModule.         /// </summary>         public void Dispose()         {         }
/// <summary>         /// Handles the current request.         /// </summary>         /// <param name="context">         /// The HttpApplication context.         /// </param>         public void Init(HttpApplication context)         {             context.PreSendRequestHeaders += this.OnPreSendRequestHeaders;         }
/// <summary>         /// Remove all headers from the HTTP Response.         /// </summary>         /// <param name="sender">         /// The object raising the event         /// </param>         /// <param name="e">         /// The event data.         /// </param>         private void OnPreSendRequestHeaders(object sender, EventArgs e)         {             this.headersToCloak.ForEach(h => HttpContext.Current.Response.Headers.Remove(h));         }     } }

Ensure that you sign the assembly, then you can install it into the GAC of your web servers and simply make the following modification to your application’s web.config (or if you want it to be globally applied, to the machine.config):

<configuration>     <system.webServer>         <modules>             <add name="CloakHttpHeaderModule"                   type="Zen.Core.Web.CloakIIS.CloakHttpHeaderModule, Zen.Core.Web.CloakIIS,                         Version=1.0.0.0, Culture=neutral, PublicKeyToken=<YOUR TOKEN HERE>" />         </modules>     </system.webServer> </configuration>

Now when you execute a page, you should see the following HTTP Response (with X-AspNetMvc-Version, X-AspNetMvc-Version and Server response headers removed):

One further note – the bots also fingerprint via file extensions, if you are running ASP.NET MVC, extensionless URLs implemented via the ASP.NET MVC routing system, should help avoid this type of detection.