sorry - hit enter too soon - I mean to write that I can't
add something to application start without taking into
consideration installation time. I don't want to mess
with that for now. So, I'm going to leave this bug alone.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here's something emailed to me related to this topic:
Why do you have to store the session guid in a database
table? While I don't see a quick and
apparent way to hijack a session in your code, this is
definitely not a good security practice.
Currently any user who has access to query.aspx or edit
access to queries.aspx already owns the system,
but if at some moment you include some security checks to
these pages you'll have to worry of an
additional object - the sessions table. Anyone who can read
the sessions table can hijack the admin
session. Anyone who hijacks the admin session owns the system.
You don't delete rows in sessions table unless a user
explicitly clicked on the Logout link
(believe me, nobody clicks there). Thus, if I have stolen an
old cookie with an admin session guid, I
own the system.
Your code already depends on the ASP Session - you put a lot
of stuff there. Why don't store the
session guid in the ASP Session object? Or, at least, delete
a row from sessions table when an ASP
Session times out?
A more general question. Why don't you use the built-in
ASP.NET authentication and authorization
features? MS has invested a lot of work both into the code
supporting these features and into the
'best practices' documents accompanying it. They support
forms authentication, integrated Windows
authentication, Passport authentication - whatever you want.
And it's even easier to use then in
ASP 2.x.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=645778
Because there is no "logoff" and that's what triggers me to
go clean them up. I could add something to Application
start, I guess.
Logged In: YES
user_id=645778
can't add something to application start because that fires
even
Logged In: YES
user_id=645778
sorry - hit enter too soon - I mean to write that I can't
add something to application start without taking into
consideration installation time. I don't want to mess
with that for now. So, I'm going to leave this bug alone.
Logged In: YES
user_id=645778
Here's something emailed to me related to this topic:
Why do you have to store the session guid in a database
table? While I don't see a quick and
apparent way to hijack a session in your code, this is
definitely not a good security practice.
Currently any user who has access to query.aspx or edit
access to queries.aspx already owns the system,
but if at some moment you include some security checks to
these pages you'll have to worry of an
additional object - the sessions table. Anyone who can read
the sessions table can hijack the admin
session. Anyone who hijacks the admin session owns the system.
You don't delete rows in sessions table unless a user
explicitly clicked on the Logout link
(believe me, nobody clicks there). Thus, if I have stolen an
old cookie with an admin session guid, I
own the system.
Your code already depends on the ASP Session - you put a lot
of stuff there. Why don't store the
session guid in the ASP Session object? Or, at least, delete
a row from sessions table when an ASP
Session times out?
A more general question. Why don't you use the built-in
ASP.NET authentication and authorization
features? MS has invested a lot of work both into the code
supporting these features and into the
'best practices' documents accompanying it. They support
forms authentication, integrated Windows
authentication, Passport authentication - whatever you want.
And it's even easier to use then in
ASP 2.x.