我们发现这个企业内部站点内容特别多，甚至包含了一个全用户列表，我们可以合理的推出许多内网都有同样的企业Windows网络帐号，它们可能在所有地方都使用同样的密码。我们很容易就能得到任意的内网密码，并且我们找到了企业防火墙上的一个开放的PPTP协议的VPN端口，这让登录测试变得更简单。
我们又挑了几个帐号测试都没有成功，我们无法知道是否是“密码错误”或者“企业内部帐号是否与Windows帐号名不同”。但是我们觉得自动化工具会让这项工作更容易。
其他方法在这次特定的渗透中，我们得到了足够的权限，我们不需要更多了，但是还有其他方法。我们来试试我们现在想到的但不够普遍的方法。
我们意识到不是所有的方法都与数据库无关，我们可以来试试。
调用xp_cmdshell微软的SQLServer支持存储过程xp_cmdshell有权限执行任意操作系统指令。如果这项功能允许web用户使用，那webserver被渗透是无法避免的。
迄今为止，我们做的都被限制在了web应用和数据库这个环境下，但是如果我们能执行任何操作系统指令，再厉害的服务器也禁不住渗透。xp_cmdshell通常只有极少数的管理员账户才能使用，但它也可能授权给了更低级的用户。
绘制数据库结构在这个登录后提供了丰富功能应用上，已经没必要做更深的挖掘了，但在其他限制更多的环境下可能还不够。
能够系统的绘制出数据库可见结构，包含表和它们的字段结构，可能没有直接帮助。但是这为网站渗透提供了一条林萌大道。
从网站的其他方面收集更多有关数据结构的信息（例如，“留言板”页？“帮助论坛”等？）。不过这对应用环境依赖强，而且还得靠你准确的猜测。
减轻危害我们认为web应用开发者通常没考虑到“有害输入”，但安全人员应该考虑到（包括坏家伙），因此这有3条方法可以使用。
输入过滤过滤输入是非常重要的事，以确保输入不包含危险代码，无论是SQL服务器或HTM本身。首先想到的是剥掉“恶意字符”，像引号、分号或转义符号，但这是一种不太好的方式。尽管找到一些危险字符很容易，但要把他们全找出来就难了。
web语言本身就充满了特殊字符和奇怪的标记（包括那些表达同样字符的替代字符），所以想要努力识别出所有的“恶意字符”不太可能成功。
换言之，与其“移除已知的恶意数据”，不如移除“良好数据之外的所有数据”：这种区别是很重要的。在我们的例子中，邮件地址仅能包含如下字符：
abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 @.-_+允许不正确的字符输入是没有任何好处的，应该早点拒绝它们 – 可能会有一些错误信息 – 不仅可以阻止SQL注入，也可以捕获一些输入错误而不是把它们存入数据库。
某个特殊的email地址会让验证程序陷入麻烦，因为每个人对于“有效”的定义不同。由于email地址中出现了一个你没有考虑到的字符而被拒绝，那真是糗大了。
真正的权威是RFC 2822（比RFC822内容还多），它对于”允许使用的内容“做了一个规范的定义。这种更学术的规范希望可以接受&和*（还有更多）作为有效的email地址，但其它人 – 包括作者 – 都乐于用一个合理的子集来包含更多的email地址。
那些采用更限制方法的人应当充分意识到没有包含这些地址会带来的后果，特别是限制有了更好的技术（预编译/执行，存储过程）来避免这些“奇怪”的字符带来的安全问题。
意识到“过滤输入”并不意味着仅仅是“移除引号”，因为即使一个“正规”的字符也会带来麻烦。在下面这个例子中，一个整型ID值被拿来和用户的输入作比较（数字型PIN）:
SELECT fieldlist FROM table WHERE id = 23 OR 1=1; -- Boom! Always matches!