"Hidden" Hyperlinks

[CAMRAMan]

Scenario:

A customer wishes to link to web pages from an online catalogue. They have concerns about users potentially copying & pasting the hyperlinks and sending them to other, unauthorised people.

Another customer who had the same concerns used "hidden links" whereby the hyperlink could not be copied and then pasted into another medium. They will not say how they did this for commercial reasons.

I suspect it is quite a simple trick, but I know nothing! Is there an easy way to do this? If so, could you please give layman-friendly details?

If it helps, the catalogue is compiled using Excel, and is then converted into a proprietary format (I think) to create the catalogue.

TIA.

[Jaded]

I'd have thought that even if you protect the link all a nefarious chap would have to do to copy it would be to click on it and then copy the address line from the new window.

Or you script it in some way...

[tiermat]

From what I have seen the usual was is to use a javascript link to call the actual link, either in another window, or for download.

I will see if I can dig out some examples for you.

[Ham]

Trivial to work around, especially if you have Opera and can (1) turn Java off any time (2) display the address even if the coding hides it

[CAMRAMan]

The users of the catalogue will not be IT-savvy. To be honest, the information is not worth going to such lengths for, but needs must...

[bobb]

Trivial to work around, especially if you have Opera and can (1) turn Java off any time (2) display the address even if the coding hides it

You can do that in any browser. Java and JavaScript are two very different things BTW...

There are plenty of ways to fool the non-IT savvy, but you'll never get round a geek! Google is your friend here...

[vorsprung]

Scenario:

A customer wishes to link to web pages from an online catalogue. They have concerns about users potentially copying & pasting the hyperlinks and sending them to other, unauthorised people.

You can "hide" the hyperlinks using javascript.  This means that when the links are clicked on the page is jumped to.  But the hyperlink is still there and can potentially be copied this just makes it a bit more time consuming and difficult

If system has control over both ends of the hyperlink system then you could get the catalogue to issue a short life token to all users which were also part of the hyperlink.  Then you get the other end of the hyperlink to verify the the token is there and is valid.  This would reduce the lifespan of the hyperlinks and so their shareability

Basically what the customer is asking for shows a basic misunderstanding of what hyperlinks are and what they should be used for.

[CAMRAMan]

Possibly so, but I think it's more likely the way that the catalogue is designed to only display hyperlinks in the relevant section. Sadly, I have no control over the catalogue as it's standard & company-wide.

[itsbruce]

Scenario:

A customer wishes to link to web pages from an online catalogue. They have concerns about users potentially copying & pasting the hyperlinks and sending them to other, unauthorised people.

This is one of the dumbest things I ever heard.  If you can click on the link and go to the web page, you can copy the url of the page you've landed on and then send that link to your friends.   How are they going to stop that?  If they want to secure those pages, they'll have to start at the server end and even then it'd be nearly impossible unless they also send the customers usb dongles without which they can't connect to the site.

How are they going to detect it if somebody is "naughty"?  Load of bollocks.

Another customer who had the same concerns used "hidden links" whereby the hyperlink could not be copied and then pasted into another medium. They will not say how they did this for commercial reasons.

The won't say because it's a bogus method that doesn't work properly, is easily circumvented and everybody's afraid of the cretinous manager who imposed it.

If it helps, the catalogue is compiled using Excel, and is then converted into a proprietary format (I think) to create the catalogue.

Makes bugger all difference; it needs to be able to send a browser to a web page and that's the place where all this supposed security fails.

[iakobski]

For starters, the security model is clearly broken. If users are authorised to view the catalogue then that same authorisation should apply to all pages within that catalogue. If the pages they want to link to are outside the authorisation zone, then just bring them in. Trying to hide the URL is simply security by obscurity - the pages are not protected in any meaningful way.

It's not clear why they don't want to do this - perhaps the pages they want to link to are out of their control and there is some reason why they can't bring them into the authorised zone?

This is what I would do: the "hidden" links on the page in the catalogue are internal links to a server script with a code for the page they want to link to. The script looks up the real URL from a mapping table, fetches the page then re-serves the page with new HTTP headers, and any other edits required to hide the source. Simples.

The won't say because it's a bogus method that doesn't work properly, is easily circumvented and everybody's afraid of the cretinous manager who imposed it.

They won't say because they paid big bucks for it when they should have just moved the files. You can have my version for free. 

[itsbruce]

This is what I would do: the "hidden" links on the page in the catalogue are internal links to a server script with a code for the page they want to link to. The script looks up the real URL from a mapping table, fetches the page then re-serves the page with new HTTP headers, and any other edits required to hide the source. Simples.

You're assuming that the users are all inside the same network; not only do we not know this, from the information given, we don't know enough about the context, the nature of the online catalogue, the users and more.

[andygates]

Bruce is wise.

If you really wish to implement some security on it, you need to go the whole login hog, have the links require logons and the logons expire (typically with a short-lived cookie), so that unauthorised people just don't have all the parts needed: the destination pages look for the cookie and tell you to bog off if you don't have it (server-side, obviously, before presenting the information).

Hidden links that go to unsecured pages aren't really hidden at all.

Even if they were, the nefarious user could always File > Save Page and mail the snapshots to their Kremlin controller.

You could perhaps wrap it in Flash, make it a bear to do that with, but that's outside my ken.  It's still going to be security theatre...

And with logins, include a tracer in the source so you know which user blabbed!  

[vorsprung]

For starters, the security model is clearly broken.

They have no security model or methodology
Quite common with IT systems y'know

[JStone]

Once you start hiding links, you may also render them inaccessible to screen-readers, hence unusable by people reliant on assistive technology, and be on the receiving end of queries under the Disabilities Discrimination Act.

[iakobski]

This is what I would do: the "hidden" links on the page in the catalogue are internal links to a server script with a code for the page they want to link to. The script looks up the real URL from a mapping table, fetches the page then re-serves the page with new HTTP headers, and any other edits required to hide the source. Simples.

You're assuming that the users are all inside the same network; not only do we not know this, from the information given, we don't know enough about the context, the nature of the online catalogue, the users and more.

Agreed we don't know enough about the details, so I could be totally off-beam. But I didn't assume the users are on the same network - where do you get that from? This would work for the requirement as given - the users would be able to click on a link but they would not be able to give that link to anyone else.

EDIT OIC: when I said "internal link" I meant a link to the same site as the catalogue, ie within the same security context. As opposed to an "external link" to some other site.

[itsbruce]

Agreed we don't know enough about the details, so I could be totally off-beam. But I didn't assume the users are on the same network - where do you get that from? This would work for the requirement as given - the users would be able to click on a link but they would not be able to give that link to anyone else.

EDIT OIC: when I said "internal link" I meant a link to the same site as the catalogue, ie within the same security context. As opposed to an "external link" to some other site.

Yes, it was your reference to an internal link that confused me.  I don't see this as too much of a benefit, now you've clarified, as third parties will still be able to view the content, but then as I said, we don't have enough information about all of this.  Warwick Lad, you need to give us more info.  You need to explain what you mean by "unauthorised", what constitutes "authorised", who is sitting where, what is visible from where and so on.   Even your opening line is ambiguous (are you linking to "pages from an online catalogue" in some local document or are you putting "links to pages" into an online catalogue?  Time flies like an arrow, you know.)  We don't know what we're protecting from whom or how or why.

[iakobski]

LIke this (technology not necessarily php, any server-side script will do:

Suppose the security context is:

http://dumbclient.com/catalogue

Legitimate user goes to:

http://dumbclient.com/catalogue/index.php

At which point they have to enter their credentials. This starts their session so they can access any pages in the security context until the session ends. On one of the pages the client wants to have a link to

http://othervendor.com/valuable_product_data.html

but instead they have a link to

http://dumbclient.com/catalogue/hide_my_page.php?id=998876

So the server at dumbclient fetches and regurgitates the valuable_product_data to the authorised user. However, if the user sends the above URL to a third party, when they try to navigate to it they will need to supply valid credentials before the page is served. Only the server knows the location of the actual data page.

Of course, as you pointed out, the authorised user can still save the actual page and send that to all their mates. This hiding would make sense if the data on valuable_product_data.html is time-sensitive - stock prices, racing results, weather data, etc. This sounds likely, otherwise the client would have just copied all the pages into the security context in the first place.

[CAMRAMan]

Well, it's hard to go into too much detail without compromising which system it is and potentially opening up myself to problems.

I'll be as generic as I can, without naming names.

End users will be accessing an online catalogue loaded onto a system paid for by central government, but hosted by a third party company. The same third party applies all the rules regarding the catalogue. Suppliers register on the system and can upload catalogues.

Users will log onto the system and then have access to the supplier's catalogue. There is a field in the catalogue that can contain a URL. This will link to a place on the supplier's (my customer) server. The users will (possibly) be on the same network as this supplier. I am not sure about this, and as they are concerned about security, it may not be the case.

The security concern is about pricing and its sensitivity to other similar suppliers who may lose custom to "my" supplier.

The crazy thing is that there is a printed catalogue containing the same information that is very widely circulated!!!

[vorsprung]

End users will be accessing an online catalogue loaded onto a system paid for by central government, but hosted by a third party company. The same third party applies all the rules regarding the catalogue. Suppliers register on the system and can upload catalogues.

Users will log onto the system and then have access to the supplier's catalogue. There is a field in the catalogue that can contain a URL. This will link to a place on the supplier's (my customer) server.

So I assume that this URL is the price information?
There are two things you can do in this case

1) the javascript obfustication of the links
2) the URL requires "registration" of the users on "the supplier's" server before any price information is accessible