URLs

M

Mark Rae

Hi,

I've been asked to write an ASP.NET app which uses traditional hyperlinks
with querystrings for navigation e.g.
http://<site>/customers/customer.aspx?id=123

The client wants the querystrings to be encrypted, sort of like Amazon.com
does. That's fine - no problem there.

However, the client now asks if there is any way of detecting whether the
user has typed the encrypted URLs directly into their browser rather than
navigate to them through the hyperlinks on the site.

I can't use HTTP_REFERER or anything like that because the client's firewall
software (Norton Internet Security) strips those types of headers off.

Any assistance gratefully received.

Mark Rae
 
P

Peter Morris [Droopy eyes software]

What about each link on your page having a guid instead of an id? The true
ID could be stored in Cache[] and set to expire in 5 minutes. That way the
referring page would not have the real ID, and the destination page could
check that the Cache[] item exists before displaying.

Probably a crap idea, but it was at least an idea :)



--
Pete
====
ECO Modeler, Audio compression components, DIB graphics controls,
FastStrings
http://www.droopyeyes.com

Read or write articles on just about anything
http://www.HowToDoThings.com

My blog
http://blogs.slcdug.org/petermorris/
 
M

MWells

If you goals are simply;

+ To support Url-based state (i.e. no session state dependencies), but
+ To prevent normal users from jumping straight to a page

One possibility is;

+ Create a frameset with one 100% by 100% frame, which contains your normal
site
+ Add some js to your regular site pages that check for the existance of
the frame

This basically hides navigational hyperlinks from the user (they only see
the entry page link in the browser's url bar). If the user does a view
source and gets the page Url, or does a rt-click add to favorites, they
still won't be able to execute the Url directly without the frame.

Fairly easy for a techie to circumvent but it requires more technical
knowledge than your average user possesses. At least it offers a mild
deterrent.

You could also do more complex things like;

+ /index.aspx - the site entry page. Creates a GUID, stores it in a
session var, redirects user to /home.aspx
+ /home.aspx - the site home page. A frameset, but which retrieves the
GUID from the session var and stores it in a js-accessible location
(possibly a public var to the page, or in a js function, or as a custom
attribute to <BODY>, etc.)
+ /??? - internal site pages, the ones you're "protecting" from direct
access. Normal ASPX pages, but they include a .NET-rendered js chunk that
compares the session var GUID to the GUID in the frame. If they don't
match, or there's no frame, redirect back to /index.aspx. You could, no
doubt, implement this as a drop-in control.

You could further private-key-sign the GUID that's rendered in the frame,
and on test, verify the signature to ensure the GUID was issued by the
server. Silly, probably overkill, but I'm just throwing ideas at the
markerboard to see what sticks for you.

All the best,

/// M
 
M

Mark Rae

If you goals are simply;

+ To support Url-based state (i.e. no session state dependencies), but
+ To prevent normal users from jumping straight to a page
Click to expand...

That's precisely it.
but I'm just throwing ideas at the
markerboard to see what sticks for you.
Click to expand...

Some interesting suggestions - thanks very much.
 
M

MWells

There is another, possible cleaner approach to this problem;

Write a custom control which we'll call AuthorizedHyperlink. Functionally,
you design it so that it behaves like a combination of a LinkButton and a
Hyperlink control. It renders just like a LinkButton, complete with
postback and onclick; but it also has the attribute NavigateUrl. You design
to behave as follows;

+ Someone clicks the link
+ You get a postback event (onclick)
+ You generate a GUID (using System.Guid.ToString()).
+ You store this in a session var called, e.g. "AuthorizedHyperlink".
+ You do a Response.Redirect to the NavigateUrl with an added querystring
param, e.g. "&Auth=(the guid string)"
+ In the receiving page, you compare the Auth querystring param with the
session var, and if they're different, you boot the user to an error page.
You also boot them if the session var is null, or the Auth querystring is
null/blank.

The test can be implemented as a separate static method that takes the
HttpContext; from there you can get to the session vars and the Request
querystring components, which makes the test simple.

This is nice because it lets you keep normal Urls, etc, avoid frames, etc,
but also guarantees that the user can't view a page unless they were
intentionally directed there from another page in the same app.

/// M
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Asp.net Important Topics. 0
comp.lang.c Answers to Frequently Asked Questions (FAQ List) 15
comp.lang.c Answers to Frequently Asked Questions (FAQ List) 1

Members online

No members online now.
Total: 25 (members: 1, guests: 24)
Robots: 206

Forum statistics

Threads
473,773
Messages
2,569,594
Members
45,123
Latest member
Layne6498

Latest Threads

Top