Prevent download of javascript code

[ivanwin2k]

My SSL server has a directory structure like the following:

[tt]
SSL Root
- Some Directory #1
- Some Directory #2
- ...
- JS Files
[/tt]

Everything works fine, authentication is working, et. al.

The html pages in the subdirectories use common JavaScript code, which resides in the "JS Files" subdirectory. This repository contains scripts that are common to all pages (e.g., no right-mouse click), so I include a SCRIPT directive in each page to point to the source found in "JS Files".

Having said all of this, I would like to know how to keep my access (as configured) to the SSL directories, but restrict it to the "JS Files" directory.

Ideally, I would like to prevent the user from downloading the JavaScript files. Is there a way to configure Apache to allow the pages to read the .js files, but prevent the user from accessing them directly? I.e., as it stands, the user can link directly to "https://[My Host]/JS Files/Some java script.js" and download/view the JavaScript file. I would like to prevent this.

Everything that I have tried thus far has only disabled the html pages from reading the script files (e.g., re-enabling right-mouse click).

I tried adding the following to my SSL VirtualHost:
[tt]
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https://[My SSL Host]/[SSL Root]/.*$
RewriteCond %{REQUEST_URI} ^(.*)\.js$
RewriteRule ^(.*) - [F,L]
[/tt]
This prevents the user from downloading/viewing the scripts in that directory; but, it also prevents the html pages from reading and executing the JavaScript files.

Can someone help? I am sure it's probably some simple rewrite rule, but I am pretty novice at server configuration and the rewrite rules tend to get me into trouble.

I have already looked at Stopping people saving images (Thread215-620990); however, since the JavaScript is not viewable, I am assuming that there is some way to protect it from being downloaded.

Thank you in advance for your help.

 

[sedj]

Firstly - do you really care if someone actually wants to look at your javascript code ? Is there some company secret in this code ? Do you think you've done something no-one else has ? I doubt it !

Secondly - even if there were a way of doing what you wanted, every time a browser loads an html page with a link to a javascript file, it also downloads this javascript and saves it to the user's computer - so if they really did want to view it, then its not hard !

Thirdly - An HTTP request is an HTTP request - whether it is spawned by a browser downloading it, or by someone typing in the direct URL. In short, if you block downloads of your javascript, then you block everything, including the browser trying to run your javascript.

If you are really that worried about it, then you should use a code obsfucator to mangle your javascript into a *basically* unreadable format.



Click here to learn Ways to help with Tsunami Relief
--------------------------------------------------
Free Database Connection Pooling Software

http://www.primrose.org.uk

 

[GOstlund]

There is also the option of encoding your JavaScript, but I'm afraid I don't have the time to go into detail about that. What I can suggest is that you could use a gateway file for your javascripts and have it check for an appropriate referrer before passing the .js file through. This is not going to be perfect, but should at least prevent people from linking to it off site and might work to keep them from viewing it through direct access of the .js file. However, the curious user can still go through their cache and find the file thier browser downloaded on their behalf.

---------
HTH,
Gavin Ostlund

 

[Deleted]

Add this to your .htaccess. This only allows downloads from sepecified domains. Works great.

SetEnvIf Referer .domain\.com block_this
Order Allow, Deny
Allow from All
Deny from env=block_this

http://unixjunky.com

 

[ivanwin2k]

To sedj: Click here for the definition of "edification". Learn it, live it, love it.

To GOstlund and UnixJunky: Thanks for the suggestions. I will look into each.

 

[Wullie]

Both of the suggestions above rely on a referrer string being passed by the browser and a correct one at that. If you rely in the slightest on your visitors being shown your page correctly, do not use these methods.

If a browser fakes the referrer or does not pass it, the JS file will be refused and your page will not function. There were rumours that a few browsers were going to disable the referrer string as default in the future. Because of these issues, you need to allow a blank referrer to pass the checks, rendering the whole thing pointless.

As mentioned by sedj, is it really necessary for you to hide these files? What is the point of hiding a no right click script? This may not apply to you but 99% of the people asking these questions are using free scripts they got from the Internet so they are available anyway.

The people who are not fooled by the no right click will be able to get your file anyway, no matter what method you use. The file is sent to the browser for it to render it, blocking this from happening results in your code not functioning.


Hope this helps

Wullie

Fresh Look - Quality Coldfusion Hosting

http://www.tutorial-world.com

The pessimist complains about the wind. The optimist expects it to change. The leader adjusts the sails. - John Maxwell

 

[ivanwin2k]

You're right, my browser didn't pass the referrer and I couldn't figure out a way around it.

I understand the point you and sedj are making; it's not the point I am trying to make.

I am a novice administrator of an Apache Web Server that I run out of my home office. Its use is to securely serve on-line help pages, user web space, and downloads for applications that I develop.

As a purely edifying exercise, I was wondering if it is possible to obscure the JavaScript files, while allowing the SSL pages to run the code in them. The code that I intend to run is proprietary and I do not want it made public. It is not trivial script code which disables a mouse-click.

As a specific case, I currently do not have the ability to run Java Server Pages or Servlets (or any server-side code other than CGI--in which I am not skilled) on my Apache Web Server. Again, I am a novice admin, so I was hoping that I could "cheat" and save time by running it as obscured JavaScript, rather than taking the next week or two learning how to enable Servlets (and Session cookies) on my Web Server, which it looks like I'll have to anyway.

If you have any links to good tutorials for doing so, I'd appreciate it.

 

[Wullie]

If when you say "cheat", you mean that you are trying to hide sensitive details in the JS or anything like that, don't do it or the data will be compromised, there is no doubt about that.

It all comes down to the way that the Internet works. For the browser to display the data, you need to serve it in a format that it will understand. You can't prevent it from being downloaded as the browser does this to display it, so the file is already on the users machine.

You also can't use some encryption method that will prevent humans from reading it because the browser will not understand it so can't display the file. Yes you can use the cheap encryption methods out there, but all it takes is another simple piece of Javascript to decrypt it and this is not hard to do.

The only slightly challenging method I have ever seen over the years was an ActiveX component that you needed to install before viewing the files. Even this was defeated within less than 30 minutes. Take into account that your visitors will also not install any component from an untrusted source and using this method will stop people from stealing your source, but only because they won't stay on the site long enough to actually look at your pages.

If you make things difficult for your users, you risk losing them after they arrive at your site. No-right click scripts will also not work. I use Firefox and one of the extensions I have installed blocks these scripts. If you want to mess with your pages, then fine, but when you start to mess with my basic browser functions for no reason then that is annoying and you would lose me as a visitor. If you end up doing this, what is the point of it being on the Internet in the first place when nobody will see it?

Wullie

Fresh Look - Quality Coldfusion/Windows Hosting

The pessimist complains about the wind. The optimist expects it to change. The leader adjusts the sails. - John Maxwell

 

[ericbrunson]

ivanwin2k,

The JS code has to be able to be downloaded by the browser in order to execute it, and it has to be able to un-obfuscate it if it is obfuscated, somehow. It's really no different than asking if you can hide your HTML from a "view source".

 

[ericbrunson]

P.S.

ivanwin2k: Click here for the definition of sarcasm. Learn it and lose it. Comments like yours to a regular contributor like sedj is not just going to alienate him, but the rest of us, too.

 

[ivanwin2k]

Just to remind you, forums are useful in sharing ideas and learning from each other. They are NOT useful when users like sedj post smart-ass responses.

I only asked a question, if he didn't know the answer, then why post a smart aleck reply? His tone was pedantic and derogatory. I don't care if he owns this forum, the tone of his reply was not warranted. Just say "it can't be done" and omit the lecture.

 

[ivanwin2k]

To Wullie:

Thanks, as a server-side developer (and a novice to web scripts), I did not know that all JavaScript is downloaded with the page. I assumed that the web server could be manipulated to prevent it in some way.

Thanks for the post.

 

[Wullie]

ivanwin2k,

I've read sedj's post again and to be honest, I've pretty much just said the same as him. In his original post, he mentions the following:

1) Probably not a reason for hiding it anyway
2) Browser downloads the files to display them.
3) Blocking access to direct downloads blocks access to all browsers.
4) You could use a obsfucator.
5) The code created by 4 could be easily decrypted.

From your first post, you mention

Everything that I have tried thus far has only disabled the html pages from reading the script files (e.g., re-enabling right-mouse click).

This repository contains scripts that are common to all pages (e.g., no right-mouse click), so I include a SCRIPT directive in each page to point to the source found in "JS Files".

In my reply above, I assumed you were trying to hide a no right click script. After reading your original post again, it still seems that way to me.

Even in the last post you mention:

Thanks, as a server-side developer (and a novice to web scripts),

The point here that everyone is trying to make is that anything you create will be somewhere else on the Internet, and if you knew javascript well enough to create something totally spectacular then you would know that the browser downloads the file to the machine and that a no right click script is totally useless and annoys most people because it disables many very basic browser functions.

I personally don't beleive that client-side code should be hidden. I learned client-side code by viewing other scripts, taking free scripts from the Internet and playing with them. If they had been hidden it would have hindered my learning. As I mentioned above, the people who normally try to hide their code are the same ones who use scripts they found on the Internet, so why should they have any right to hide it?

None of us are trying to have a go at you, but when you ask for help to do something that cannot be done and it widely known that it can't be done, this only shows us your lack of knowledge in the JS area, which makes it even harder to beleive that you have something that should be hidden.


Hope this helps

Wullie

Fresh Look - Quality Coldfusion/Windows Hosting

The pessimist complains about the wind. The optimist expects it to change. The leader adjusts the sails. - John Maxwell

 

[ivanwin2k]

The point you (and everyone else) are trying to make has never evaded me; I was simply trying to prohibit access to some code in a directory. I didn't mean to start a never-ending philosophical debate about the merits of open source.

Thanks to everyone for your replies. I consider the matter closed.