Elliotte Harold wrote:
Kenneth Downs wrote:
In SQL Injection, the user accesses some table they are not supposed
to access. This can only be done if the application connects to the
database as some generic user, where that generic user can do
anything it wants.
Not always. Sometimes it's about accessing a row they're not supposed
to access,
You are correct that row level and column level security are required to
completely finish the picture (not something I was going to bring up in
a first post). I wasn't going to go that deep in a first exposition.
In fact, the complete resolution down to cell-level security is in
theory the final story.
Andromeda supports row-level and column-level security precisely for
this reason. I have one customer in particular for whom that is the
most used feature.
But it remains true that the entire security model of a table-based
system is security privileges on the tables (including rows and
columns). Everything else /resolves to this in the end/. For this
reason we also don't use or need any stored procedures, as they
complicate the security picture without adding benefit. By implementing
security directly on tables and making use of triggers we have the
tightest possible encapsulation of data and code.
Finally, you ain't never going to do better in code, because the
possibilities for latent errors are too high. By contrast, direct
assignments to tables, being the /final action required anyway/, are the
easiest to work out and assign, and the easiest to document and verify.
Code-based solutions don't come close to providing the security you need.
--
Kenneth Downs
Secure Data Software, Inc.
www.secdat.com www.andromeda-project.org
631-689-7200 Fax: 631-689-0527
cell: 631-379-0010
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
