...

View Full Version : Testing the origin of the refering page



Gary Williams
10-06-2003, 08:38 AM
Hi All,

I am an asp newbie so please bear with the following problem description.

I need to test the url of the previous page to the one displayed. That is, I need to know the url of the page that called the one currently on the screen, so that I can test it to prevent people accessing the site from 'bookmarks', etc.

I have tried javascript and now know that document.referrer is not reliable across all versions of IE and that you can't get at the 'History' function anymore.

I have read that 'session.variables' may be used to solve this, but that is as far as I have got. I can use asp to search/report a database but that is the limit of my capabilities at present.

Any idea's/polite suggestion? :-)

Regards

Gary

glenngv
10-06-2003, 08:56 AM
use request.servervariables("HTTP_REFERER")

Gary Williams
10-09-2003, 09:30 PM
Hi Glenn,

Tried that, but HTTP_REFERER doesn't work with all versions of IE.

Thanks

Gary

HairyTeeth
10-10-2003, 03:58 AM
If you have a login page, you can set a session variable when they have sucessfully logged in - eg:

Session("isLoggedIn") = true

When the session expires, the session variable is destroyed (ie. session variables have session scope). If the user logs out, I set the session variable values to "" (zero-length string) - I should probably set them to equal Nothing and call Session.Abandon as well, but I don't bother (is there a reason that I should, anyone??)

In your other pages, you have a procedure that checks to see if that particular session variable exists.

If it doesn't exist when they try to visit a page that requires the session variable to be true, they get redirected to another page (login for example). If it does exist, well, their session is current and they can access the page.

If a user bookmarks a page and visits from the bookmark (and they don't have a current session), they get redirected to wherever. (login.asp say)

As you can see, this method assumes a login process - but that need not be the case. For example, you can set a session variable to equal the url of a page and read that Session variable on another page like this:

--
page001.asp
--


Session("strUrlReferer") = Request.ServerVariables("URL")

--
page002.asp
--


Response.Write Session("strUrlReferer")

The value of Session("strUrlReferer") should change with each page that has code like page001.asp (I haven't tried it though), so that when you actually ask for the Session("strUrlReferer") value (as I did in page002.asp above), it's value should be that of the refering url.

If the value of Session("strUrlReferer") is empty (or a particular value that you want to know about), then you can redirect (or whatever) as described for the login method.

But this only works for pages in your own site (as does the login process above)

whammy
10-13-2003, 02:33 AM
IE shouldn't have anything to do with it anyway, unless cookies are disabled.

Then it's a problem because if cookies are disabled, Session variables won't work in ASP.

raf's other solution is definitely thinking outside of the box, and sounds like it would work. But before you go with that method, I'd double-check your assumption that HTTP_REFERER doesn't work with whatever browser, because it's server-side code!

What that means is that it doesn't matter what browser you're using. The only thing I can see that could possibly affect regarding client-side code and HTTP_REFERER is the following:

1. There is no referrer (easy enough to check for)
2. Cookies are disabled on the client's browser (also easy enough to check for - set a cookie, and see if it exists!)

I'd look at those two things first, and then go from there.

M@rco
10-14-2003, 04:57 PM
Gary, referrer URLs have nothing whatsoever to do with cookies.

The only connection between them is that some "privacy" apps and/or firewalls block or interfere with them. This means that you *cannot* rely on a referrer URL being available (or not)! :p

In any case, you're barking up the wrong tree - Hairyfew has already provided the correct approach, i.e. to create a login system which sets a session variable, which is then checked at the top of each page that you need to protet. This DOES require cookies to be enabled, but since 99% of modern sites need them, any user disabling them is causing his own problems, and I suggest that should not be your concern.

raf
10-14-2003, 08:53 PM
raf's other solution is definitely thinking outside of the box, and sounds like it would work.
Hey thanks whammy. (though you've gotten me realy confused now :D )

Anyway : request.servervariables("HTTP_REFERER") is useless for what you try to do, because it will only contain a value if the client clicked a link to request your page. If he clicked a bookmark or types in the pageadress, that variable wount even be in the servervariables-collection.

The only two alternatives are sessions (but they need cookies) or storing there IP in a db.
But this second method has the disadvantages that there are providers (like AOL) that assign another IP number to each pagerequest ...
So what you need to do is :
- on top of the page, check if a sessionvariable is set
- if not, run a select agains a table in your db with all IP's of active sessions. If found --> display page (there is an incredibly wmall chance this will be a 'false hit' of a second AOL surfer, but that chance is so slim ...
- if IP not found, set a cookie and store the clients IP in a sessionvariable and then redirect to another page with the IP adress in the querystring and read the cookie --> if the cookie is set, redirect to the loginform.(after a succesful login, set the sessionvariable you test on on top of each page). If the cookie isn't set, display a message that he will only be able to continue if he has a 'stable' IP (so no AOL users) and provide a link to a third page, again with the IP in the querystring.
- on this third page you compare the IP of the request with the value in the querystring. If they match, create a record in the sessiontable

I wrote something similar in PHP recently, but if i were you, i'd just require users to have cookies enabled, because it becomes a lot more complecated and resource eating to apply this hack...

whammy
10-15-2003, 03:15 AM
I agree... but using the HTTP_REFERER is a good way to make sure first of all that some wannabe hacker isn't creating his own HTML form to post to your website. Just check the ServerVariables collection and make sure you know where this post is coming from.

If using cookies is a problem, I'd perhaps provide a blurb on your website as to why cookies must be enabled.

The same type of thing is required on most websites - after all, it's the easiest solution, and probably the best. Anyone who knows how to disable cookies should be able to figure out how to enable them as well.

I require cookies on all of my sites, just for login purposes (and these don't necessarily use Session variables).

P.S. raf, your solution is so confusing and unnecessary (although you might have noticed something I didn't), that I quit reading it. It's much simpler than that, I think. :p

Why use two or three methods (let alone involving a database) when you can just check a cookie?

HairyTeeth
10-15-2003, 05:05 AM
Originally posted by whammy
raf's other solution is definitely thinking outside of the box, and sounds like it would work.
um... raf hadn't made a post at that stage. Were you refering to another thread?

raf
10-15-2003, 08:11 AM
Originally posted by whammy
I agree... but using the HTTP_REFERER is a good way to make sure first of all that some wannabe hacker isn't creating his own HTML form to post to your website.

There are more secure ways to achieve that. I'm not even sure checking the referer will stop them. Besides, this was the original question:


I need to test the url of the previous page to the one displayed. That is, I need to know the url of the page that called the one currently on the screen, so that I can test it to prevent people accessing the site from 'bookmarks', etc.

so it though i should point out that the referer-servervariable is empty when the page is requested through a bookmark or types in url


I require cookies on all of my sites, just for login purposes (and these don't necessarily use Session variables).

P.S. raf, your solution is so confusing and unnecessary (although you might have noticed something I didn't), that I quit reading it. It's much simpler than that, I think. :p

Why use two or three methods (let alone involving a database) when you can just check a cookie?
Well, i don't have any userrequirements and can still achieve the same functionality, unless they don't have a stable IP. It's just a more universal method, and is a typical case of 5 - 95 --> 95% of the code is needed for this extra 5 percent of users.

But as i pointed out in my closing comment ; i don't recommend it.


It's a lot of overkill if it is just to check the referer. I also use this session-table:
- to store all active and timed out sessions --> more secure and powerful then asp's build in sessionmanagement
- to also serve cookiedisabled users
- to store the last page they requested --> i don't proces a form if this formpages value isn't the value in the db
- to store the page they should be redirected to if they abort a proces or wan't to jump back a page --> i also don't require users to have javascript enabled and this enables me to make more stable applications.

Caffeine
10-15-2003, 08:30 AM
Originally posted by whammy
I agree... but using the HTTP_REFERER is a good way to make sure first of all that some wannabe hacker isn't creating his own HTML form to post to your website. Just check the ServerVariables collection and make sure you know where this post is coming from.

On this point I have to disagree. I don't consider myself being a 'wannabe hacker', not even close but I know that the Server.Variables are basically useless when it comes to security; they are so easy to fake! Therefore they should not be relied on.
Sessions / Cookies with encryption are much more secure. But this is kind of offtopic isnt it :D


If using cookies is a problem, I'd perhaps provide a blurb on your website as to why cookies must be enabled.
In sweden, there is some kind of law on that you _have to_ state that you use cookies, if you do. I'm not sure if the law say that you have to explicit state what they are used for. But maybe this is a Sweden-only-kind-of-thing, I don't know :confused:

I think a session/cookie-check sounds exactly what Gary wants.

M@rco
10-15-2003, 09:23 AM
Originally posted by Caffeine
On this point I have to disagree. I don't consider myself being a 'wannabe hacker', not even close but I know that the Server.Variables are basically useless when it comes to security; they are so easy to fake!Yes, anything originating from the client (HTTP headers in particular) is susceptible to manipulation.

Never trust the client! lol ;)

HairyTeeth
10-15-2003, 10:02 AM
Maybe I've missed something fundamental (not uncommon :rolleyes: ), but why explicitly check for (or set) a cookie if the requirement is only for a single session - as seems to be indicated in the original question?

Why not just set a session variable and check that?

Caffeine
10-15-2003, 10:19 AM
Originally posted by M@rco
Yes, anything originating from the client (HTTP headers in particular) is susceptible to manipulation.

Never trust the client! lol ;)

Call me paranoid.. but nope, never trust the clients if you want your webapp. to be secure!

raf
10-15-2003, 10:21 AM
Maybe I've missed something fundamental (not uncommon ), but why explicitly check for (or set) a cookie if the requirement is only for a single session - as seems to be indicated in the original question?

because ASP sessions rely on cookies. So if the client has cookies disabled, a new ASP session is started for each requested ASP-page.
The client side session cookie contains the sessionID, which the server needs to get with each request.

More info:
http://www.learnasp.com/learn/sessionswhat.asp

The only way to check if the client has cookies enabled, is to write a cookie and then attempt to read it. (Well, it's the only way i know ...)


There is also a PHP like way to deal with that problem (cookie disabled users) --> appending the sessionID to each URL but that is unsafe and shouldn't be used if you are concerned about session-hijacking. More info
http://www.aspfaqs.com/webtech/TheBook/page5.asp

M@rco
10-15-2003, 10:23 AM
I agree. As I have already said earlier, all he wants to do is prevent users arriving at certain pages without going through his site first. Referers are out (for reasons already discussed), so using a simple login which sets a session variable will be perfectly adequate.

Incidentally (for those who aren't aware), session state is maintained through the use of cookies anyway, so you could set a session cookie, or set a session variable - they'll be generated (and expire) at the same time anyway, and are both as easy as each other to set. The difference is that cookies are open to client-side manipulation, whereas session variables (which are server-side) are not, and hence the session variable approach is most secure.

Surely that's cleared everything up now? Have we finished?

:rolleyes: :p

raf
10-15-2003, 10:44 AM
Originally posted by M@rco
Surely that's cleared everything up now? Have we finished?

:rolleyes: :p
No. I suppose it was already partialy cleared up before your post but there are still some untreated issues.

So i'll go over it once again:

session cookie --> i suppose you mean a cookie created by your code without an expirationtime. This cookie can contain variable-value pairs that are stored on the clients machine (and that can be read and altered)
'sessionIDcookie' --> when a new session is created, the webserver sends a cookie to the clientsmachine that only contains the sessionID. If the client requests a new page, the server checks for the sessionID. If he doesn't find one (for instance the first requested page of that session, the first pagerequest after a sessiontimeout or a client that has cookies disabled) he will create a new session and send the sessionID in a cookie to the client. If you rely on ASP's build in sessionmanagement, then there is no way to diferentiate between these three situations. You need to keep a sessiontable inside your db for that and identify the requesting client basedon a sessionID or IP.
sessionvariables --> these are variable-value pairs that are stored on the server, and that can be identified with the sessionID.


So it depends on what your actual 'security' concern is.
--> Checking login-sessinvariables tells you if the client has logged in and has an active session (which is absolutely not the same as : 'did the client click on a link on one of my pages' !). For that, you need to keep track of the clients position inside your site, by storing a pageID inside a sessionvariable or sessiontable inside your db. (Remember, the db-approach will always work for all clients)
Else he can log in and than click the bookmark or type in the adress or submit a form he made on his own machine.

M@rco
10-15-2003, 11:39 AM
All absolutely true.

However, even tracking the IP is fallible, since any users accessing the internet via an HTTP proxy or NAT (such as all businesses, students at uni, etc. etc.) will appear to come from the same IP address.

raf
10-15-2003, 11:50 AM
You can check for that

http://www.codingforums.com/showthread.php?s=&threadid=25909&highlight=vote

Besides, the cascade is like this:
- if cookies enabled --> use session
- else --> check if 'stable' IP (that is an IP that stays the same during the session)
- if stable IP, identify client by IP in that session

So there is only a problem if you can not pass the proxy to get the real IP + if you have two simultanious users that have cookies disabled and are behind that same proxy.

So it's not bulletproof, but it'll go further then the proposed 'if you don't enable cookies, then get out !' setup.

whammy
10-15-2003, 03:10 PM
Hmm, ok I think you guys are right!

I'll have to take another look at your ideas there raf, and try them out myself. ;)

Gary Williams
10-16-2003, 09:48 AM
Hi All,

I certainly started a good discussion there!

Thanks to everyone for your advice and opinions. I'll now try to follow the technicalities of this thread and implement the idea's.

I found this script as an include file in an asp application. Is this the type of solution you mean:

========================

<%
if Session(cfgSessionPwdName) <> cfgAdminPassword and
InStr(1, Request.ServerVariables("SCRIPT_NAME"), "default.asp", vbTextCompare) <= 0 and IsSecurityEnabled() then Response.Redirect "default.asp"

Function IsSecurityEnabled
On Error Resume Next
If not cfgNoSecurity = True Then IsSecurityEnabled = True Else IsSecurityEnabled = False
On Error Goto 0
End Function
%>

==================

Regards

Gary

raf
10-16-2003, 10:21 AM
If you're gonnan rely on sessions, then it's always a good idea to work with different securityprofiles. I'v posted some code and additional info in these threads:
- loginform, loginprocessing, securitycheck on top of eachpage.
http://www.codingforums.com/search.php?s=&action=showresults&searchid=173853&sortby=lastpost&sortorder=descending

Gary Williams
10-16-2003, 10:59 AM
Thanks raf,

I'll go through posts from your link.

Regards

Gary

M@rco
10-16-2003, 11:20 AM
I had been writing a lengthy critique of that code, but unfortunately we just had a power outage and it was lost.

Rather than typing it all out again, my simple advice to you is to discard the code you have posted! Don't touch it with a bargepole! There's at least 5 fundamental problems with it!

Instead, I suggest you read raf's posts, and develop your own authentication solution. It's relatively easy to do, and you would benefit from doing the coding yourself rather than using snippets of code of dubious origin and which you might not fully understand.

Just my $0.02! ;)

whammy
10-17-2003, 02:50 AM
So I guess we're agreed that raf has studied this aspect more than we have (although for my needs my solutions work very well, so far). ;)

Good game raf... :D

raf
10-17-2003, 07:07 AM
Thanks.

By the way, the threads i refered to (where i posted some code) are just a basic 'session-variable checking' permission system.
If someone needs more info on setting up a system with a session-table inside the db (with ASP or PHP), then just drop me a mail or PM.

(Would be to much code and explanations to handle it here)



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum