RE: Reviewing security parameters

["Scovetta, Michael V" <Michael.Scovetta () ca com>]

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 () ca inter net]
Sent: Friday, April 16, 2004 12:47 PM
To: webappsec () 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/