[Javascript] Approved method of "bugging out"

[Mike Dougherty]

We inherited a goofy (but effective) mechanism for securing a page:

The javascript hashes the password for the page, then uses that hash key
to parse an encoded string - the result of which is the redirection
location.  Only by supplying the correct password will the correct hash
key be computed, and the encoded string is meaningless without the
correct hash key.  One downside is that there can only be one password
per page (unless you really want to extend the algorithm to check
multiple keys)

I agree with Chris: server-side authentication is a more secure
approach.  You might be able to create an access token cookie with
client-side javascript - then require the 'secure' pages to validate the
token in the cookie.  But again, it'll turn into a complex issue very
quickly.

-----Original Message-----
From: javascript-bounces at LaTech.edu
[mailto:javascript-bounces at LaTech.edu] On Behalf Of Chris Tifer
Sent: Tuesday, August 05, 2003 7:33 AM
To: [JavaScript List]
Subject: Re: [Javascript] Approved method of "bugging out"


It would be much better to handle authentication on the server-side
since the user could just as easily disable javascript to bypass this
'security
measure'.

Chris Tifer

----- Original Message ----- 
From: "David T. Lovering" <dlovering at gazos.com>
To: "[JavaScript List]" <javascript at LaTech.edu>
Sent: Sunday, August 03, 2003 9:37 AM
Subject: [Javascript] Approved method of "bugging out"


>
>   I am trying to harden a number of pre-existing pages by embedding a
script in the onLoad handler (or maybe even earlier in the process tree)
that will check the authentication info for the incoming user, and then
unconditionally blow the window/browser
> back out if the authorization is not validated.  The first part is
easy,
and I've already got a handle on it.
>
>   The second part appears to be more troublesome, particularly with IE
browsers.  I've tried "self.window.close()" and a number of close
analogs,
and in every case it brings up a nice little window saying "the process
wants to close the window, is this
> OK?"  Of course, a cracker will say "no", and continue happily raping
the
application.  I
> want the equivalent of dynamite for the fishpond, that will abort the
browser altogether without any dialogue, thereby ensuring that no
passive
authentication threads remain active and that no history can lead back
to
the page(s) in question.
>
>   Yes, I know how to nuke the history list.  However, I don't like to
do
this out-of-hand, since the user may have legitimate URLs stacked up in
it
which should be preserved.  Also, I can simply redirect the
window.location.href to somewhere innocuous,
> but that still leaves the initial authentication thread active, and
can be
"backed" by the history list.  No, only unconditional dynamite will
serve.
>
>   Anybody have any ideas?  I need to get this script bundle out the
door
ASAP for a product demo at the end of this upcoming week.
>
> -- Dave Lovering
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript

_______________________________________________
Javascript mailing list
Javascript at LaTech.edu
https://lists.LaTech.edu/mailman/listinfo/javascript