NYCPHP Meetup

[Kenneth Downs]

bz-gmort at beezifies.com 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070928/f6ff80e3/attachment.html>