tags:

views:

281

answers:

6

I'm working for a customer with a huge legacy codebase consisting of various Java en JSP based applications.

Most querying is done using the home-build 'orm' system. Some applications use Plain Old JDBC. Some applications are based on Hibernate (yes HQL build with plus signs is a potential problem as well). Some of the older applications are entirely writen in JSP.

I've found a couple of SQL inject bugs manually. But I could really use some sort of tool to search for potential weak spots.

Any ideas?

A: 

When I was working on localization of "this-will-never-need-localization" application, we use a home-made tool to analyzing compiled code ( IL in .NET, it is same as byte-code in Java ).

You can find calling the specified methods which works with DB ( typicaly CRUD operations ) wicht has a string parameter with SQL command, and track the string instance up and check for concating.

We used the .NET Reflector for decompiling and tracking strings. But I don't know, if is available similar tool for Java :(.

TcKs
+3  A: 

I'd write some searches or load up an IDE that looked for use of java.sql.Statement as opposed to PreparedStatement.

MattMcKnight
A: 

You can go for prevention rather than cure. add a sanitization layer just below ur UI, so you wont end up with sql/scripts in user inputs. There must be examples in java, I have seen such an approach in CakePHP

Midhat
A: 

Find any place that doesn't use a PreparedStatement.

Hank Gay
What about usages of PreparedStatement where the parameterized statement is formulated via String concatenation?
shadit
@shad: That is exactly one of the cases I've found digging arround manually. thanks for pointing it out!
p3t0r
If you're not using parameters, you're not really getting any benefit from the PreparedStatement, that's true. But if you've got more SQL injections coming from that than from plain old Statements that *can't* be parameterized, a previous dev had a sick sense of humor.
Hank Gay
+3  A: 

I would recommend FindBugs (there is also an eclipse plugin) which can track down these issues and many more.

We are using it at work, it's fast and it's worth the money (as in free). We've solved some common problems with its help.

Alex
+2  A: 

How large is your URL space? If possible, it's best to attempt SQL injection via HTTP GET and POST requests. There are some issues that can be found by source/byte code examination, but the only way to know for certain what kinds of potentially malicious input your application will accept is to use HTTP requests.

CAL9000 is a good SQL Injection / Cross-site Scripting testing tool if your set of URLs is small.

Companies that are serious about detecting mishandled malicious input will hire a 3rd party to do penetration testing. White Hat Security is a vendor I have worked with in the past and can recommend. We used them for a $100MM+ e-commerce web site. (I have no affiliation with White Hat and do not benefit in any way if you become their customer.)

All testing/hardening of your code aside, it is a very good idea to have an HTTP firewall in place like mod_security.

shadit