[Courses] Web Database Security

[jennyw]

Kai,

One answer is to use sessions.  Some platforms, like PHP (and I'm pretty
sure, Zope), have session management built-in.  You may have to do more
research with others (for example, there seem to be several session
packages for Perl).

The idea with sessions is that once you authenticate a user, they get a
token. This can be passed in the URL, as a form variable, or whatever. You
do not need to use a cookie, although it's often easier to do so.  This
token is only good for a certain amount of time (like an hour).  The
session manager will match tokens against the current valid tokens, and if
the token isn't in the list, it will result in a rejection (which you can
handle any way you want).

As for someone else trying to take your token -- well, the fact that the 
token typically lasts for an hour or so (it can be refreshed if a user 
keeps the session going; or a new token can be generated if they're online 
for more than half an hour or whatever), this makes it kind of hard.  Even 
if they do this, though, your authentication method could take into 
account the IP address of the computer that got the token and if the IP 
does not match, a rejection will result. This should work for dial-up 
users, too, since chances are their IP will not change in the middle of a 
session.

This could be a complicated topic, but if you do a Web search about
reading about sessions would be a good start.

I don't think you mentioned your development language ... If you use PHP,
here's an article you might want to check out:

http://www.zend.com/zend/tut/session.php

Jen



On Mon, May 06, 2002 at 01:49:23PM -0700, Kai MacTane wrote:
> 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"
> 
> _______________________________________________
> Courses mailing list
> Courses at linuxchix.org
> http://mailman.linuxchix.org/mailman/listinfo/courses
> 
>