FAQ Topic - How can I prevent access to a web page by using javascript? (2010-05-09)
in [JavaScript]
|
Prev: THE LAST ONLINE CASINO SECURITY LINE
Next: FAQ Topic - How can I prevent access to a web page by using javascript?(2010-05-09)
From: Garrett Smith on 15 May 2010 20:02 Dr J R Stockton wrote: > In comp.lang.javascript message <hsi2vs$3no$1(a)news.eternal- > september.org>, Thu, 13 May 2010 16:46:01, Garrett Smith > <dhtmlkitchen(a)gmail.com> posted: > >> For purpose of the FAQ entry, I have shifted the focus on javascript >> being used to restrict access to a web resource. >> > > Such a subject, for the readership that you should be aiming for, will > merely add further disguise to whatever other meaning the item may be > intended to convey. > > For a start, who is "I"? It is the hypothetical reader that appears in other entries, for example: "how do I format a Date object with javascript," "my element is named myselect[], how do I access it? A question such as you propose could easily be > asked by a browser user wishing to keep his history secret, or wanting > to prevent his parents reading anything about Brussels sprouts. > How so? -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: VK on 15 May 2010 20:51 On May 14, 3:46 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > Jonannes Baagoe and Stockton are discussing encrypting strings and using > javascript to run decrpytion algorithms. For what practical purpose? The page URL to navigate has to be in the regular format, so easy to copy-paste from the address bar or from right-click => properties. Same for XHR call => document HTML replacement, just will take an extra minute to see the algorithm. This is the unsolvable default of any purely Javascript-based protection: it may be very good, but only till the first authorization of anyone with granted access. After that the URL can be copied and shared with the whole world. > For purpose of the FAQ entry, I have shifted the focus on javascript > being used to restrict access to a web resource. > > Discussions of cryptography are interesting but seem a bit too much for > the FAQ. If anyone feels otherwise, and feels that he is qualified to > draft an entry about that (I am not), then state so and do so. I don't think that a "history of perpetuum mobile development attempts" would be suitable for FAQ. Right now http://www.jibbering.com/faq/#hideSource it says everything what there are to say on the subject.
From: Johannes Baagoe on 15 May 2010 23:00 VK : > Garrett Smith : >> Jonannes Baagoe and Stockton are discussing encrypting strings and >> using javascript to run decrpytion algorithms. > For what practical purpose? As stated in the question : to prevent access to a Web page by using javascript. > The page URL to navigate has to be in the regular format, so easy > to copy-paste from the address bar or from right-click => properties. And so what ? > Same for XHR call => document HTML replacement, just will take an extra > minute to see the algorithm. In case you missed the discussion, the page is here : http://baagoe.com/en/ES/encrypted.html Inspect the code to your heart's content, and see if you can get in. (That is, without looking up the password I published later.) > This is the unsolvable default of any purely Javascript-based > protection: it may be very good, but only till the first authorization > of anyone with granted access. After that the URL can be copied and > shared with the whole world. Which *still* does not make the page accessible, unless you know the password. All you get is a blank page with a request for the password. > I don't think that a "history of perpetuum mobile development attempts" > would be suitable for FAQ. Quite, but sometimes, something that was dismissed as a perpetuum mobile turns out to be more like Columbus's egg. > Right now http://www.jibbering.com/faq/#hideSource > it says everything what there are to say on the subject. That is a different question, and a different subject. -- Johannes
From: Ry Nohryb on 16 May 2010 05:24 On May 14, 1:51 pm, Johannes Baagoe <baa...(a)baagoe.com> wrote: > Johannes Baagoe : > > >> it is simply a matter of using a goodness-of-fit test of the > >> observed byte frequencies against the null hypothesis that the > >> distribution is uniform, which will be the case unless we have > >> found the key. Chi-square serves well and is quite fast. > > Ry Nohryb : > > > How would you write that test ? > > In the specific case involved, `decrypt` returns a String, whose > charCodeAt method returns Numbers in [0, 65535] for any i between > 0 and the length of the String minus 1. (In most other languages, > one would rather count bytes than unsigned 16-bit char codes.) > > So we initialise an Array (let us call it `counts`) of 65536 zeros, > and loop over the decrypted String counting character codes : > > for (var i = plain.length - 1; i >= 0; i--) { > counts[plain.charCodeAt(i)]++; > } > > (In real applications, this would be done incrementally, as the > decryption progresses. One may also stop before it is ended, once > a sufficiently large substring for the test has been decrypted.) > > If the count distribution is close to uniform, each count will be > approximately equal to the length divided by 65536. Let us call that > value `expected`, and calculate Pearson's chi-square statistic : > > var expected = plain.length / 65536; > var chi2 = 0; > for (var i = 0; i < 65536; i++) { > var diff = counts[i] - expected; > chi2 += diff * diff / expected; > } > > In the case of an unsuccessful decryption, the result will be > reasonably close to 65536. On successful decryption, it will be *much* > higher, say, above 70000 - the precise threshold that should ring > a bell depends on how much time you are prepared to spend in human > inspection of false positives vs. how much you want to be sure not to > miss the real solution. It also depends on the encoding, for ASCII, > you may be quite sure that all the counts above 127 will be 0, and > choose a corresponding very high test value - or a simpler test. > (A chi2 much *lower* that 65536, say, less than 60000, is either > a bug or a miracle.) > > Scrupulous minds will note that Pearson's test may not be appropriate, > if for not nothing else, then because `expected` will be less than > 5 for short plaintexts. In actual practice, it doesn't matter - > the test discriminates quite nicely, and it is faster than more > theoretically reputable ones. If I understand it correctly, you look for an irregular, non-flat distribution of frequencies. Well, it's ok, but as you know beforehand which elements should exhibit a higher than average frequency, you could as well, ISTM, look directly for that, as I did in my isHumanTxt() code snippet, don't you think so ? -- Jorge.
From: Johannes Baagoe on 16 May 2010 06:07
Ry Nohryb : > If I understand it correctly, you look for an irregular, non-flat > distribution of frequencies. Well, it's ok, but as you know beforehand > which elements should exhibit a higher than average frequency, > you could as well, ISTM, look directly for that, as I did in my > isHumanTxt() code snippet, don't you think so ? Quite, the method I posted is for the general case where we don't know what to look for, except that it is not random. Very often, one knows a lot more than that, and a simpler test like yours may be sufficient. You, on the other hand, go to the other extreme and assume it is ASCII. Lots of human texts are not. Your test would fail on Russian or Greek, mine would recognize Chinese and even cuneiform. (Not to mention that some people who use non-English alphabets might object to not being considered human.) -- Johannes |