Prev: Discount smet caps( www.nike-black.com )
Next: FAQ Topic - How do I protect my javascript code? (2010-07-10)
From: FAQ server on 8 Jul 2010 19:00
-----------------------------------------------------------------------
FAQ Topic - How can I prevent access to a web page by
using javascript?
-----------------------------------------------------------------------

In practice you can't. While you could create a suitable
encryption system with a password in the page, the level of
support you need to do this means it's always simpler to do it
server-side. Anything that "protects" a page
other than the current one is definitely flawed.


The complete comp.lang.javascript FAQ is at
http://jibbering.com/faq/

--

The sendings of these daily posts are proficiently hosted
by http://www.pair.com.

From: Evertjan. on 9 Jul 2010 02:55
FAQ server wrote on 09 jul 2010 in comp.lang.javascript:

> -----------------------------------------------------------------------
> FAQ Topic - How can I prevent access to a web page by
> using javascript?


.... using clientside javascript ...

Using password authentication in serverside javascript is easy.

The FAQ should not be so clientside specific when asking such general
questions. Adding only one word makes it acceptable.


> -----------------------------------------------------------------------
>
> In practice you can't. While you could create a suitable
> encryption system with a password in the page, the level of
> support you need to do this means it's always simpler to do it
> server-side.

"the level of support you need"

I do not thing any newcomer, and that where this FAQ is for,
will understand what the heck this means.


> Anything that "protects" a page
> other than the current one is definitely flawed.

Same 'what the heck' objection,
this FAQ-Q primarily is about the current page, I presume?

Javascript definitly can be used to inject a password in a link:

<a
href='...'
onclick =
'location.href = location.href+"?"+prompt("Password", "");'
>...

the password to be evaluated serverside.

However I do not think this should be added in this FAQ-Q.

So I suggest leaving this other page sentence out.


--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
From: Scott Sauyet on 9 Jul 2010 09:20
Evertjan wrote:
> FAQ server wrote on 09 jul 2010 in comp.lang.javascript:

>> FAQ Topic - How can I prevent access to a web page by
>> using javascript?
>
> ... using clientside javascript ...
>
> Using password authentication in serverside javascript is easy.
>
> The FAQ should not be so clientside specific when asking such general
> questions. Adding only one word makes it acceptable.

Absolutely.


>> In practice you can't. While you could create a suitable
>> encryption system with a password in the page, the level of
>> support you need to do this means it's always simpler to do it
>> server-side.
>
> "the level of support you need"
>
> I do not thing any newcomer, and that where this FAQ is for,
> will understand what the heck this means.

This should be phrased more artfully, perhaps, but the basic idea is
correct: this can be done client-side, but it's much more difficult
than doing it server-side, and there is little advantage to doing it
on the client.

When this was discussed in May, Johannes Baagoe demonstrated a clever
technique to password-protect the current page, a technique that is
not particularly arduous. But there was still little to recommend it
over server-side techniques except as a curiosity.


>> Anything that "protects" a page
>> other than the current one is definitely flawed.
>
> Same 'what the heck' objection,
> this FAQ-Q primarily is about the current page, I presume?

No necessarily.

> Javascript definitly can be used to inject a password in a link:
>
> <a href='...' onclick =
>  'location.href = location.href+"?"+prompt("Password", "");'
>
> the password to be evaluated serverside.

That's not really a technique to prevent access to a page. The
intent, I believe, is to claim that solutions like the following are
fundamentally unsound:

function myClickHandler(elt) {
var password = prompt("Enter password");
if (!validate(password)) return false;
window.location.href = deobfuscate(elt.href, password);
}

With techniques like Johannes described, a URL could be successfully
encrypted, and something like the above could certainly stop the
casual user from reaching the target page. But that page is still
available. If the URL is shared, another person could access it
directly. Even if such URLs have a one-time usage (which would
require server-side solutions anyway!) this is falling back on
security through obscurity, never a great idea.


> However I do not think this should be added in this FAQ-Q.
>
> So I suggest leaving this other page sentence out.

I disagree. I think it's important to point out.

--
Scott
From: Dr J R Stockton on 10 Jul 2010 18:40
In comp.lang.javascript message <4c36587b$0$278$14726298(a)news.sunsite.dk
>, Thu, 8 Jul 2010 23:00:03, FAQ server <javascript(a)dotinternet.be>
posted:

>FAQ Topic - How can I prevent access to a web page by
>using javascript?

Subject needs re-writing; is the desire to prevent downloading of the
page as it stands on the server, or is it to prevent the material being
readable without the password?

>In practice you can't. While you could create a suitable
>encryption system with a password in the page, the level of
>support you need to do this means it's always simpler to do it
>server-side. Anything that "protects" a page
>other than the current one is definitely flawed.


Page <URL:http://www.merlyn.demon.co.uk/$pw.htm> contains encoded
material, which will be revealed by entering the password and pressing
the button.

Display etc. is crude, but could easily be modified to hide the initial
display and show a mote typical page.

IMHO, if Garrett & others cannot post the decoded material, the FAQ
entry needs rewriting.

--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (RFCs 5536/7)
Do not Mail News to me. Before a reply, quote with ">" or "> " (RFCs 5536/7)
From: Dr J R Stockton on 14 Jul 2010 14:46
In comp.lang.javascript message <xrydnUJkttMaS6bRnZ2dnUVZ7qednZ2d(a)gigane
ws.com>, Tue, 13 Jul 2010 04:59:19, Stefan Weiss <krewecherl(a)gmail.com>
posted:

>On 12/07/10 21:11, Dr J R Stockton wrote:
>> Non-professionals, however, may or may not have access to code server-
>> side; for those who need to do it, and cannot do it server-side, there
>> is distinct advantage to doing it client-side.
>...
>> Has anyone yet managed to read, client-side, the message in page
>> <URL:http://www.merlyn.demon.co.uk/$pw.htm> without knowing the
>> password?
>
>That's a very poor algorithm, even for non-professional use.

Agreed; I should have said that the actual encoding is crude. I wanted
something that would both decode and encode, out of laziness and maybe
lateness. One could easily do better; but that is enough to show that
information can be hidden from those without the password.

There is a greater problem with the encoding; it is browser-dependent,
as I have just found. I used Firefox 3.0.19; it differs in Opera 10.10.



> There was a young man named Z.........
> who ...
>
>which gives us some known plain text to work with. A sufficiently
>motivated attacker (which I am not) could probably decypher this in a
>very short time.
>
>That's assuming that your password is not completely random and shorter
>than the cyphertext...

Agreed. But even a weak defence is of use for a text of little value.

I did think of using Donaudampfschiffahrtsgesellschaft as the password,
but could not remember it adequately. The actual password is a bit
shorter, but bears little resemblance to Evertjans' suggestion.


I'm surprised that Evertjan did not think of the Z......... word.

--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.
 |  Next  |  Last
Pages: 1 2
Prev: Discount smet caps( www.nike-black.com )
Next: FAQ Topic - How do I protect my javascript code? (2010-07-10)