有史以来最牛的服务器反黑全集(2)

令人遗憾的是，如果是整型数据出了语义上的问题，没有什么东西可以替语义背黑锅了，所以没有了一个一定程度上通用的解决方案。不过也不要悲观，前面就已经说过，能避开就避开，釜底抽薪不要让可能有语义问题的变量作为输入好了。 
仅仅考虑数据库安全的话，所有有威胁的语义问题都几乎出在对数据库的操作上，那么，我们只要注意update/insert等语句就可以了，如果考虑数据内容的安全性的话，select也得算上。一般来说，特别关注的是生成的where后面的条件语句，总觉得条件的语义应该是由服务器端决定的，而不是说用户的输入是什么就是什么。我的建议是对于所有的可能出现语义问题的整型变量，最好都是Session，当然，没有进行非常深入的研究，或许有人能够提出像对付字符串的语义问题一样的有效方法也说不一定。不过话又说回来，在语义层面上看对字符串的过滤，不能证明它不安全，但是更重要的没有人能够证明它安全，只是大家现在用着没有问题，也就默认了罢了。 
若要深入的分析语义，也会突然冒出一大堆奇怪的东西，所以还是就此打住吧，真切的希望同行之间能够多一些这方面的交流！ 
前面说的也许更多地会用在一些对既有代码的补救上，如果是从头开始构架一个软件的话，上面的仅仅是设计上一些参考。所有的漏洞都是源于设计上的缺陷，一个好的软件应该被证明其模型是正确的，这很难但是可以做到。如果你一开始就证明了软件的正确性，我想也不会有漏子可以给别人钻了。 
方案六 
防范SQL指令植入式攻击 
发帖子的目的是为了大家讨论与研究。。。 
什么是SQL 指令植入式攻击？ 
在设计或者维护 Web 网站时，你也许担心它们会受到某些卑鄙用户的恶意攻击。的确，如今的 Web 网站开发者们针对其站点所在操作系统平台或Web 服务器的安全性而展开的讨论实在太多了。不错，IIS 服务器的安全漏洞可能招致恶意攻击；但你的安全检查清单不应该仅仅有 IIS 安全性这一条。有些代码，它们通常是专门为数据驱动(data-driven) 的 Web 网站而设计的，实际上往往同其它 IIS 漏洞一样存在严重的安全隐患。这些潜伏于代码中的安全隐患就有可能被称为“SQL 指令植入式攻击” (SQL injection) 的手段所利用而导致服务器受到攻击。 
SQL 指令植入式攻击技术使得攻击者能够利用 Web 应用程序中某些疏于防范的输入机会动态生成特殊的 SQL 指令语句。举一个常见的例子： 
某 Web 网站采用表单来收集访问者的用户名和密码以确认他有足够权限访问某些保密信息，然后该表单被发送到 Web 服务器进行处理。接下来，服务器端的ASP 脚本根据表单提供的信息生成 SQL 指令语句提交到 SQL 服务器，并通过分析 SQL 服务器的返回结果来判断该用户名/密码组合是否有效。 
为了实现这样的功能，Web 程序员可能会设计两个页面：一个 HTML 页面 (Login.htm) 用于登录，另一个ASP 页面 (ExecLogin.asp) 用于验证用户权限(即向数据库查询用户名/密码组合是否存在)。

乍一看，ExecLogin.asp 的代码似乎没有任何安全漏洞，因为用户如果不给出有效的用户名/密码组合就无法登录。然而，这段代码偏偏不安全，而且它正是SQL 指令植入式攻击的理想目标。具体而言，设计者把用户的输入直接用于构建SQL 指令，从而使攻击者能够自行决定即将被执行的 SQL 指令。例如：攻击者可能会在表单的用户名或密码栏中输入包含“ or ”和“=” 等特殊字符。于是，提交给数据库的 SQL 指令就可能是： 
代码:Select * FROM tblUsers Where Username= or = and Password = or = 

这样，SQL 服务器将返回 tblUsers 表格中的所有记录，而 ASP 脚本将会因此而误认为攻击者的输入符合 tblUsers 表格中的第一条记录，从而允许攻击者以该用户的名义登入网站。 
SQL 指令植入式攻击还有另一种形式，它发生在 ASP 服务器根据 querystring 参数动态生成网页时。这里有一个例子，此 ASP 页面从 URL 中提取出 querystring 参数中的 ID 值，然后根据 ID 值动态生成后继页面： 
代码: 

在一般情况下，此 ASP 脚本能够显示具有特定 ID 值的文章的内容，而 ID 值是由 URL 中的 querystring 参数指定的。例如：当URL为 http://www.example.com/Article.asp?ID=1055 时，ASP 就会根据 ID 为 1055 的文章提供的内容生成页面。 
如同前述登录页面的例子一样，此段代码也向SQL 指令植入式攻击敞开了大门。某些恶意用户可能会把 querystring 中的文章 ID 值偷换为“0 or 1=1”等内容(也就是说，把 URL 换成 http://www.example.com/Article.asp?ID=0 or 1=1) 从而诱使 ASP 脚本生成不安全的 SQL 指令如： 
代码:Select * FROM tblArticles Where ID=0 or 1=1 
于是，数据库将会返回所有文章的内容。 
当然了，本例服务器所受的攻击不一定会引起什么严重后果。可是，攻击者却可能变本加厉，比如用同样的手段发送 Delete 等 SQL 指令。这只需要简单地修改前述 URL 中的 querystring 参数就可以了！例如：任何人都可以通过 “http://www.example.com/Article.asp?ID=1055; Delete FROM tblArticles ” 之类的 URL 来访问 Web 网站。 SQL 指令植入式攻击的危害 
SQL 指令植入式攻击可能引起的危害取决于该网站的软件环境和配置。当 Web 服务器以操作员(dbo)的身份访问数据库时，利用SQL 指令植入式攻击就可能删除所有表格、创建新表格，等等。当服务器以超级用户 (sa) 的身份访问数据库时，利用SQL 指令植入式攻击就可能控制整个 SQL 服务器；在某些配置下攻击者甚至可以自行创建用户帐号以完全操纵数据库所在的 Windows 服务器。 
杜绝SQL 指令植入式攻击 
杜绝SQL 指令植入式攻击的第一步就是采用各种安全手段监控来自 ASP request 对象 (Request 、 Request.QueryString 、 Request.Form 、 Request.Cookies 和 Request.ServerVariables) 的用户输入，以确保 SQL 指令的可*性。具体的安全手段根据你的 DBMS 而异，下面给出的都是基于 MS SQL Server的例子。 
在前述登录页面的例子中，脚本期望得到的两个输入变量 (txtUserName 和 txtPassword)均为字符串类型。无论用户在哪个参数中插入单引号，他都可能让数据库执行单引号中的 SQL 指令。为了杜绝此类SQL 指令植入式攻击，我们可以借助 Replace 函数剔除单引号，比如： 
代码:p_strUsername = Replace(Request.Form("txtUsername"), "", "") p_strPassword = Replace(Request.Form("txtPassword"), "", "") 
在第二个例子中，脚本期望的输入变量是长整型变量 (ID) 。用户可以通过在 ID 参数中插入特殊字符来运行不安全的 SQL 指令。为了为了杜绝此类SQL 指令植入式攻击，我们只需要借助 CLng 函数限制 ID 值为长整型变量，比如： 
代码:p_lngID = CLng(Request("ID")) 

当用户试图在 ID 中包含特殊字符时，CLng 就会产生一个错误。 
为了进一步减少SQL 指令植入式攻击的危胁，请务必清除客户端错误信息文本中的所有技术资料。某些错误信息往往泄露了技术细节，从而让攻击者可以看出服务器的安全漏洞所在。这里指的错误信息不但包括应用程序生成的消息框，还包括来自 IIS 的出错提示。为此，你可以禁止由 IIS 发送的详细错误信息，而改用自定义的出错页面。(关于创建自定义的出错页面的更多信息，请务必参阅 《Creating Custom ASP Error Pages》。) 
最后，为了减轻SQL 指令植入式攻击的危害，请限制 Web 应用程序所用的数据库访问帐号权限。一般来说，应用程序没有必要以 dbo 或者 sa 的身份访问数据库。记住，给它的权限越少，你的网站越安全！你还可以考虑分别给每个需要访问数据库的对象分配只拥有必需权限的帐号，以分散安全漏洞。例如：同是前端用户界面，当用于公共场所时就比用于具有本地内容管理机制的平台时更加需要严格限制数据库访问权限。 
相关资料 
在 Internet 上有许许多多关于本话题的有用资源。我想下列连接可能会对你有所帮助： 
* SQL Injection FAQ (http://www.sqlsecurity.com/) 
* Advanced SQL Injection White Paper (http://www.nextgenss.com/research.html) 
* Preventing SQL Injection (http://www.owasp.org/asac/input_validation/sql.shtml)