Bypass login prevention?

[maikai]

Hi developers,
I need some help in making my web site safer.
How can i prevent people from copy and pasting an address which can bypass the username check?

Am i making any sense here?

I read somewhere that Session is able to prevent this.

How do i implement session thingey?
i currently use this to redirect users to the login page


<%
Dim mymember, errmsg
mymember = Request.Cookies("username")
if mymember = "" then
errmsg = "Please login first"
response.Redirect("login.asp?action=" & errmsg)
end if
%>


Thanx alot

[lmf232s]

you basically got it, or you could do this which is the same thing you have.

if Session("LoggedOn") = True then
'do nothing they are already logged on
else
response.redirect"Login.asp"
end if

this would be at the top of every page.

[maikai]

Hmmm....it doesn't seem to work. Do I replace what i have on top of every page with this?

if Session("LoggedOn") = True then
else
errmsg = "Please login first"
response.Redirect("login.asp?action=" & errmsg)
end if

How do i set the Session to true?
I have a login page that sends the username and password to an ASP page that checks its authenticity with the database.

do i need to add anything in that part of the coding?

[russell_g_1]

Just add

Session("LoggedOn") = True

to the code where you validate the username and password.

And yes, you need to add it to every page that you want protected by the login system.

i stick this at the top of my stuff

if Session("LoggedOn") then
response.write "Please login first"
response.end
end if

[lmf232s]

if Session("LoggedOn") = True then
else
errmsg = "Please login first"
response.Redirect("login.asp?action=" & errmsg)
end if


Yes like russell said, when you validate the username and password,
then populate the session variables.

Another thing is that your errmsg will not dispaly they way you have
it. You set the errmsg but once you hit response.redirect its
going to take you to a new page. So you could do a couple of things.
Here is just 1 idea. have your code like this

if Session("LoggedOn") = True then
else
errmsg = "Please login first"
'add some code to open a new page and display the error message
' or do this
respone.redirect "Please Login First"%><br>
<a href="Login.asp">Click here to Login</a>
<%
respose.end
end if


you get what i am saying, or you could just dispaly the error message
on the login screen.

[maikai]

Ok, will try it. Is there any other way to store login information? I'm currently using this

response.cookies("username") = rs("username")

is the Session more secure?

[phpnovice]

is the Session more secure?
I'd be interested to hear the response to that, too. Because, the ASP Session uses client cookies anyway.

[buntine]

You could just alter the statement slightly so there is no dead code.

if Session("LoggedOn") <> True then
errmsg = "Please login first"
response.Redirect("login.asp?action=" & errmsg)
end if


is the Session more secure?

Nup. But I think it is handier because of the functionality of the glabal.asa file.

Regards.

[russell_g_1]

but does session pass the values of all your variables back and forth like a cookie or is it just the sessionid?

[phpnovice]

To my understanding... All ASP Session variables are stored as client cookies -- unlike PHP (which just does the session id this way).

[russell_g_1]

i thought that session variables were all stored in memory on the web server in a bit of memory reserved for that session. the only bit that gets sent to a client is the sessionid (which uniquely identifies a client's session) in the form of a cookie.

i would assume that it would be more secure to use session instead of request.cookies because the values aren't passed around (and can't be tampered with) if they're just on the server.

[phpnovice]

OK, I went and read it again. This time I got the idea that it is as you say:

About SessionID and Cookies

The first time a user requests an .asp file within a given application, ASP generates a SessionID. A number produced by a complex algorithm, the SessionID uniquely identifies each user's session. At the beginning of a new session, the server stores the Session ID in the user's Web browser as a cookie.

The SessionID cookie is similar to a locker key in that, as the user interacts with an application during a session, ASP can store information for the user in a "locker" on the server. The user's SessionID cookie, transmitted in the HTTP request header, enables access to this information in the way that a locker key enables access to a locker's contents. Each time that ASP receives a request for a page, it checks the HTTP request header for a SessionID cookie.

After storing the SessionID cookie in the user's browser, ASP reuses the same cookie to track the session, even if the user requests another .asp file, or requests an .asp file running in other application. Likewise, if the user deliberately abandons or lets the session timeout, and then proceeds to request another .asp file, ASP begins a new session using the same cookie. The only time a user receives a new SessionID cookie is when the server administrator restarts the server, thus clearing the SessionID settings stored in memory, or the user restarts the Web browser.

By reusing the SessionID cookie, ASP minimizes the number of cookies sent to the browser. Additionally, if you determine that your ASP application does not require session management, you can prevent ASP from tracking session and sending SessionID cookies to users.

ASP will not send the session cookies under the following conditions:

If an application has session state disabled.
If an ASP page is defined as sessionless, that is, a page containing the
<%@ EnableSessionState=False %>
tag. For more information, see Sessionless ASP Pages.

You should also note that SessionID cookies are not intended to provide a permanent or secure means for tracking users across multiple visits to a Web site. The SessionID information stored in the server computer's memory can be easily lost or impersonated by a malicious user. If you want track users who visit your Web application over a longer periods, you must create a user identification by storing a special cookie in a user's Web browser and saving the cookie information to a database. If you do so, configure your application to use SSL in order to encrypt the SessionID and protect it from malicious users. For more information, see Using Cookies and see "Secure Sockets Layer" in IIS Help, which is accessible from IIS Manager..
As for security:

ASP shares a pool of session identification cookies between all applications within the same process. A malicious user can manipulate an established session cookie from an application to which they have valid access and use it to gain access to another application within the same process. This can only happen if the session identification cookie is unencrypted. To ensure that never happens, always use Secure Sockets Layer (SSL) with application that use session cookies. For information on configuring SSL for your application, see "Secure Sockets Layer" in IIS Help, which is accessible from IIS Manager.