[thelist] Enough security

Ken Schaefer Ken at adOpenStatic.com
Wed Nov 10 22:30:48 CST 2004

: -----Original Message-----
: From: thelist-bounces at lists.evolt.org
[mailto:thelist-bounces at lists.evolt.org] On
: Behalf Of Andreas Wahlin
: Subject: SV: [thelist] Enough security
: <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).>
: Ah, very good to know. Then it's better than I thought :)

If you are using SSL, then cookie theft attacks are usually fairly difficult
(as the cookie is encrypted between the server and client). Even if you use
URL based sessionIDs, the sessions will eventually expire, making session
replay attacks difficult. To prevent them being exposed to other sites via
the HTTP_Referer header, you can use a single "out" page which redirects user
to external links.

: <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".>
: Now to google for XSS attacks and SQL injections ... Saw somethig about
: SQL injections somewhere.

I have posted a number of times about this. Search the archives. Here are
some links to get you started:

OWASP (Open Web Application Security Project) Web App Security Guide. This
covers SQL injection, replay attacks, XSS attacks, cookie theft, all sorts of

SQL Injection links:

For the question "enough security?" I think I've posted some stuff on that as
well. Security (and the amount of it) really depends on what you are trying
to protect against. All of the things mentioned above are about protecting
unauthorized access to the web application (and through the application to
the data store). There is nothing about protecting the Access database file
itself against other types of access (directly off the file system). If
someone managed to use the FSO, or Explorer or similar to make a copy of the
database, all the user's details are available since there is no
username/password protecting the database, and none of the data is encrypted
or hashed (as far as we are aware from your description).


More information about the thelist mailing list