[thelist] Enough security

Chris spam at cimmanon.org
Wed Nov 10 08:10:05 CST 2004


On Wed, 10 Nov 2004 14:41:32 +0100, Andreas Wahlin  
<Andreas.Wahlin at ufl.gu.se> wrote:

> I have a site that different persons log onto, mainly it's
> administrators and students. Information logged on the students is
> somewhat sensible; adress, phone number, "social security number"
> (Personnummer for Swedes), some administrator comments and so forth.
> This is protected with userid and password login.
>
> The site as such is protected by SSL, and I have an Access 2003 database
> (ok so flame me :) in a place where you can't reach it from the web
> (like typing https://thesite/thedatabase.mdb). This database contains
> usernames and passwords and of course all the data.
> The userid and password is input by using a form with method post and
> action="", so the info gets posted to the same page and then parsed in
> ASP script.
> The ASP script fetches username and password from the database and
> compares with Request.Form, if they match a Session variable is set to
> the username which every page then polls to see if the user is a valid
> one.
> Thus only one comparison is done with username and password, after that
> each page just checks if the username is in the database.
>
> Now, my question, if you've bared with me so far is; is this enough
> security. Can I sleep at night knowing I did pretty much what I could,
> or is this childsplay? (I'm not that good server side, or on security)
>
> I know that if only people knew the username of a person and the name of
> the session variable in which I store it, they could set that externally
> and then just walz in on the place, but other than that I don't see any
> major flaws, but then I don't know much about this.
>
> Big thanks in advance for help
>
> Andreas

Sessions cannot be forged like cookies (if ASP's are the same as PHP's  
sessions, anyway), since all of the session information is stored server  
side.  The only thing users can see is a hash that's used to determine  
which session that user owns.  The only danger with sessions is if someone  
guesses or steals the hash of an existing session (this is the main reason  
why I shy away from hashes that appear in URLs:  they show up in  
referrals).

Provided you're protecting the database from SQL injections and making  
sure that XSS attacks are not possible via form submissions (if ASP has a  
function similar to PHP's striptags(), that would be a good place to  
start), I would say what you're doing is "good enough".

-- 
chris


More information about the thelist mailing list