[Courses] Web Database Security

[Raven, corporate courtesan]

Heya --

	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.

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.)  In order to figure out how to best secure your database,
there are a few things that we need to figure out.

	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.)

	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.)

	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?  Are there various levels of trust, or is
anyone who can access this database effectively "root" on it?  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.)  Are you doing
input checking to make sure that things like " ' / and so forth are
escaped?

> 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.

	This leads nicely into the secure programming thread we meant to
get around to discussing.  However, as a relative programming newbie,
I'm not as qualified as many here to speak about it.  Anyone who's a
more experienced programmer care to speak to this?  (We may want to move
this thread to techtalk, depending on how many folks are on this list.)
 
> Once someone is authenticated, I can hand them a cookie, but I'd like to 
> ensure that said cookie couldn't just be copied and pasted to some other 
> machine. (It's not that I trust people that little, especially the ones I'd 
> be trusting with access to the database. It's partly just for the security 
> exercise, and partly "But what if one of their roommates sneaks onto their 
> computer, or the thing gets stolen or hacked?")

	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? 
 
> 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.
 
> Any ideas? What would be the most secure, and yet most convenient, way to 
> do this?
 
	Afraid I'm more full of questions than answers on this one, but
maybe some of my questions will spark the right answers.

Cheers,
Raven
 
"You found the Amulet of Yendor!"