JavaScript in Password Protected Folder?

[xmp333]

Hi All,


I am trying to hide my JavaScript source. The method I chose was to
keep all the important source in a password protected folder, and then
use a SRC="folder/script.js" to include it in my code. This way, the
script will run, but the user will be unable to view the included
code. Or so I think .

I have tried this method, and it seems to work. However, I would like
to know if you can see any problems with this. For instance, can you
think of a way to bypass this and get at script.js? Can you foresee
any problems that would arise as a result of keeping scripts behind
password protected folders? Any other security concerns?


Thanks in advance.

 

[Richard Cornford]

I am trying to hide my JavaScript source.
Why?

The method I chose was to keep all the important source in
a password protected folder, and then use a SRC="folder/script.js"
to include it in my code. This way, the script will run, but
the user will be unable to view the included code.
Or so I think .

You are wrong.

I have tried this method, and it seems to work.

Anyone who knows enough about javascript to be able to do anything
useful with the source will probably know several ways of viewing the
source once they have access to the page that imports it.

However, I would like to know if you can see any problems
with this. For instance, can you think of a way to bypass
this and get at script.js? Can you foresee any problems
that would arise as a result of keeping scripts behind
password protected folders? Any other security concerns?

It isn't going to work. You can restrict access to the page but once
someone has access they can read the source code, because you will be
sending them the source code.

Richard.

 

[Guido Wesdorp]

I am trying to hide my JavaScript source. The method I chose was to
keep all the important source in a password protected folder, and then
use a SRC="folder/script.js" to include it in my code. This way, the
script will run, but the user will be unable to view the included
code. Or so I think .

It would surprise me if a client's browser can load the script without
having to log in, if so that's a security bug in your webserver. Also
this will *never* hide your scripts, as soon as the browser loads them
they're available either in the cache (read: on disk somewhere) or just
by viewing them in your browser. It's not possible to hide JavaScript
source code.

Cheers,

Guido

 

[Randy Webb]

Hi All,


I am trying to hide my JavaScript source. The method I chose was to
keep all the important source in a password protected folder, and then
use a SRC="folder/script.js" to include it in my code. This way, the
script will run, but the user will be unable to view the included
code. Or so I think .

I have tried this method, and it seems to work. However, I would like
to know if you can see any problems with this. For instance, can you
think of a way to bypass this and get at script.js? Can you foresee
any problems that would arise as a result of keeping scripts behind
password protected folders? Any other security concerns?

Open your page in IE.
File>Save As and save it.
Theres the .js file, in a folder all of its own.

 

[Richard Cornford]

[top posting fixed]

(e-mail address removed) wrote:

<snip>

JavaScript is a client side script, ...

<snip>

Pleas do not top-post to comp.lang.javascript. The group FAQ outlines
acceptable posting style in section 2.3 paragraph 5 and references the
applicable standard.

Your posting software appears to exhibiting faulty behaviour in its
handling of the "References" header in your postings. It has sent (split
across lines at the location of spaces to avoid uncontrolled wrapping):-

References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>

But:-

| RFC 1036 Standard for USENET Messages December 1987
|
|
| 2.2.5. References
|
| This field lists the Message-ID's of any messages prompting the
| submission of this message. It is required for all follow-up
| messages, and forbidden when a new subject is raised.
| Implementations should provide a follow-up command, which allows a
| user to post a follow-up message. This command should generate a
| "Subject" line which is the same as the original message, except
| that if the original subject does not begin with "Re:" or "re:", the
| four characters "Re:" are inserted before the subject. If there is
| no "References" line on the original header, the "References" line
| should contain the Message-ID of the original message (including the
| angle brackets). If the original message does have a "References"
| line, the follow-up message should have a "References" line
| containing the text of the original "References" line, a blank, and
| the Message-ID of the original message.
|
| The purpose of the "References" header is to allow messages to be
| grouped into conversations by the user interface program. This
| allows conversations within a newsgroup to be kept together, and
| potentially users might shut off entire conversations without
| unsubscribing to a newsgroup. User interfaces need not make use of
| this header, but all automatically generated follow-ups should
| generate the "References" line for the benefit of systems that do
| use it, and manually generated follow-ups (e.g., typed in well after
| the original message has been printed by the machine) should be
| encouraged to include them as well.
|
| It is permissible to not include the entire previous "References"
| line if it is too long. An attempt should be made to include a
| reasonable number of backwards references.

- would require that the References header of a message that appears,
from the quoted material and its attribution, to be intended as a
response to the OP should carry the header:-

References: <[email protected]>

And if intended to be a response to any of the other contributors to
date would be only the References header from that "original message"
(singular) followed with a space and the message ID of that message.

While the header that you sent contains the message IDs of all of the
contributions to the thread to date and will probably give most
newsreader software the impression that it is Randy that you are
responding to (or just confuse it). It is important for newsreader
software to be able to accurately represent which messages are replying
to which other messages and they need meaningful References headers in
order to be able to do that. Hence the clearly specified format and
contents of that header and the fact that it is required in messages
that represent responses.

If you are going to post to Usenet, in addition to making yourself
familiar with the conventions of the groups that you are posting to, it
would be a very good idea to be using software that does not violate
such an important aspect of the applicable standard.

Richard.

 

[Randy Webb]

JavaScript is a client side script

But that is not all its limited to. Before one posts as horribly as you
did, you should read the FAQ, about 8 times or so, and then read it 88
more times.

 

[Randy Webb]

While the header that you sent contains the message IDs of all of the
contributions to the thread to date and will probably give most
newsreader software the impression that it is Randy that you are
responding to (or just confuse it).

It confused mine. My reply to Stan is showing as a reply to you, when it
was actually a reply to Stan (I read/replied to his before I read yours).

 

[Richard Cornford]

It confused mine. My reply to Stan is showing as a reply to you,
when it was actually a reply to Stan (I read/replied to his before
I read yours).

I can't tell how the threading is going to come out on my newsreader yet
as I can see both of your replies (as responses to stanD) but my post
hasn't shown up yet. It appears to have made it across the Atlantic but
hasn't yet managed to propagate across the room at my ISP from the
receiving box to the reporting box (or could they be on different
continents?).

On the plus side both of our newsreaders have followed RFC 1036 to the
letter. (I assume you noticed the organisation originating this latest
nonsense; another great contribution to the Usenet community.)

Richard.

 

[xmp333]

Why?

Because the organization wishes to protect its source code, since it
is proprietary and may reveal internal details that we prefer to keep
secret.



Thanks.

 

[xmp333]

Hi All,


Thanks for the rapid and definitive responses. It looks like I cannot
use JavaScript for any proprietary coding (only things that I don't
mind being open source).

This helps with making decisions about this project.


Thanks again!

 

[Brian Genisio]

Hi All,


Thanks for the rapid and definitive responses. It looks like I cannot
use JavaScript for any proprietary coding (only things that I don't
mind being open source).

This helps with making decisions about this project.


Thanks again!

Well, you are correct, and incorrect. You do not have to make your
JavaScript code open source... you simply have no method for hiding your
code... this is true. Open Source means something different than making
your code publically readable. You can put strinct copyrights in your
code, making it obvious that it is illegal to use your code in any
way... that is about all you can do.

There is one hotly contested method, called something like obfuscation,
where you run the code through a program that will mangle all of the
variables, and remove white-space, making it harder to read.

While this is a method for making it harder for someone to read your
code, it in no way hides it. If someone wants to put effort forward,
they can still read the code... it is just more difficult to do.

If you need to hide your code, you might consider Java, or server-side
scripting. In both cases, the user never has access to your source code.

Brian

 

[Randy Webb]

<snip>


On the plus side both of our newsreaders have followed RFC 1036 to the
letter. (I assume you noticed the organisation originating this latest
nonsense; another great contribution to the Usenet community.)

Actually, I hadn't paid attention to it until you mentioned it. But
knowing that, they also stopped adding the generated signature lines to
there posted posts.

It won't slip by me again though

I have to figure out how to make Mozilla quote the way I want it to and
show more than "so and so wrote" :-(

Ahh, the joys of learning

 

[xmp333]

[My Misuse of the Term "Open Source"]

Well, you are correct, and incorrect. You do not have to make your
JavaScript code open source... you simply have no method for hiding your
code... this is true. Open Source means something different than making
your code publically readable. You can put strinct copyrights in your
code, making it obvious that it is illegal to use your code in any
way... that is about all you can do.

True, I should have been more careful with my language. Thanks for
the correction.

There is one hotly contested method, called something like obfuscation,
where you run the code through a program that will mangle all of the
variables, and remove white-space, making it harder to read.

While this is a method for making it harder for someone to read your
code, it in no way hides it. If someone wants to put effort forward,
they can still read the code... it is just more difficult to do.

I read about that, but it wasn't enough protection for my tastes, I
think I encountered a few pages like that as a matter of fact. I gave
up on them because I figured I could find other pages that were
properly formatted, but had I wanted to, I could have figured out the
contents. Normally, I wouldn't think of hiding source since I would
like people to be able to examine my work and (hopefully) learn from
it, as I have done with other pages. However, since this is
intellectual property for my employer the situation is much different.

If you need to hide your code, you might consider Java, or server-side
scripting. In both cases, the user never has access to your source code.

I have used server side scripting, and while it's the safest "platform
independent" technique, it is also lacking in interactivity and
responsiveness.

Java is the only other possibility that I can see, but I have no idea
of its future -- especially on the Windows platform. Furthermore,
since this application is targeted towards end users, I don't want
people to have to go through any hassle to run it -- and this includes
installing additional components.

Oh well, if it weren't a challenge, it wouldn't be fun

Brian

Thanks.

 

[Richard Cornford]

Because the organization wishes to protect its source code,
since it is proprietary and may reveal internal details that
we prefer to keep secret.

Client-side code (including Java, which may be decompiled) should
not contain internal details that can be exploited. You don't keep
secrets by distributing them to people you can't trust to keep
them for you.

Richard.

 

[xmp333]

Because the organization wishes to protect its source code,

Client-side code (including Java, which may be decompiled) should
not contain internal details that can be exploited. You don't keep
secrets by distributing them to people you can't trust to keep
them for you.

Well, the secrets aren't critical, so a "moderate" level of protection
is enough for us. Sure, they can decompile, but that would require a
lot of effort (and knowledge) on their part. It isn't a casual effort
like browsing JavaScript source. Also, if you are going to go through
that level of effort, there has to be a motivation. Casual browsing
can be done without serious motivation. All this leads to a "good
enough" level of protection.

Also, the issue isn't trust. As a matter of course, anything intended
for commercial use is to be regarded as intellectual property and kept
secret. This includes source code, and since there's no way (that I
know of) to conveniently distribute a program without opening up the
possibility of decompilation, then compilation is the best way of
doing it.

Lastly, the intended audience is the general public, or at least
certain members thereof. This is basically a "shrink-wrapped"
application, and as such, we don't have things like NDAs, etc...

Richard.

Thanks.

 

[Thomas 'PointedEars' Lahn]

[top posting fixed]

(e-mail address removed) wrote:

<snip>
news:[email protected]...

By all means, please shorten your attribution(s).

<snip>

Pleas do not top-post to comp.lang.javascript. The group FAQ outlines
acceptable posting style in section 2.3 paragraph 5 and references the
applicable standard.

Full ACK

Your posting software appears to exhibiting faulty behaviour in its
handling of the "References" header in your postings.
Nonsense.

It has sent (split across lines at the location of spaces to avoid
uncontrolled wrapping):-

References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>

This is perfectly OK according to the standards. RFC 1036 (which is
BTW not even on the Standards Track) is an extension to RFC 822, and
later RFC 2822 (which is on the Standards Track). It does not
redefine the format of header lines, neither does the part of the RFC
you have quoted. *Your* news client software is simply incapable and
it is *your* software which disobeys the standards also in this regard.

WFM. Mozilla Thunderbird 0.5+ (20040220).

You should get a working client or workaround this bug with
additional software. See <http://insideoe.tomsterdam.com/>


HTH

PointedEars

 

[Richard Cornford]

Richard Cornford wrote:

This is perfectly OK according to the standards. RFC 1036 (which is
BTW not even on the Standards Track) is an extension to RFC 822, and
later RFC 2822 (which is on the Standards Track). It does not
redefine the format of header lines, neither does the part of the RFC
you have quoted. *Your* news client software is simply incapable and
it is *your* software which disobeys the standards also in this
regard.

<snip>

If you don't believe that RFC 1036 (Standard for Interchange of USENET
Messages) is applicable to Usenet posts how about:-

| RFC 977 Network News Transfer Protocol February 1986
|
| 1.4. A Central News Server
| ...
| NNTP is modelled upon the news article specifications in RFC 850,
| which describes the USENET news system. However, NNTP makes few
| demands upon the structure, content, or storage of news articles,
| and thus we believe it easily can be adapted to other non-USENET
| news systems.
| ...
| 3.10.1. POST
| ...
| If posting is permitted, the article should be presented in the
| format specified by RFC850, and should include all required
| header lines. ...
| ...

- which is a standards track document and directly employs:-

| RFC 850 Standard for Interchange of USENET Messages June 1983
|
| 2.2.6 References This field lists the message ID's of
| any articles prompting the submission of this article. It
| is required for all follow-up articles, and forbidden when
| a new subject is raised. Implementations should provide a
| follow-up command, which allows a user to post a follow-up
| article. This command should generate a Subject line
| which is the same as the original article, except that if
| the original subject does not begin with "Re: " or "re: ",
| the four characters "Re: " are inserted before the
| subject. If there is no References line on the original
| header, the References line should contain the message ID
| of the original article (including the angle brackets).
| If the original article does have a References line, the
| followup article should have a References line containing
| the text of the original References line, a blank, and the
| message ID of the original article.
| ...

- which RFC 1036 updates an replaces (without any change to the
definition of the References header).

But even then:-

| RFC 2822 Internet Message Format April 2001
|
| 3.6.4. Identification fields
| ...
| The "References:" field will contain the contents of the parent's
| "References:" field (if any) followed by the contents of the parent's
| "Message-ID:" field (if any). If the parent message does not contain
| a "References:" field but does have an "In-Reply-To:" field
| containing a single message identifier, then the "References:" field
| will contain the contents of the parent's "In-Reply-To:" field
| followed by the contents of the parent's "Message-ID:" field (if
| any). If the parent has none of the "References:", "In-Reply-To:",
| or "Message-ID:" fields, then the new message will have no
| "References:" field.
| ...

The only pertinent differences between RFC 2822 and 850/1036 (and
thus, by implication 977) is in providing more detail of what
should happen if the message responded to does not have References,
Message-ID and/or In-Reply-To fields. The References header in the
message I was responding to still couldn't be validly constructed
in response to any of the preceding messages in this thread. That
is, it is impossible to take the References header (or the lack of
it in the original post) and append the Message-ID field to come
up with the References field in that response.

You should get a working client or workaround this bug with
additional software. See <http://insideoe.tomsterdam.com/>

What bug? My software didn't build the References header in the
message I was responding to, and it did a fairly reasonable job of
interpreting information that was incorrect to start with.

Richard.

 

[Thomas 'PointedEars' Lahn]

<snip>

If you don't believe that RFC 1036 (Standard for Interchange of USENET
Messages) is applicable to Usenet posts

I have never stated that. But you have, again, nothing quoted that
states that wrapped References are not OK according to any standard.

[...]

You should get a working client or workaround this bug with
additional software. See <http://insideoe.tomsterdam.com/>

What bug? My software didn't build the References header in the
message I was responding to, and it did a fairly reasonable job of
interpreting information

No, it did not, it failed.

that was incorrect to start with.

It was not incorrect.


PointedEars

 

[Richard Cornford]

I have never stated that.

You stated that the header I quoted was "perfectly OK according
to the standards" when it is structurally incorrect according
to RFC 1036, which implied that you didn't believe that
RFC 1036 was a standard that should be applied to a Usenet post.

But you have, again, nothing quoted that states that
wrapped References are not OK according to any standard.

Why would I want to quote anything that stated that wrapped
References headers are not OK? That would have no baring on
the number and sequence of message IDs in the References
header that I was criticising.

You didn't by any chance not bother to read what I had
written (twice) and instead jump to an irrelevant conclusion
based on some preconception that you have? If you are going
to do that and then post statements like "Nonsense" based on
your irrelevant preconception the least you could do is go
on to state why you think something is nonsense so that it
would be clear that that you are thinking about something
unrelated and irrelevant.

No, it did not, it failed.

No it didn't, it associated the message with the message
baring the Message-ID that appeared last in the sequence of
message IDs in the References header. One of three equally
reasonable responses based on the data provided, but probably
the most common response by newsreaders as that would
normally be the ID of the message being responded to.

It was not incorrect.

It is not possible to employ the procedure for building a
References header described in RFCs 850, 1036 and/or 2822
and come up with the References header that I was
commenting on. In context no References header could be built
with more than two message IDs and in a reply to the OP that
header should only contain one message ID, while the header
in question has 4. That is objectively incorrect and if you
had bothered to read what I said you would not have wasted
your time making irrelevant comments, my time responding to
those and everyone else's time reading a reiteration of an
argument that was correct to start with.

Richard.

 

[Thomas 'PointedEars' Lahn]

You stated that the header I quoted was "perfectly OK according to
the standards" when it is structurally incorrect according to RFC
1036, which implied that you didn't believe that RFC 1036 was a
standard that should be applied to a Usenet post.

Misunderstanding. I always referred to the
formatting, not the structure. See below.

But you have, again, nothing quoted that states that wrapped
References are not OK according to any standard.

Why would I want to quote anything that stated that wrapped
References headers are not OK? That would have no baring on
the number and sequence of message IDs in the References
header that I was criticising.

You didn't by any chance not bother to read what I had written
(twice) [...]

Oh, in fact I *did*. But sorry, you've lost me. Let us recapitulate:

We have an OP:

| From: (e-mail address removed)
| Message-ID: <[email protected]>
(no References header)

According to the quotes, beside others, it was replied to with

| From: Randy Webb <[email protected]>
| Message-ID: <[email protected]>
| References: <[email protected]>

and

| From: "Richard Cornford" <[email protected]>
| Message-ID: <[email protected]>
| References: <[email protected]>

and

| From: StanD <[email protected]>
| Message-ID: <[email protected]>
| References: <[email protected]>
| <[email protected]>
| <[email protected]>
| <[email protected]>
(no word-wrap!)

which you replied to with

| From: "Richard Cornford" <[email protected]>
| Message-ID: <[email protected]>
| References: <[email protected]>
| <[email protected]>
| <[email protected]>
| <[email protected]>
| <[email protected]>
(no word-wrap either)

In the above posting, you stated that

| [StanD's] posting software appears to exhibiting faulty behaviour in
| its handling of the "References" header in [StanD's] postings.

which I have come to recognize as truth, and

| It has sent (split across lines at the location of spaces to avoid
| uncontrolled wrapping):-

which is wrong anyway. Now, on closer inspection, I fail to observe
wrapped References here, so it is likely that your news client software
does this by default (which is perfectly OK, nevertheless it makes the
above statement wrong). See also Google Groups where there is no
wrapping either:

http://groups.google.com/[email protected]&output=gplain

(But that is only for the records.)

| References: <[email protected]>
| <[email protected]>
| <[email protected]>
| <[email protected]>

And then you cited from the RFC (I think I already know pretty well).
So I, indeed, falsely assumed that with the RFC quote and your trailing
comments you only try to prove that it is not standards-compliant to
wrap References. Alas, I overlooked that you also wrote:

| And if intended to be a response to any of the other contributors to
| date would be only the References header from that "original message"
| (singular) followed with a space and the message ID of that message.

(please note that English is not my native tongue) and thus I correctly
argued (but there was nothing to argue for in this context, since there
was in fact no dissent about it) that wrapped References are in fact
standards-compliant. *I am sorry, my bad.*

So let us be this a draw, OK? If you would have argued more exactly for
what you were trying to prove (and, ex post facto, not assumed that your
client software leaves the References formatting unchanged) and if I
would have taken more care in reading your postings (and, ex post facto,
all headers involved), this misunderstanding would most certainly not
have arised in the first place.

JFTR: The References header quoted above is in fact incorrect, but
not for its wrapped M-IDs (formatting) but for its wrong order and
occurrences of M-IDs (structure). The web interface used for posting
(www.Forum4designers.com gateway) is malfunctioning, I think neither
of our news client software is in this regard. (But note that my
software nevertheless displayed the forum4designers.com posting as
followup to the OP, as it was intended Randy may find this
interesting, as he is also using a mozilla.org product, but of an
earlier release version.)


\V/ Live long and prosper

PointedEars