HTML and Script esoterica... Help?

[altivo]

OK, someone out there is undoubtedly a lot more versed in HTML and scripting than I am.

Here's what I've got:

1. Database vendor provides me with a "secret" URL to link to that gives access to a databank to which the library has subscribed.


2. I provide vendor with the range of IP addresses used by machines in the library, and they guarantee open access to the data from those addresses.


3. They also offer to let the library's "legitimate users" have access from other locations, provided that we validate them by passwords or something first.


4. I can validate them by checking their 14-digit library card number, and have already done so for other applications. Simple, no? No!

Here's why: The vendor wants the HTTP_REFERER environment variable to be a known value, always the same, that they can check to show that the access is validated. They do NOT want the user to know what URL they have been linked to when they gain access.

I know how to meet one or the other of those requirements, but not both at the same time. If I use a script to validate the user's access, and then link them to the right URL by using "Location" or "Refresh" the HTTP_REFERER comes up blank at the destination. If I use the script to send the user to a confirmation page and ask them to click a button or link to get to the target, HTTP_REFERER is set and valid but the user can easily figure out the direct URL to link to,

Now theoretically, even knowing the "secret" URL does no good because HTTP_REFERER can't be set to an arbitrary value. Or can it? If it can, someone knowing the URL and the referring location can gain access to the data illicitly. If it can't, then it doesn't seem to matter if the target URL is discoverable.

Or is there a solution to this problem that I'm not seeing? I think some of you may well know. bariki? hellmutt?

Comments

[farhoug.livejournal.com]

It isn't a big trick to alter HTTP headers to change the referer, and almost all browsers have the possibility to not send it anyways... that is, if someone wants to go through a referer check, there's not much to stop them.

The only thing that comes to mind to is to proxy all traffic that comes from and goes to the "secret" URL. Otherwise it wouldn't be that "secret", if browser converses with the third party directly.

Perhaps there is some other trick to pull that off, but that's all I can figure out at this hour... =)

[altivo.livejournal.com]

I'm assuming that the vendor masks their entry point URL themselves, by some sort of redirection or header trick. But that's their problem. Yes, once linked there, the browser will be conversing directly with their server, not mine.

I deal with other data vendors who have similar needs, but they all do it either by calling my validation routine with the library barcode provided to them by the user, or by letting my validation script supply them with an account and password that they use to set up a session for the referred user. The user doesn't know and can't see the account and password information.

[duskwuff.livejournal.com]

Location: and Refresh: work a little differently than you're figuring. Basically, if the server issues a redirect, the Referer: gives the address that sent the browser to the page that issued the redirect, not the page that contained the redirect itself. You can use Javascript to reset document.location if you really want to set a specific referer.

And, as farhoug said, note that Referer is absolutely unreliable - some personal security suites (cough, Norton, cough) will filter it out by default (!), and some browsers will let you set an arbitrary referer. Its only real use is as an item to track in web stats.

Also, there is absolutely no way to keep a URL secret. That's bad security, and if that and a referer is all that's protecting the site, the database provider is hardly even trying.

[altivo.livejournal.com]

I figured that referer is unreliable, but that's the vendor's decision to use it, not mine. I'm just concerned about setting it.

I'm thinking I should use a cookie set by the validation routine to secure access to the referring page or script, so that will keep anyone from linking directly to the referral point. But in my tests, I found that any kind of redirect I used to get to the target came up with a null value for referer.

If I use JScript to set a bogus referer value (one for a page that doesn't actually exist) it would probably be secure against most normal users, but anyone who knows how to read the document source could figure it out.

I think I'm going to have to demand a better explanation from the vendor of what it is they want.

[altivo.livejournal.com]

OK, I found why Location: didn't seem to be working, got that fixed. Thanks for your help. That seems to resolve the dilemma for me.

The fact that this vendor wants to rely on REFERER for security is their problem, not mine, fortunately.

So my login script checks the requesting IP, and if it is local, links the user to the vendor's page via Location: referral. The vendor doesn't care about REFERER as long as the requesting IP is in our range.

If the IP is outside, then I ask for a library card number and validate them, and if valid, use Location: again to link to the vendor's page. The REFERER value is being set to that of the validation script, and the vendor can check for that.

Users whose software blocks out REFERER values will either have to disable that feature or only use the database from inside the library. ;P

[duskwuff.livejournal.com]

Fair enough. It's their database, not yours, after all, and the security is their problem :•P

What you might want to do, though, is stick a quick notice on the page to the effect of:

Norton Internet Security and other software that blocks certain HTTP headers may prevent you from viewing this site. Click here for instructions on how to disable this feature in Norton Internet Security. If you're using something else, you're on your own.

[hellmutt.livejournal.com]

Not a clue I'm afraid, but thanks for flatteringly overestimating my techiness. :)