Deron Meranda
deron.meranda at gmail.com
Tue Apr 25 17:00:19 EDT 2006
On 4/25/06, Joshua Ginsberg <listspam at flowtheory.net> wrote: > > Surely it can't be all that easy? There must be some tricks for > > securing things that I'm not aware of. Something I'm misunderstanding? Proper website security is a very tough thing to get correct. The history is littered with big companies that have gotten it wrong: HotMail, Yahoo, Amazon, etc... Fortunately for many sites just close enough is good enough. You really need to determine what kind of security you need to figure out what to do. Using cookies instead of (or in addition to) HTTP authentication (Basic/Digest) is in many cases somewhat better, mainly because you have better control over the browser memorizing passwords and that the server can make it easy to log off a user (just try to log off when using HTTP authentication). Login forms should set the autocomplete="off" attribute to try to force browsers not to remember passwords...although with things like the Google toolbar, even that doesn't always work. Using extra devices like captchas can help prevent bot brute-forcing attacks (with reduced usability). (In a LAN/Intranet environment you can use other protocols such as NTLM or Kerberos, which are a bit more secure, but challenging to configure). But even cookies aren't the best either. First you should always issue encrypted (or stateless) cookies. They should have domain restrictions set, as well as SSL-only restrictions (which, btw, see mod_python issue 108 http://issues.apache.org/jira/browse/MODPYTHON-108). You may want to disable the TRACE method in Apache to prevent cookie stealing. If you want to do any sort of log off or expiration, you should also include the expiration date in the cookie content (and properly encrypted or signed), since the actual cookie expiration property is modifiable by the user. And if not *everything* is over TLS/SSL, then it's not worth putting too much effort into it anyway. (Which, btw, google mail can operate in all-SSL mode if you start at the page https://mail.google.com/ when you first log in). Even then though, if you're not validating client certificates, TLS/SSL is severely handicapped already from man-in-the-middle attacks. What I do (by using mod_python) is to use a cookie-based system. First a subset of my server (say the /login url) is set to use it's own private PythonInterpreter and PythonPath; and all of my high-sensitive stuff goes in there. It is what draws the login forms and processes them. When it logs somebody in, it will issue a cookie whose content contains the user's id, the expiration timestamp, and a digital signature (you can use the mod_python's SignedCookie class for this). Then for the entire website (/ url), excluding /login and /error, I have a PythonAccessHandler which verifies the cookie, and will cause an HTTP 401 Unauthorized if it's not correct or has expired. If it's okay, then it stuffs information about the user into the req object so the content handlers can get to it if desired, as well as setting up and loading the session object (if you use sessions). The advantage of this is that it protects all my files, even things like images which are not handled by mod_python. And since it's in it's own handler, and forces 401's if somethings wrong, there's little chance that a broken content handler may accidently disable security. There are of course lots of different approaches, and even I have just glossed over what I do. -- Deron Meranda
|