我正在为拥有庞大的遗留代码库的客户服务，该遗留代码库由各种基于Java en JSP的应用程序组成。

大多数查询是使用家庭构建的" orm"系统完成的。一些应用程序使用Plain Old JDBC。一些应用程序基于Hibernate(是的，带有加号的HQL构建也是一个潜在的问题)。一些较旧的应用程序完全用JSP编写。

我发现了一些手动SQL注入错误。但是我真的可以使用某种工具来搜索潜在的薄弱环节。

有任何想法吗？

解决方案

当我在本地化"这将永远不需要本地化"应用程序时，我们使用自制工具来分析编译后的代码(.NET中的IL，与Java中的字节码相同)。

我们可以找到调用与DB一起使用的指定方法(通常为CRUD操作)，而该方法具有SQL命令的字符串参数，并跟踪字符串实例并检查是否为简明。

我们使用.NET Reflector来反编译和跟踪字符串。但我不知道，是否有适用于Java的类似工具:(。

我会进行一些搜索或者加载一个IDE，以查找使用java.sql.Statement而不是PreparedStatement的情况。

我们可以寻求预防而非治愈。在用户界面下方添加一个净化层，这样我们最终就不会在用户输入中出现sql / scripts了。 Java中一定有示例，我在CakePHP中已经看到了这种方法

查找任何不使用PreparedStatement的地方。

我建议使用FindBugs(还有一个eclipse插件)，它可以跟踪这些问题以及更多其他问题。

我们在工作中使用它，它速度很快，而且物有所值(如免费)。我们已通过其帮助解决了一些常见问题。

URL空间有多大？如果可能的话，最好尝试通过HTTP GET和POST请求进行SQL注入。通过源代码/字节码检查可以发现一些问题，但是要确定应用程序将接受哪种类型的潜在恶意输入，唯一的方法是使用HTTP请求。

如果URL数量很少，则CAL9000是一个很好的SQL注入/跨站点脚本测试工具。

认真检测错误处理的恶意输入的公司将雇用第三者进行渗透测试。 White Hat Security是我过去与之合作过的供应商，可以推荐。我们将它们用于价值100毫米以上的电子商务网站。 (我与White Hat没有从属关系，如果我们成为他们的客户，也不会以任何方式受益。)

除了对代码进行所有测试/强化之外，最好有一个像mod_security这样的HTTP防火墙。