[EMAIL PROTECTED] wrote:
Kenneth Downs wrote:
The focus is on "...does not let them do anything they can't do
anyway...."
If the hacker wants to test the SQL injection abilities, let them.
>Let them have fun. Let them learn. The real question is, can they
>do harm? And the answer is NO, not if they are connected to the
>database with an account that has limited security abilities.
Hmm, I would say tricking someone into wiping out all patient records
by having them click a custom crafted link which uses their authority
to wipe every record in the database(since they have delete authority)
would be harm.
....but of course we want to prevent session hijacking and forged urls
no matter what the security mechanism, right?
...and I assume your database has foreign keys and delete constraints
that would prevent orphaning all of those customers' orders, right?
...and finally, who is it that is connecting with the ability to wipe
every record in the database?
Hmm, I think in terms of online stores and credits.
The nature of the application does not determine the security model,
anymore than it determines the language. We don't use PHP for retail
and Java for wholesale. The nature of the app simply determines the
security assignments made, just as it determines what actual PHP or Java
we write.
Looking over your project website, it seems your doing this with
views, correct?
Column and row-level security, yes.
I also note your using Postgress as your DB Engine. Is it possible to
provide the same type of security through views in MySQL(to be honest,
due to the large number of v4 servers out there, I haven't kept up
with V5 in regards to views)
Prior to version 5, mySQL lacked so many basic database features that it
was just not in the running. That is why Andromeda uses Postgres (I
certainly did not pick Postgres so I could enjoy opting out of what
99.9% of the community is using, but it lets me deliver work to my
customers). With version 5 the non-MySQL world is looking at it and
saying, "Hmmm, they're getting there, i'll be interested in looking at
version 6 or 7."
Row and column level security wouldn't help from an online store
perspective.
See comment above. It's not about the kind of application.
To give an analogy, lots of people don't think Javascript handles
inheritance because there is no class. Then they find out about
prototypes and they say, "Oh, ok, there is a way to do everything, it's
just different." Now, whether or not its *better*, well I won't comment
on that.
Same goes for database security. There is a way to do everything you can
possibly want to do. The stunning and obvious fact that I will keep
repeating is, /it all comes down to table permission in the end
anyway!/ Most people just don't think that way, so they can't see how
to design in. They think in terms of, "Who should be allowed to run
this program that does these powerful and dangerous actions?" I will
claim that putting security directly into the database is better than
any other way because it /does what is needed in the end with the least
possible work./
You could establish a level of this security through triggers, for
example in a credit based system, instead of updating credits
directly, you could do inserts into a purchase table and that table
has a trigger to update the credits based on the package purchased.
More or less, yes. A public user is not allowed to write to the items
availability table. But he can insert a line into the orders table
(which is always stamped with his user_id), and a trigger fires that
decrements the availability.
I'm not disputing that your model is a good model to follow where
feasible(a database server where you can create user accounts for
every user), and given unlimited funds of course it should always be
implemented. But even this method doesn't eliminate problems with SQL
injection, it minimizes them(depending on the application design, this
may or may not result in fairly comprehensive protection.)
You are making the classic "Javascript can't do OO because it doesn't
have classes" mistake. Andromeda systems costs less to develop, are
more secure, and easier to document than any code-centric alternative,
precisely because of the radical DRY (don't repeat yourself) element of
our database design. A single spec details table structure,
calculations, and security, and the builder builds the database for me.
On a completely off-topic segue, the new UI that I showed off at LIPHP
is really cool, I'll be making that public today or tomorrow, it really
shows off the approach.
I wonder how difficult it would be to design a functional application
that would work both in the shared hosting/single db user model AND a
dedicated server/multi user model, and would there even be a market
for such an app(market defined as people who would use it in both modes)
Actually an Andromeda node can host any number of applications, private
business apps and public sites both (as SDS servers in fact do), with
multiple instances of the same apps and multiple versions of the same
apps all running simultaneously. All database users are fully isolated
into their individual apps.
--
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
