[geeklog-devel] Filtering in GL2

Tony Bibbs tony at tonybibbs.com
Wed Dec 15 17:17:22 EST 2004

My response is below.

Dirk Haun wrote:

>What about SQL injection attempts then?
>There's several sorts of filtering that have to be done, and ideally (I
>think), they should be handled by different "entities" (for lack of a
>better word), as opposed to the all-in-one approach that 1.3's
>COM_applyFilter  implements.
>I.e. an SQL request should be parsed for injections / malformed SQL by
>the entity that handles SQL (would that be Propel then or Creole?).
>JavaScript, unwanted HTML, etc. should be handled by the module that
>handles the post (or whatever data is being processed), as it may be
>acceptable for one module, but unacceptable for another.

That's understandable.  However, it is worth noting a few things:

1) As a GL2 standard, any custom sql (i.e. that not automatically 
created by propel) must be in a prepared statement format.  This 
standard automatically makes GL2 less vulnerable (read the section "Why 
use prepared statements" on this page:


Now, I realize this is MySQL specific and I hope to maintain DB 
independence but nearly all 'real' DBMS support some form of prepared 

2) Saving using the save() method on the Propel generated domain objects 
all get converted to prepared statements.  So, not to be naive, SQL 
injection may still be possible but it should be considerably harder for 
a programmer in GL2 to allow for such a thing to happen.

That only takes care of, to a large degree, SQL injections.  All your 
other points are valid and I think that having a single class with a 
bunch of atomic filter methods for various things (i.e. javascript, 
html, etc) makes sense at the kernel level...not necessarily at the 
plugin level.  I only say that because if we have at least a base 
filtering class in the kernel, each plugin can override it as needed (in 
fact, I think this makes sense as a 1.3.x enhancement).

And if I heard right, Blaine will be doing a draft of this class, no? 


More information about the geeklog-devel mailing list