[geeklog-devel] Filtering in GL2
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
>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?).
>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
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