Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Filter for SQL Injection attack protection  RSS feed

 
Wesley Baker
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've read the following post, and I think it deals with my question, but I got a bit confused about halfway through:

http://www.coderanch.com/t/364780/Servlets/java/Why-does-getParameterMap-return-immutable

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?
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66141
141
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why would you be doing this in a filter? It's main-line functionality and not really suited to a filter. And I'd even delegate it to lower levels than the UI. After all, database security is not a UI issue and should be independent of the UI.
[ October 11, 2008: Message edited by: Bear Bibeault ]
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 37180
515
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wesley,
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().
 
Wesley Baker
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I had forgotten about PreparedStatement, and only recently started reading about it. I think I will have to overhaul my database connection class and use PreparedStatement instead of Statement.

Jeanne, you make some good points I hadn't considered. Thank you both for your input.
 
Mike Taylor
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I wouldn't carte-blanc use PreparedStatements because they are more secure.

I would. A performance problem is much easier to fix than a secuirty hole.

(BTW, that article is eight years old and Oracle specific. I would be surprised if it were still relevant.)

 
Tim Holloway
Bartender
Posts: 18661
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!