Simple Java tricks to protect your web application against SQL injection

Your application is vulnerable to SQL Injection when you send unfiltered strings to the database. Most modern ORM frameworks should take care of it (but don't take my word!... go ahead and check how secure your framework is).
Sometimes, you have to work with plain JDBC (or ODBC). Here is a couple of tricks that help:

1. First and foremost, avoid concatenating strings for SQL queries. Use prepared statements unless is not possible (i.e. cases when you have undefined number of parameters)
2. Leverage the language type system: If you're passing a number, use Integer instead of String... any invalid character will fail the conversion and will not reach the DB.
3. If there's no option but concatenate strings, make sure the database comment quotes are escaped (for example, in DB2 you have to replace the single quote character with 2 single quote characters: instead of "SELECT * FROM users WHERE name='"+param+"'" use "SELECT * FROM users WHERE name='"+param.replaceAll("'","''")+"'"

For something a little more advanced, you can wrap the strings in some kind of "EscapedString" class, and use that class in the signature of the DAOs (related to 2. )

Note: by no means this is a comprehensive list. Application security is very hard, check your database documentation...

What's your project score?

The Standish group's CHAOS report has a table of success factors:

Success Criteria	Points
1. User Involvement	19
2. Executive Management Support	16
3. Clear Statement of Requirements	15
4. Proper Planning	11
5. Realistic Expectations	10
6. Smaller Project Milestones	9
7. Competent Staff	8
8. Ownership	6
9. Clear Vision & Objectives	3
10. Hard-Working, Focused Staff	3
TOTAL	100

The study is not new, but still is valid. This are the critical factors for a project success.
Mapping it to your current project, will let you focus on the areas that will improve your chances...
What is your current project score?

RUP and risk management

I must admit that I like the Unified Process. The more non-trivial the project is, the more I think is applicable.
Typically, RUP is presented as a use-case driven, architecture first, iterative-incremental process divided in four phases: inception, elaboration, construction, and transition.
Somehow, using a manufacturing metaphor (I know, I know... usually are the worst ones, and can't go too far), the project can be divided into 2 major stages: "engineering" (inception and elaboration) and "production" (construction and transition).
The good thing is "engineering" aims to reduce significantly the risk level of the project. The biggest uncertainties at the beginning of a project are usually related to requirements (and scope) or technical ones, and they have a big impact because they’re the major sources of cost and time overruns. The traditional approach like the “waterfall” process is to pinpoint all the requirements and then complete the design to the detail (what the “agilists” call “Big Requirements Up Front” and “Big Design Up Front”). I will not beat the “Waterfall” straw man, it has its niche (albeit a lot smaller than most people think). Other option is ignore them and hope that the team is “agile” enough to respond to the risks when they materialize.
In the case of RUP, there’s an explicit intention to “defuse” those risks, by exposing and validating the assumptions as soon as possible:

• the inception phase main goal is to discover what it should be done (usually identifying most of the use cases, and detailing the most critical ones)
• the elaboration phase main goal is to define how it should be done, by defining the architecture of the system (based on the critical use cases)

After those phases are completed, you will have the architecture of the system, feedback from the most critical use cases, a clear view of the scope, and no technical surprises awaiting. At this point you should be able to have an accurate estimation of the total project effort, and the total risk exposure of the project should be significantly lower...