I have created a filter, and I have created a class that extends HttpServletRequestWrapper.
I want to create a filter that helps to eliminate SQL Injection attacks, so I want to remove any "odd" characters from the request values, like quotes, punctuation marks, math operators, etc.
In my class that extends HttpServletRequestWrapper, I have overrided (overrid?) getParameter() like so:
(For those not regular expression savy, that means remove any character not listed)
My question is, will this be enough? Or do I need to override all of the get parameter methods?
[ October 11, 2008: Message edited by: Bear Bibeault ]
It would be significantly better to use PreparedStatements to make SQL injection impossible for several reasons:
1) What if someone comes up with a clever way of doing injection? Maybe using escape codes or numeric values or the like.
2) What if you get a requirement to allow special characters? For example, some people have a single quote (apostrophe) in their names.
I do like that you are using a whitelist of allowed characters rather than trying to dream up what is invalid.
If you decide to go with this approach, note that you also need to override getParameterValues().
Mike Taylor wrote:I wouldn't carte-blanc use PreparedStatements because they are more secure. Performance has alot of merit too. PreparedStatements do not perform as well as Statements for a lot of use case conditions. We had used PreparedStatements religiously and found it to be a huge performance buster in our Web Applications. PreparedStatements does some validations and generates an almost like stored-proc to support the parameters. Which takes time. Then it passes the parameters to execute the query. When a simple Statement is in and out of there quickly. So I'd still would use a Filter to scrub input values coming in to prevent any sql injection for any string built queries for Statements. I refer to http://oreilly.com/catalog/jorajdbc/chapter/ch19.html for actual performance comparisons. So keep looking for that Injection Filter. I think its a good idea in most cases for web-applications. If I were doing something like batch for larger iterative inserts or something, then I'd be looking at PreparedStatements.
Um? Java code compilation also "takes time". What of it? You pay once and reap the benefits multiple times. If your SQL compiler is really that much slower than the kind of horror show that comes from pasting strings together - and hopefully escaping all the quotes &co., you seriously need to consider finding a new DBMS. Better Security is one reason for using prepared statements, but another is performance, precisely because if you compile the statement once and use it over and over again, you'll save overhead.
In Oracle 10g, they added a server-side optimization feature that would allow the examination of SQL that was impacting the server and permit the DBA to alter the offending statements for better performance without affecting the client apps. That's a feature that works a whole lot better when you're working with standardized (compiled) code instead of one-off SQL statements.
Also, just for the record, DIY JDBC is a lot like assembly language. While in theory it's the fastest way to go, in practice it doesn't scale well (in addition to maintenance costs). Benchmarks run on several of the most popular ORM systems versus raw JDBC have shown that raw JDBC can be slower by a factor of 2 or more. A lot of this is because the ORM frameworks were designed to synergize with the DBMS's, and part of that synergy comes from use of compiled SQL.