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: VK on 16 May 2010 07:33 On May 16, 3:06 pm, VK <schools_r...(a)yahoo.com> wrote: > I trust you that you play fairly and that it's a purely client-side > Javascript solution, so using only static Javascript code and > (possibly) any amount of static client-side data files. > If it's so, then the rest is easy. Again: ask comp.lang.java.security, > they had zillions of key+decoder-noKeyExchange solutions, yours is not > the most obfuscated one from what I saw. As a side note: never use "application/ecmascript" for your scripts. It is not recognized by IE of any version, so the whole script part will be ignored, just like for scripting disabled - as it is right now. Use type="text/javascript" only or (obsolete but more logical) language="JavaScript". Also the form has to be brought into some more conventional way: <form action="" onsubmit="return show(this.pass.value)"> <!-- with show() either making rewrite or returning false --> Please enter the password: <input name="pass" type="password"> </form> With these two defaults fixed - especially the first one - I'll ask my worker at Monday what is wrong in this particular approach. I am playing fairly - no password will be looked for anywhere in advance.
From: Johannes Baagoe on 16 May 2010 07:35 VK : > Johannes Baagoe : >> VK : >>> yet another "bulletproof" encryption with both key and decoding >>> in one block of code. >> [...] >>> Same for secure solutions of key and description algorithm being in >>> the same execution block. I don't know exactly where it is wrong, >>> I just know that it is wrong. >> What makes you assume that the key is anywhere in the code ? > I trust you that you play fairly and that it's a purely client-side > Javascript solution, so using only static Javascript code and > (possibly) any amount of static client-side data files. Quite. > If it's so, then the rest is easy. Again: ask comp.lang.java.security, The question was "How can I prevent access to a web page by using javascript?". That one can use AES in Java to decrypt a Web page is no surprise. > they had zillions of key+decoder-noKeyExchange solutions, yours is > not the most obfuscated one from what I saw. It does not attempt to be obfuscated at all, on the contrary. But it is not a "key+decoder-noKeyExchange" solution. The key has to be exchanged by some other means, by hand or over a secure line. Exactly like a password for server-side access control. You are assuming much too much. Try reading instead, for a change. This is not an attempt of security by obscurity. I wouldn't dream of proposing yet another attempt, I am quite familiar with Kerckhoffs's principle. What I propose is a simple application of classic, symmetrical cryptography using a reputable algorithm (AES). Not "personal research". (And of course, no obfuscated key.) -- Johannes
From: Johannes Baagoe on 16 May 2010 08:07 VK : > As a side note: never use "application/ecmascript" for your scripts. It > is not recognized by IE of any version, so the whole script part will be > ignored, just like for scripting disabled - as it is right now. That is nice to know - a much simpler way to prevent unwanted access to my pages :) > Use type="text/javascript" only I shall bear it in mind if and when I intend to accommodate non-conforming browsers. > or (obsolete but more logical) language="JavaScript". language = cdata [CI] Deprecated. This attribute specifies the scripting language of the contents of this element. Its value is an identifier for the language, but since these identifiers are not standard, this attribute has been deprecated in favor of type. > Also the form has to be brought into some more conventional way: There is no form, just an INPUT element. Which, being a %formctrl; and therefore an %inline; is perfectly legal in a P element. > With these two defaults fixed - especially the first one - I'll ask my > worker at Monday what is wrong in this particular approach. I am playing > fairly - no password will be looked for anywhere in advance. Nothing is wrong. Wanna bet ? :) -- Johannes
From: VK on 16 May 2010 08:48 On May 16, 4:07 pm, Johannes Baagoe <baa...(a)baagoe.com> wrote: > VK : > > As a side note: never use "application/ecmascript" for your scripts. It > > is not recognized by IE of any version, so the whole script part will be > > ignored, just like for scripting disabled - as it is right now. > > That is nice to know - a much simpler way to prevent unwanted access > to my pages :) > > > Use type="text/javascript" only > > I shall bear it in mind if and when I intend to accommodate non-conforming > browsers. Other words if ever decide to accommodate your solutions for more that 40%-45% of your Web visitors... I don't think it's a suitable approach for c.l.j. Browser-specific tech forums in their intranet sections are definitely the choice to post such solutions. > > or (obsolete but more logical) language="JavaScript". > > language = cdata [CI] > > Deprecated. This attribute specifies the scripting language of the > contents of this element. Its value is an identifier for the language, > but since these identifiers are not standard, this attribute has been > deprecated in favor of type. Yes, I know - and I didn't tell you that you *had* to use it. Just bear in mind that W3C opinions on anything as of the year 2010 are negligible. One day I may tell you the whole story of that "standard" type attribute and that "standard" text/javascript value. It is interesting and funny. Yet again fill free to use type="text/ javascript" > > Also the form has to be brought into some more conventional way: > > There is no form, just an INPUT element. Which, being a %formctrl; > and therefore an %inline; is perfectly legal in a P element. Irrelevant to me. I am the service customer you are benefiting from: either by having your code QA'ed or by having my proven wrong and stupid. You are the service provider - and in order to get "paid" you gonna do what I want, and if I don't give a damn if the original coding is allowed or not - you'll have to do the same. Or no contract. :-) Pretty much like with Firefox guys and Bank of America director back in 2006: they were singing for an hour of how autocomplete attribute for text fields breaks standards, W3C's "Web full potential", personal karmas etc. At the time limit end the BoA representative simply said: "Thank you for all this interesting information. By this Friday Firefox has to have autocomplete implemented exactly as it is in IE. If yes, at Monday we are signing the contract. If not, at Monday we are signing the contract with Microsoft. Thank you for your time." That was the first really harsh lesson of the real life Mozilla had to learn and I really enjoyed their faces at the moment... Also guess: was autocomplete implemented as requested by that Friday or not? Check it out ;-) > Nothing is wrong. Wanna bet ? :) Do what your customer want first - without questioning his sanity, intellectual level, professionalism and by keeping friendly smiling. When will talk about the payment. :-) :-|
From: Johannes Baagoe on 16 May 2010 10:44
VK : > Johannes Baagoe : >> VK : >>> Use type="text/javascript" only >> I shall bear it in mind if and when I intend to accommodate >> non-conforming browsers. > Other words if ever decide to accommodate your solutions for more > that 40%-45% of your Web visitors... I cannot imagine a visitor who has no standard-conforming browser and who would still be interested in anything I have to say. > I don't think it's a suitable approach for c.l.j. Browser-specific > tech forums in their intranet sections are definitely the choice to > post such solutions. I would argue exactly the contrary: comp.lang.javascript is about the computer language javascript, which has nothing at all to do at with browser-scripting except for a historical accident. Questions about workarounds for buggy browsers should be discussed in the appropriate vendors' forums. (Or, at the very least, be appropriately tagged in the subject line.) > I am the service customer you are benefiting from: either by having > your code QA'ed or by having my proven wrong and stupid. You are the > service provider - and in order to get "paid" you gonna do what I > want, and if I don't give a damn if the original coding is allowed > or not - you'll have to do the same. Or no contract. :-) If anything, it is the other way round - you offer a quality control service I might be interested in. If serious, you should take the job as it is, without demanding arbitrary alterations to suit your habits. Just as I would if you decided to hire me as consultant. But no contract. My opinion about your competence in cryptology was made the moment you posted your nonsense about Shannon's Clairvoyant. On the other hand, *you* asserted repeatedly that something is impossible. Everybody who took the trouble to actually check came to the opposite conclusion. The reflex of declaring it impossible (which I shared, too, before Stockton first, and then Jorge made me rethink) comes from considering only the terrible solutions that are implicitly, but not explicitly, assumed in the FAQ, viz. obfuscating a password. My solution does nothing of the kind. I have now explained that three times. If you still do not want to check and take the last chance of a graceful retreat, I shall not additionally rewrite my page according to your whims to make you do so. After all, the way you manage your reputation is your own concern. -- Johannes |