更有就是过滤器的位置，这个掺杂了逻辑问题在内的复杂问题。
我曾很惊奇地发现乔客论坛对外散布的版本中一段让人觉得不可思议的问题代码，假如您比较感兴趣的话，翻翻gallery.asp就能看到一个特定的动作序列（action=flash_view），绕过了任何对id的检查。
其实说起来，这一类代码不太可能有太复杂的逻辑结构，对代码进行审查的时候，进行任何的分支覆盖是能够手工完成的，只要稍微想想就会发现对变量的检查是否能够有效地到达您的目的地——生成SQL语句的地方。
关于过滤器的位置，假如要深入下去，马上就会出来一些让人眼花缭乱的东西，中间的分析很麻烦而且很形式化，虽然确实有算法能够确保位置选取的正确性，但是我想这里还是给出一些结论性的东西吧。倘若您很有兴趣，我想您能够来信和我交流。
过滤的位置，取决于两个方面：您获得变量的来源，连同您需要确保到的生成SQL语句的位置。前面一个，不论是来自于直接还是间接输入，先想想可能的输入字符；对于后面一个，您要确保无论程式运行情况怎样，经过了过滤语句的流程一定会经过您需要确保到的生成SQL语句的位置（确保其是有效过滤语句的后向必经节点）。假如您不很清楚流程的判断，我的建议是if中仅仅判断，if嵌套间不要有多余的东西，过滤语句后紧接生成SQL语句。
再回到前面提到的潜在问题，我们终于能够在这里解决了：在取出数据后依然首先进行判断。因为根据前面说的，这一种间接输入依然有可能出现危险。
说到这里，插一句另类的过滤位置问题：不要把对输入的过滤放到客户端解决，那是能够绕过的！谁能确保您的VBScript/JavaScript能起作用，假如别人直接用NC或一个不支持脚本的浏览器呢？
上述两个大的方面，以软件测试的目光来认识，显然是没有穷尽任何的分支所导致。在使用对方提交的数据之前，先做一个对方任何可能进入字符的分析列表，然后就每一种输入分支情况进行类型的审核，这是每个代码编写者都应该做的事情。这是一件很简单的事情，因为只是类型上的审核还好，碰上语义的问题就麻烦了……
三、类型正确意味着放行？
涉及到语义的问题，要是可能的话，我选择最好还是避开。
譬如对于一个整型数字，您输入的确实是个整型，通过了过滤器，潜在的问题是您的输入内容上合法吗，或根本就不应该从您这里获得信息？很多年前就有人提出来，有些注册的模块存在问题：他里面的id是通过一个type=hidden掩盖后隐式提交的，但是我在第一步建立了用户，第二步仍就有可能通过提交内容不合法的id来修改他人的信息。这种异类的问题都是很难发现，而且几乎都只有靠经验而不是某一个具体的算法来处理。我们在联系一下前面的，连起来想想或许能够更加清楚，对于输入的字符串，感觉上没有过滤也不会有错，因为比较数字之类集合来说，字符串所能容纳的几乎是全部可能输入的集合。事实上，常见的是没有过滤造成单引号的错误匹配，进而导致了SQL Injection。严格说起来，这也是个语义上的问题，但是对于这样子的特别情况而言，能够通过处理输入中的单引号来确保语义的某种程度上的正确。所以我也一再强调，单引号本身是无罪的，但是是背了语义的黑锅而已。
令人遗憾的是，假如是整型数据出了语义上的问题，没有什么东西能够替语义背黑锅了，所以没有了一个一定程度上通用的解决方案。但是也不要悲观，前面就已说过，能避开就避开，釜底抽薪不要让可能有语义问题的变量作为输入好了。
仅仅考虑数据库安全的话，任何有威胁的语义问题都几乎出在对数据库的操作上，那么，我们只要注意update/insert等语句就能够了，假如考虑数据内容的安全性的话，select也得算上。一般来说，特别关注的是生成的where后面的条件语句，总觉得条件的语义应该是由服务器端决定的，而不是说用户的输入是什么就是什么。我的建议是对于任何的可能出现语义问题的整型变量，最好都是Session，当然，没有进行很深入的研究，或许有人能够提出像对付字符串的语义问题相同的有效方法也说不一定。但是话又说回来，在语义层面上看对字符串的过滤，不能证实他不安全，但是更重要的没有人能够证实他安全，只是大家现在用着没有问题，也就默认了罢了。
若要深入的分析语义，也会突然冒出一大堆奇怪的东西，所以还是就此打住吧，真切的希望同行之间能够多一些这方面的交流！
前面说的也许更多地会用在一些对既有代码的补救上，假如是从头开始构架一个软件的话，上面的仅仅是设计上一些参考。任何的漏洞都是源于设计上的缺陷，一个好的软件应该被证实其模型是正确的，这很难但是能够做到。假如您一开始就证实了软件的正确性，我想也不会有漏子能够给别人钻了。
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
