Re: validating a referrer IP address redirect - HOW?



Toynbee <ybhattacharya@xxxxxxxxx> writes:

On Jan 12, 3:31 pm, Regis <ord...@xxxxxxxxx> wrote:
Toynbee <ybhattacha...@xxxxxxxxx> writes:
We would like to validate those users who were redirected from a
certain portal (and not from elsewhere) to our SharePoint portal. The
idea is that we wish to let users who have authenticated on certain
specific portals to be able to use a link to come and view certain
areas of our portal without having to authenticate once again (and
without us setting up Single-Sign-On etc.). All we wish to check is
whether the person accessing our portal has actually been re-directed
from the other trusted portal(s).

Why?  

And what level of trust are you willing to give them if the referrer
check matches?

I ask because the red flag of "something dreadfully foolish and
insecure is about to get implemented" is waving.

From a security perspective, you rely on referrer information alone at
your peril.  It's something that can be trivially forged.
Furthermore, from a functionality perspective, some browsers can be
configured to not send referrer information (which helps protect user
privacy to some extent) and such reliance would also break with
browsers configured thusly.

Passing a quality, random session cookie somehow, or leveraging
javascript to POST a per-user/per-session session token of some sort
would be far preferable to validating based on http referrer header
info.

If however, your referrer URL has a randomized token in it, it may be
non-dreadful (but still a problem), because we like to keep session
ID's out of URLs/ GET variables as browsers and proxies like to cache
them.  

Since this is a Bulletin Board, the stakeholders are willing to accept
just a valid referral.

Which seems like a nice/swell idea until the spammers figure it out
and the bulletin board is polluted with bot spam. It may take a
while for them to figure out the auth though, so it may be worth a
shot.

Can a "per user / per session" cookie be implemented without creating
individual accounts at the portal where the user is being trusted /
authorized to browse the bulletin board?
How exactly can this be done?

If they don't have individual accounts at the portal, and they aren't
willing to implement account signup for the bulletin board, yeah,
they're kinda screwed. The referrer auth obscurity may buy some time
though, but plans should be put in place to implement user security
and all the usual bulletin board goodies should the spam come. If
it's a custom solution, the more likely it is the obscurity will keep
spam submissions at bay for a little while until a spammer notices the
board, and determines its trivial authentication mechanism. Once that
cat's out of the bag, the board may get unusable pretty quickly.

If you're being contracted for this, you owe it to them to paint the
scenario described above, and ask them if they're willing to risk it.
You'll probably wantt o implement some fairly strong recaptcha stuff
as a prerequisite to posting if users won't be individually authed as
well.

Good luck with it!





.