[Courses] Web Database Security

[Kai MacTane]

At 5/6/02 12:57 PM , Raven, corporate courtesan wrote:
>         I will preface this with a disclaimer -- I don't know a lot
>about databases.  I can generally make them do what I want, but the
>design thereof, comparative database programs, etc. is more in depth
>than I usually get.  So take me with a grain of salt on this one.

This isn't so much about database security, though -- it's more about Web 
security. Most of the same problems would apply if users were accessing 
nearly anything else.

Basically my question here is: "I want to give a certain group of 
individuals the ability to access Thing X over the Web. How do I do this 
securely?"

"Securely", in this case means: a legitimate user should not be able to 
give access to some non-legitimate user, short of telling them hir username 
and password. A legitimate user's hypothetical nefarious roommate shouldn't 
be able to sneak into their computer and borrow/steal their cookie, for 
example. But Legitimate User X should be able to access the service from 
anywhere on the Net.

>Quoth Kai MacTane (Wed, May 01, 2002 at 05:49:21PM -0700):
> > (At the moment, both the contents of the table and its structure can be
> > edited using the Web interface. Links to the pages to do so are only
> > displayed in the nav bar if you're coming from the IP of my house's local
> > network, but someone who knew the appropriate URLs could enter them by 
> hand
> > from another location.)
>
>         Okay, that's something that should be changed.  (It's unlikely
>that anyone would figure out the URLs, but security through obscurity is
>Not Good.)

Yes, absolutely.

>         One -- what do the users that you wish to give access to have in
>common?  Anything?  (If it just turns out to be "internet access and an
>interest in Tolkien", that's fine, but if they're all coming from static
>IPs or they all use Platform X or something, you might be able to use
>that to enhance security.)

They're pretty much all Internet users who have an interest in Tolkien. Of 
the people I'm thinking of allowing as database editors right now, they 
break down as follows:

* One on the East Coast of the US, using a mail server that appears
   to be in California somewhere;
* One from Poland, using that same possibly-Californian mail server;
* One in Holland, using a Dutch ISP;
* Another one that I think is in Holland, using Hotmail;
* One on Norway, coming through a Norwegian university;
* One from Greece, using a Yahoo! Mail account; and
* One from somewhere-in-the-US, using a Hotmail account.

I'm not sure what platform any of these people use, and I certainly don't 
want to mandate a platform -- I hate it when other people do that. ("Our 
software can be used by any Windows computer!" makes me want to scream. And 
then there's "We support both platforms -- Windows *and* Mac!")

>         Two -- how are you going to distribute these URLs?  E-mail is
>plain text and sniffable.  If you are depending on people not knowing
>the URLs, having them sit unencrypted on a server that may be
>super-insecure (or even already hacked) is not a good idea.  If you opt
>to password-protect the page, have people call you or send you PGP mail
>or something else to get the password.  Plaintext mail with "the secret
>URL is here, and your password to access it is JohnRonaldReuel" all
>there is handing the keys to the kingdom to anyone who sniffs or reads
>that mail.  (Again, the odds of this happening are low, but the disaster
>potential if it does is reasonably high.)

Ugh. You have a very good point there, and since some of these people are 
using free HTML mail providers, I cannot count on the security of their 
mail servers. OTOH, I also can't count on these folks being able to deal 
with a PGP-encrypted email, and I sure as hell can't phone them all!

As part of the security system, I plan to make sure that none of the 
database-affecting components will work unless you have an authentication 
token. So keeping the URLs secret shouldn't be an issue (once this is done).

>         Three -- how much are you trusting your users?  Are you giving
>them permission to remove entries as well as add them?  Can they remove
>entries other people make?

I haven't decided on that yet. At the moment, the only way to remove an 
entry is via direct SQL command on the server (i.e., command-line login). I 
foresee very little need for removal of entries, and so I didn't create a 
Web interface tool for that.

>Are there various levels of trust, or is anyone who can access this 
>database effectively "root" on it?

At the moment, anyone who can access the db-editing tools can add and edit 
any entry, and can add, redefine, and remove database columns. So, in 
theory, they could nuke the entire db just by removing all columns. This 
would be something of a chore, since they'd have to remove each one as its 
own operation, and there's thirty-plus columns... but they could just zap 
three to five important ones, and leave the whole thing a shambles.

>Is there a limit to how much data one user can add?  (Filling up your disk 
>with 20,000,000 entries for "hahasucker" is a bad thing.)

There is no such limit. I'm trying to only hand editing ability to people 
that I trust not to be assholes.

That's a security flaw, isn't it? :)

>Are you doing input checking to make sure that things like " ' / and so 
>forth are escaped?

I'm doing that in a couple of places where they're liable to get used 
legitimately (free-form text fields), because otherwise they'll break the 
SQL syntax. I don't think any of this could get turned into command lines. 
Still, better escaping is a good idea anyway.

> > I can certainly set up a second database table for authentication
> > information (probably just username and password) and have any
> > component that needs to access that database for authentication
> > purposes.
>
>         It goes without saying, but -- protect that database.  I'd only
>give one user access to it, and check any scripts that run as that user
>for buffer overflows, input validation, etc.

I figure that one gets accessed only by the command line, except for 
allowing users to change their passwords (and to read it to authenticate 
users). Yes, I need to be careful about the coding on that one.

>         Can you come up with something machine-specific to add into the
>cookie and then check against?  There's IP address, but NATted computers
>and ones that have 127.0.0.1 as their host IP will break this.  Also,
>all the cookie thief would have to do is change the IP of their machine
>to match what's in the cookie.  Can you think of anything that you can
>find out remotely, that the user cannot easily change, that's machine
>specific?

The only thing that comes quickly to mind is MAC address, and I'm not sure 
if I can easily determine it.

What if I take the IP address, use the password as a salt or hash with 
which to encrypt the address, and then put that in my authentication token?

> > But then, I can't expire someone's access until they close their
> > browser -- I'd like to be able to auto-expire their login after
> > something like 20 or 30 minutes of inactivity.
>
>         Yeah, this would be a good feature.

Okay, so this pretty much needs to be cookie-based... yes? Or am I missing 
some other method?

                                                 --Kai MacTane
----------------------------------------------------------------------
"Wind in wings,/Two angels falling
  To die like this/With a last kiss..."
                                                 --Siouxsie and the
                                                   Banshees,
                                                  "Face to Face"