RE: Reviewing security parameters

My $0.02:
  First, if you write to a database each time a user logs in, you
may be susceptible to a DOS attack (imagine me holding down Refresh
after I login).
  Next, make sure your random number generator doesn't suck. You might
want to do something like take hex( md5( username + timestamp + salt ))
instead.
  Does the SSL check happen on each page or just the login page?
  About typing session to IP: First, obviously IPs are spoofable to
some extent. However, even worse is that some ISPs spread their
customer's requests over multiple transparent proxy servers (like AOL),
so the same person loading up a web page with 5 different images
*might* get 5 different IPs in the web server's log. It doesn't mean
you shouldn't track by IP, it's better than nothing, but you might
need to think about how to get around this.
  And finally, the devil's in the details. Bad security is easy, and
good security is hard. I'd get another pair of eyes (or maybe a couple
dozen) to look at your script and give their opinion too.

Hope that helps--
Regards,

Michael Scovetta

-----Original Message-----
From: Simon Lemieux [mailto:lemieuxs_at_ca.inter.net]
Sent: Friday, April 16, 2004 12:47 PM
To: webappsec_at_securityfocus.com
Subject: Reviewing security parameters

Hi there,
   I just composed a login page for my administration of my website.

I just wanted to make sure I had taken everything in consideration when
programming that php script. My main focus is, of course, security.

At first a login variable is initialized with "guest" in it. If the
whole script fails or if the user was not granted access, it will return
"guest". It is then the duty of the index.php (that called my login
script) to check what login was returned and take action if it was
"guest", like refusing all access. But as you see the script is also
designed to let a guest come in and still use some things.

Guest access is denied on my administration page of course.

The script checks if it was run using SSL. If not it will automatically
return the "guest" user and will print a link to the same page with
https://... So it always authenticate users with SSL.

Also, the inputs the user will send to login are the forms _REQUESTs
that contains login and password and then the input become a COOKIE
which contains a random ID. All these inputs are checked to see if they
are trustable; they must contain only letters and numbers, I've also
allowed some punctuation but no " or '...

The Cookie ID is a string of 32 characters given randomly and stored in
a login database with the user's IP address and user ID.

So I check to see if both ID and IP matches the user's.

At any point if the Cookie contains wrong information or if it contains
untrustable characters, the user is disconnected (ie. all login records
are closed and user will have to re-auth).

Logins, disconnection, bad login/passwords, untrustable characters are
reported in a Log database.

Do you guys think this script is safe?

Thanks,
   Simon

-- 
Dedicated to audio/visual and interactive artwork.
http://xilo.cjb.net/