protecting .js files with htaccess

[icydash]

i have some code that uses <script src=whatever.js> in it and i want the code to be allowed to use the .js file, however i dont want people to be able to just type in the url and download the .js file... how do i block people from being able to access the code by directly typing in the url (i think it can be done with htaccess)?

[webdevsf]

I don't know about apache, but as a general rule, you can't stop anyone from downloading the js file. In fact, if they want it, its most likely already in their cache, and they don't ever have to go back to your server to retrieve it.

Consider a javascript source scrambling solution instead.

[icydash]

thats dumb though everyone knows how to decrpyt it, theres got to be a way of protecting source...

[msr986]

>theres got to be a way of protecting source...

No, there isn't. If the browser can read it, a human can read it. You can make it difficult, but it can still be retrieved.

[jdMorgan]

icydash,

In answer to your original question, you can "sort of" use .htaccess to stop direct type-in access, but at the cost of losing visitors who access your site from behind corporate firewalls, or those with firewalls or internet security software installed at home.

The problem is that you can test for a blank referrer, but there is no way to tell if the referrer is blank because it is a type-in address, or because an intervening proxy or firewall dropped the referrer for "security" purposes. If you install RewriteRules in .htaccess to block accesses with no referrer, then these people will not see your site normally, because their browsers won't be able to load and run your javascript.

Javascript, like HTML published on the web is easy to "steal." If you are really worried about it, then you have a couple of choices - a registered copyright and a good attorney, or perhaps a server-side solution. By keeping the majority of the script function on the server, you can "hide" part of the functionality of your code. ...But don't ask me for details, 'cause I haven't done it myself... :)

You could also implement some kind of fancy session tracking to make sure that anyone requesting a .js file has loaded the containing html page, but that would then require you to disable caching of the containing page in order to ensure that it was always loaded from your server. And that would slow down your user's experience and increase your server load.

I found it easier to just "get over it" in most cases. YMMV.

HTH,
Jim

[icydash]

It the case i have here, i can't 'get over it' -- whats being programmed is a large scale realtime (so no server-side coding can be done either) game and simply being able to take the source right out of my own .html files nad stick it ont heir site is out of hte question. there has got to be some way of securing javascript code or a .js file.

[icydash]

and source scrambeling the javascript wouldn't do anything anyway, they can still just take the scrambeled source and stick it right on their site. see my dilemma?

[drbrain]

You need to beef up on lawyers and licenses then.

If you release your code to be run elsewhere, then they can reverse engineer it. Not even moving to Java or C will help you.

You can always invite them over to your house to play the game on your computers...

[msr986]

>It the case i have here, i can't 'get over it'.... there has got to be some way of securing javascript code or a .js file.

Beyond the suggestions mentioned here, there are NO other solutions. What you are asking is not technically possible. It someone wants your JS code, they will find a way to get it.

[choster]

Javascript was invented by Netscape as an add-on to HTML, which has always meant to be viewed. Consider that all my browsers going back to Netscape 0.9b have included a View Source feature; it would seem to me that code on the web was intended to be viewable and shareable, and that is why it is so hard to obfuscate or "protect" HTML, CSS, or JS. If you need to protect your investment by concealing the code, opt for something executed on the server, a CGI script or an API application.

[icydash]

cgi, php, etc, are not in realtime, hence the problem. and if what your saying is true, that there is absolutly no way to protect this code, out of the thousands of security measures and teams working on this stuff to date, then you are wrong, i dont care what you say.

[TallTroll]

The problem here isn't security, really. JS is a client side technology ie, the code is delivered to the browser, which then runs it. Therefore you MUST deliver readable, runnable code to the browser, or it just doesn't work. If someone wants to get really fancy, they will run a packet sniffer on the traffic from the game server, strip the TCP/IP headers, and stitch the raw source back together to nick it, or intercept it at the transmission layer, modify it before delivering it to the application layer and presumably then screwing up the game mechanics etc

>> simply being able to take the source right out of my own .html files nad stick it ont heir site is out of hte question.

Then you need to use a non-web technology surely. HMTL, JS etc, its all explicitly designed to be open technology, to facilitate sharing. Its one of the reasons that security is so damn hard in ecommerce for instance. You have to create at best an extra layer (SSL), maybe a different protocol (HTTPS), or ultimately a proprietory, non-open system (EDI springs to mind) to have any chance of securely exchanging c/c details etc and then someones just going to leave all the c/c details on a database thats open to HTTP calls. D'oh!

What you really need is a non-open equivalent, your own proprietory file format etc, similar to Flash in that regard, I suppose. Then you supply a plug-in for the browser, and the files go up as meaningless binary files, useless unless you can decode them with the plugin.

[icydash]

I figured out how to secure my javascript code, and you are all wrong, it can be done with php. It all works, and it was relitivly easy to do, although it took me an hour or so to figure out. I am still working on securing it more, but at the moment, when you run the .php file with the .js code in it, nothing comes up unless its run by the proper other .php file. As i said there are still a few minor security problems, but this will fix a majority of them--so to all you people out there saying it cant be done, IT CAN! (you just need to use your heads)

[keeper]

Perhaps you can explain how you stopped the browser cacheing the .js file....

[webdevsf]

IcyDash - let us know when you've fixed all your security issues. I'm sure a few of us would be happy to beta test your "solution". ;)

[icydash]

Guys, I'm not to worried about beta testing, I work with the best and brightest out there, if there is a hole, it can be found by these people. I own <snip>, and I'll let you all know how its done once I resolve all security issues -- and to the comment above, with php headers you can stop browser catching.

[edited by: Woz at 6:39 am (utc) on July 2, 2003]
[edit reason] No URLs please, TOS#13. [/edit]

[wackybrit]

I figured out how to secure my javascript code, and you are all wrong, it can be done with php. It all works, and it was relitivly easy to do, although it took me an hour or so to figure out. I am still working on securing it more, but at the moment, when you run the .php file with the .js code in it, nothing comes up unless its run by the proper other .php file.

Gee. All I do, then, is request your PHP file, send a fake referrer string through something like Net Vampire, and bam, I now have your JavaScript.

Alternatively, I could just access your page the regular way, and have a packet sniffer grabbing your source as it flows into my machine.

[webdevsf]

Urls are against the TOS, IcyDash...

Anyway, as your board is for hackers, you will find out for yourself anyway how secure javascript is quickly enough.

You should write client side code using C++.

[drbrain]

There's also Mozilla's about:cache, where you can pick out any 'ol file in your cache and view it, or the DOM Inspector where you can pick any 'ol JS file and view and save its contents, or Venkman, the JS debugger, where you can view any 'ol JS file and save it.

I doubt it would take any single person determined to get your JS more than an hour to download it and email it all to you. Certainly no more than a day.

Care to sticky me a URL, and email?

[icydash]

As i said above their are still some security issues, and contrary to your beliefs, it is not done with JUST a referrer, there are several security measures in place. We are also working on transfering the data encrypted so, no, a packet sniffer will not work. And as for the cache, i believe ive said it before, there are ways around that with php headers. And as you said, yes, my sites boards are all for hackers, so i am sure all security issues will be resolved quickly. I am not saying it is 100% secure now, i am just saying that we are on our way there, and i have allready managed to do 'the impossible' that you ALL said i couldn't do, so why not a little faith?

[icydash]

sorry about the url i didn't know it was against TOS.

[icydash]

Oh and for all you who think you can do it with js debuggers and so on, its in a .php not .js file, so no, you can not download the code, and js debuggers will not work since the code is stored server side unless the script is given the correct arguements from the correct file.

[icydash]

trust me--this is what i do, im not retarded, heh. :)

[GeorgeGG]

For what it's worth:

Oh and for all you who think you can do it with js debuggers and so on, its in a .php not .js file,
so no, you can not download the code, and js debuggers will not work since the code is stored
server side unless the script is given the correct arguements from the correct file.

Think I understand about what you are saying, I use a '<script src=whatever.js>'
which is really a server binary 'c' to deliver a js source file back to the browser.
If it's not called in the right way/place/path/etc, 'most' of the time you
won't get the js file, and if you do get it, it's most likely not useable anywhere else.
Likewise the js file in the cache is not useable elsewhere also.
But people can still get it.

GeorgeGG

[Key_Master]

trust me--this is what i do, im not retarded, heh. :)

Icydash, don't listen to the naysayers. No, you can't protect JavaScript files 100% but what's so bad about 99.5%?

[icydash]

exactly thanks for the encouragement guys its nice to finally get some :) and im probably 50% there in my quest for secure js code ;]

[icydash]

w00t baby make that 50% a 60%, now with all the measures in place the ONLY way of getting the code is with a packetsniffer. Going to the correct url, no matter what arugements you type in, it wont display the code. Now just to find a way to encrypt the data as it sends so its a big jumble in the packetsniffer and my 60% jumps to a 90%, leaving just other random ways i havnt thought of yet. :]

[wackybrit]

I just don't hope you 'encrypt' it enough so that your browser cannot run the plain-text scripted code *g*

[TallTroll]

>> leaving just other random ways i havnt thought of yet. :]

Like implementing a system freeze, and pulling the code straight out of RAM over a null modem connection?

I've seen that done... and I don't think theres a way around it

[icydash]

yea stuff like that