Site Logins/Security 1

[Qaroven]

Though I'd throw this general question out ..

On a site I'm tinkering on I use the ServerVariables('HTTP_COOKIE') to uniquely identify someone currently logged on, paired with their username.

Not sure exactly where that servervariable comes from or if it will work on most browsers?

Just wondered how reliable this method is, and other people's ideas for site logins/security. Ben
+61 403 395 052

 

[kor]

My Wrox Programers Reference defines the ServerVariables('HTTP_COOKIE') as "All the cookies that were sent from the client presented as a single string". The Request.Cookies collection is how you access them individually.

If you're discovering a cookie you didn't write yourself, it's probably the Session cookie. On every page that uses Session state, ASP automatically sends and reads a unique identifier cookie. That allows ASP to store Session variables on the server and only sends/receives the cookie identifier to the client to determine which set goes with each user.

From what I've read, it's certainly possible for the client with the right hacker script to spoof the Session cookie and thus gain unauthorized access to your web application. In that sense, it's not secure. However the vast majority of users have no interest or ability in this type of hacking, so using it for security is probably 'good enough'. That's true for all simple cookie-based site security.

 

[Qaroven]

Interesting ..
I just used HTTP_COOKIE 'cos it appeared to be a unique browserID. Once I've validated the login, I store the username and that identifier in the database and refer to it when checking permissions for each page.

(When viewed HTTP_COOKIE always appears to be something like ASPSESSIONIDFFFFABCD=ABFDGGEFBBCDDCBA) Ben
+61 403 395 052

 

[Ovatvvon]

Ben,
personally, I like to stay away from cookies when it comes to more security. You can easily create a user login database with microsoft access, creating a userID, password, name, etc etc fields. then create a form on the login page, and then create a loginValidate page that will request the userID and password from the login page and compare it to the database. If there is a match for the userID and the password is correct, allow them access, if not, redirect them to a noaccess page or the login page. Simple, database, login.asp, and loginValidate.asp.

Then the only thing you have left to do is keep them from gaining access to all of your "member" pages. at the top of every one of those pages, put an include script:
<!-- #include file=&quot;/include/checkAccess.asp&quot; -->
and make that file check for a memberFlag in the session state (which you set to 'true') during the loginValidate. If it's not, then redirect to a noaccess or login page. Here is examples:

---login.asp--------------------------------

<form method='post' action='loginValidate.asp' autocomplete='off'>
userID:<input type='text' name='userID'>
Password:<input type='password' name='password'>
<input type='submit' value='Submit'>
</form>


---loginValidate.asp-------------------------

<%
dim userID, password, sql
userID = request.form(&quot;userID&quot
password = request.form(&quot;password&quot
sql = &quot;SELECT * FROM users WHERE (((users.userID)='&quot; & userID & &quot;') And ((users.password)='&quot; & password & &quot;'));&quot;

set conn = server.CreateObject(&quot;ADODB.Connection&quot
DSNtemp = &quot;DRIVER={Microsoft Access Driver (*.mdb)};&quot;
DSNtemp = &quot;DBQ=C:\InetPub\

http://wwwroot\db\userList.mdb;&quot;

conn.Open DSNtemp
set rs = server.CreateObject(&quot;ADODB.Recordset&quot
rs.Open sql, conn, 3, 3

if rs.eof then
session(&quot;memberFlag&quot = false
response.redirect(&quot;login.asp&quot
else
session(&quot;memberFlag&quot = true
response.redirect(&quot;memberPage.asp&quot
end if

conn.Close
set conn = nothing
%>

---checkAccess.asp---------------------------

if session(&quot;memberFlag&quot <> true then
response.redirect(&quot;login.asp&quot
end if


---memberPage--------------------------------

<!-- #include file=&quot;include/checkAccess.asp&quot; -->
<html>
<head>
<title>Member Area</title>
</head>
<body bgcolor=&quot;#FFFFFF&quot; text=&quot;#000000&quot;>
<BR>
Only your members can see this!
<BR>
</body>
</html>


####################################################

Make sense? Seams like a lot more, but it's not. And would be a lot more secure than cookies! Plus, if the user empties their cookies from their browser...then what? Here, it's all based on the database, and the user input for userID and password.

Anyquestions write back here, or email me at jimbob550@hotmail.com


- Ovatvvon

 

[kor]

<Quote>Make sense? Seams like a lot more, but it's not. And would be a lot more secure than cookies! Plus, if the user empties their cookies from their browser...then what? Here, it's all based on the database, and the user input for userID and password.</Quote>


I'll give you a star for a good answer, but you're still using cookies. You're just letting ASP manage them instead of doing it yourself. You can't get away from them. HTTP is a stateless protocol and cookies are almost the only way to maintain state. The only way to avoid using cookies is the have the user enter their login information on every page.

 

[Ovatvvon]

I do believe I've heard that before. But I guess what I was getting at is that it's not stored as a cookie for the user to delete or what-have-you. Sorry for any misscommunication.