Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.help > #2710 > unrolled thread

Preventing Typed URLs From Being Used

Back to article view | Back to comp.lang.java.help

Contents

  Preventing Typed URLs From Being Used Steve <tinker123@gmail.com> - 2013-05-08 16:28 -0400
    Re: Preventing Typed URLs From Being Used Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-05-08 13:42 -0700
      Re: Preventing Typed URLs From Being Used Steve <tinker123@gmail.com> - 2013-05-08 16:47 -0400
        Re: Preventing Typed URLs From Being Used Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-05-09 07:58 -0700

#2710 — Preventing Typed URLs From Being Used

Hi,

My boss asked me to alter our Java Webapp such that users cannot go to 
places in our Webapp by typing URLs into their browser location bar.

I told her that I can not disable their location bars.

I told her the way this is usually done is to launch a WebApp in a new 
customized browser window sans a location bar.

That was not acceptable to her.

I already have a Java Filter class set up to enforce various rules.  So, 
I was thinking of this approach


1. Implement a system wide "writeFlagCookie" javascript function to 
write a cookie anytime a user initiates a GET by clicking on a link or a 
button.

2. Everywhere the WebApp does a redirect or a forward, put a flag 
variable, say "wasRedirected" into the HTTP session.

3. In my Filter, intercept each request and check for the request type.

4. If it is a POST, I know a human didn't type the URL into their 
browser, so I automatically let it through.

5. If it is a GET, look for a javascript generated cookie, or the flag
stored in the session to indicate a redirect or a forward.  If I find 
neither send the user back to the page they just tried to leave from.


Though it will be a lot of work, it sounds too simple to be adequate.

Is there anyway this approach can bite me in the ass?

Any other constructive thoughts?

Thanks

Steve

[toc] | [next] | [standalone]

#2711

On 5/8/13 1:28 PM, Steve wrote:
>
> Hi,
>
> My boss asked me to alter our Java Webapp such that users cannot go to
> places in our Webapp by typing URLs into their browser location bar.
This is usually an indication of either a misunderstanding of the web, 
or a misunderstanding of security.  If I were in your situation, I would 
ask what the actual problem they are trying to solve is.
> I told her that I can not disable their location bars.
In general, you can not control what the user does.  You can attempt to, 
but the end-user can do things that are disabled by the browser using 
extensions or command-line utilities, or scripts they write themselves.
>
> I told her the way this is usually done is to launch a WebApp in a new
> customized browser window sans a location bar.
>
> That was not acceptable to her.
That comes closer to solve the problem, but not entirely.  It also is a 
bad user experience to interfere with users standard uses.

> I already have a Java Filter class set up to enforce various rules.  So,
> I was thinking of this approach
>
>
> 1. Implement a system wide "writeFlagCookie" javascript function to
> write a cookie anytime a user initiates a GET by clicking on a link or a
> button.
>
> 2. Everywhere the WebApp does a redirect or a forward, put a flag
> variable, say "wasRedirected" into the HTTP session.
>
> 3. In my Filter, intercept each request and check for the request type.
>
> 4. If it is a POST, I know a human didn't type the URL into their
> browser, so I automatically let it through.
Though I could use curl to type a URL and send data. I could also update 
the URL in the form HTML.

>
> 5. If it is a GET, look for a javascript generated cookie, or the flag
> stored in the session to indicate a redirect or a forward.  If I find
> neither send the user back to the page they just tried to leave from.
What if they are doing multi-tab or multi-window browsing?

> Though it will be a lot of work, it sounds too simple to be adequate.
It is. You need to understand what the actual requirement is (breaking 
the users browser is an attempted solution, not an actual problem to be 
solved).

> Is there anyway this approach can bite me in the ass?
Yes, it solves nothing, it break tabbed browsing, and leads to other 
poor user experience.

> Any other constructive thoughts?
Find a job at a better place?

[toc] | [prev] | [next] | [standalone]

#2712

On Wednesday May 08 4:42 PM, Daniel Pitts wrote:
> Yes, it solves nothing, it break tabbed browsing, and leads to other
> poor user experience.

What other "poor user experience"(s)?

How would it break tabbed browsing?

Steve

[toc] | [prev] | [next] | [standalone]

#2713

On 5/8/13 1:47 PM, Steve wrote:
> On Wednesday May 08 4:42 PM, Daniel Pitts wrote:
>> Yes, it solves nothing, it break tabbed browsing, and leads to other
>> poor user experience.
>
> What other "poor user experience"(s)?
Well, for one thing if the user has cookies disabled, your site no 
longer works, period.

Also, bookmarks will fail.  Oh, and by the way, the user might be coming 
to your site from somewhere else.

> How would it break tabbed browsing?
Cookies being set are shared across browser tabs. If the user reloads a 
page in a different tab, then that request will have the wrong cookie 
value and be denied.


I really do suggesting digging deeper and asking *why* your boss wants 
this. After 8 years professional software development experience, I can 
almost smell the misconceptions your boss has about security.

Users *are* able to enter URLs, fake cookies, POST arbitrary data, even 
fake HTTP headers. You shouldn't even try to stop them. Just expect it. 
Most of the time, you don't care and shouldn't care.

Sometimes there is data surfaced on your site which must remain secure. 
  In those times, you should use https *and* authentication *and* 
authorization checking.

The alternative to https/authentication/authorization is an insecure 
site.  If you miss any *one* of those, your site isn't secure.

There is no ifs, ands, or buts.

(Okay, so there are other secure transports other than https, but most 
of those aren't used in browsers)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.help

csiph-web