Prevent access via entering url in address bar of browser

[rwtaylor]

I only want to allow requests that originate from an application event. For example, clicking on a link in the application or submitting a form for processing.
I don't want to allow the user to just enter a url in the browser address bar after they have been authenticated.

For example, a user accesses a search page which returns a list of orders which they are authorized to view. Each order is accessed by clicking on a link which brings up the order detail. The link contains the order id which uniquely identifies the order. A malicious user could simply start entering order detail url's with different order id's. In this case, I would have to add authorization code prior to returning an order to ensure the user was authorized to view that order.

I know ACEGI offers ACL (access control list) authorization, and I know there are other ways to authorize access, but I want to try and reduce the number of authorization points I have to manage.

I know one solution would be placing a dynamic token in the url and verifying it against a token in the session. If they match, then allow access, else deny access. Struts had something like this built in to their <html:link .../> tags and the <html:form .../> tags.

The bottom line is that all events should originate from the application, otherwise they should be considered malicious.

Any ideas, references, or experiences would be appreciated.

Thanks.

[jvictor]

I am a newbie to spring, but I'd suggest to put ur jsp or view stuff under WEB-INF making it non public. I can be wrong :-)

[Colin Yates]

To make it a *little* bit more difficult, make all your controllers only accept posts instead of gets. Anything entered into the URL in a browser is sent as a post....

To be honest, I think it would be better for you to deal with the security issue instead of ignoring it This all seems very fragile and a bit nasty

[chrismay]

> Anything entered into the URL in a browser is sent as a post.

He means sent as a GET :-)

You could try and use the transactional token approach, but that's really designed to solve a slightly different problem - preventing re-submissions of form data - and it might have some unexpected side effects (for instance, if your app. has any cacheable GET requests you'll get stale tokens from proxies, if your user has 2 browser windows open they'll both refer to the same session and overwrite each other's tokens, etc).

I think yatesco is right; you need to deal with the security requirement. If you've already got code somewhere that checks whether a user has access to a given order, it shouldn't be too hard to stick it in a filter in front of the 'edit order-detail' pages (assuming order-details know their orders in your domain model) and return an HTTP 403 if they haven't got access.

[ybardavid]

YOu can also check the referrer http header, and check if the page hit came from the application or not. Very few users disable this header field in their browser

[cuong]

This is probably a bizarre idea but you could one-time encrypt the query parameter of the link with values that they will always be different even for the same item of data - a sort of SSL at the parameter level. It would be improbable that a user can change the parameter values and expect them to work.

You have the problem of an encrption and decryption algorithm tho' ...

I'd be interested in what approach you decide to use.

[Colin Yates]

Yes, I did mean GET

[Cowboy Bob]

The way I do it:-

1) I have a filter that sits in front of the app that calls into a permissions model that can be configured via XML for page level restrictions (as well as finer grained control if required)
2) JSPs are all inside WEB-INF so they cannot be viewed outside the control of Spring.

Bob

[Cowboy Bob]

YOu can also check the referrer http header, and check if the page hit came from the application or not. Very few users disable this header field in their browser

That's fairly useless IMO, since the OP is talking about malicious users. The first thing a malicious user would do is turn off the referrer header (as well as JavaScript though that's a different discussion).

Bob

[rwtaylor]

I am a newbie to spring, but I'd suggest to put ur jsp or view stuff under WEB-INF making it non public. I can be wrong :-)

I already secure my content using Container Manage Security.
I'm trying to solve a different problem.

Please re-read my post. Thank you for your suggestion though.