Welcome to WebmasterWorld Guest from 3.84.139.101

Forum Moderators: open

Message Too Old, No Replies

Protect Javascript code

is that possible

     
1:56 am on Nov 23, 2004 (gmt 0)

Preferred Member

10+ Year Member

joined:Aug 14, 2004
posts:602
votes: 0


Hi,

I was wondering if there is a way to protect a javascript code?
I took a long time to code some nice tools for my visitors but im afraid they will be copied easily without even asking for permission.

Not that i dont want to share, just that i d like to know about it kinda respect point of view :)

Thanks

12:57 am on Nov 26, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member kaled is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:Mar 2, 2003
posts:3710
votes: 0


Yep, just tried it in Firefox. Save page complete and I have the javascript file.

It reads as follows
alert("Woohoo! My JavaScript Works!");

Kaled.

1:24 am on Nov 26, 2004 (gmt 0)

Senior Member from CA 

WebmasterWorld Senior Member httpwebwitch is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:Aug 29, 2003
posts:4061
votes: 0


I mentioned this last week in another thread [webmasterworld.com]. I can't presume this is a new idea.

A nice way to protect your JS is to use a combination of crippling and obfuscation. To cripple a script, make it conditional on the location:

<script>
var loc=location.toString();
if (loc.indexOf("domain")!=-1){
alert("do something")
}
</script>

To make the crippling even more difficult to crack, use some scrambling or encryption on the location string. Set a few bool variables to "true" and keep checking that condition all over the place throughout your script.

then obfuscate the heck out of the whole thing. Sure your code won't be "hidden" from anyone, but it will be so knotted up even the most skilled JS coder would be lost trying to untangle it.

I'm eager to see how this problem gets solved. We should all pool in together and offer a prize to the first person who makes an uncrackable, totally hidden JS.

3:49 am on Nov 26, 2004 (gmt 0)

Junior Member

10+ Year Member

joined:Apr 10, 2003
posts:107
votes: 0


Ultimately Javascript can NEVER be protected. You can deny access to the code based on referer or user-agent but I can just fake those headers.

Javascript is client-side. I can get to it because the browser must get to it.

4:51 am on Nov 26, 2004 (gmt 0)

Full Member

10+ Year Member

joined:Jan 19, 2003
posts:324
votes: 0


I use .htaccess file to protect css and js files:
RewriteCond %{HTTP_REFERER}!^http://domain.com/.*$ [NC]
RewriteCond %{HTTP_REFERER}!^http://domain.com$ [NC]
RewriteCond %{HTTP_REFERER}!^http://www.domain.com/.*$ [NC]
RewriteCond %{HTTP_REFERER}!^http://www.domain.com$ [NC]
RewriteRule .*\.(css¦js)$ - [F,NC]

dcrombie

10:18 am on Nov 26, 2004 (gmt 0)

Inactive Member
Account Expired

 
 


You can (I think) reduce that RewriteRule to the following:

RewriteCond %{HTTP_REFERER} !^http://(www\.)?example\.com/? [NC]  
RewriteRule \.(css¦js)$ - [NC]

However, the code is already downloaded by the browser along with the page - and a lot of browsers now let you view CSS/JS code/files without making another request to the server.

And otherwise, it's not difficult to pass a request with a fake REFERER value and by-pass any .htaccess restrictions of the type above.

Finally, as the search engines are starting to scan CSS/JS files (for some months now) you might be incurring penalties in terms of ranking by blocking their spiders.

11:21 am on Nov 26, 2004 (gmt 0)

Junior Member

10+ Year Member

joined:Nov 24, 2004
posts:46
votes: 0


no matter how you code serverside, a JS file is just a text file which is downloaded from the server and viewed in a browser. anyone can then save the file and pass it off as my own if they're that way inclined.

the words, "dead", "flog", "horse" and "a" come to mind.

2:52 pm on Nov 26, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Mar 14, 2004
posts:1181
votes: 0


jbot, you appear to have the impression that the contributors to this thread view it as more than an academic exercise, a simple "distraction". If so, I believe you are mistaken.

Since decompilers started becoming more efficient, a little less than 20 years ago, there has been little one could do prevent the exposure of one's code. But tilting at windmills is part of the exercise that advances the art.

2:59 pm on Nov 26, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Apr 15, 2004
posts:2047
votes: 0


Please read the thread properly.
The general idea is not to make it impossible, but to make it "difficult".

In any case, there is always the thrill of the chase. I've been picking up a little PHP in the process.

It would be nice to think that you have joined us for a little more than to post messages, on the 2 current threads on this topic, telling us what we already know.

I'm well aware that you are a skilled scripter, jbot, and look forward to learning something in a thread that you feel is more worthwhile pursuing.

3:24 pm on Nov 26, 2004 (gmt 0)

Junior Member

10+ Year Member

joined:Nov 24, 2004
posts:46
votes: 0


the impression i got is that you were seriously trying to hide the code, not just make it harder. however, those users who'd want to get the code will still be able to get it whatever you do. casual users are not the kind to go looking at the code anyway, even tho they are the ones who'd only be put off by your measures.

if you are producing any JS of note, or which is central to the intellectual property of your applications, then you should look into JScript.NET which can be compiled into bytecode in the form of DLLs which you can then be called from an HTA. however, why do that when you could create windows' forms and build executables.

rambo: yes, indeed, tilting at windmills, i couldn't have quoted Cervantes better myself ;)

5:28 pm on Nov 26, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Apr 15, 2004
posts:2047
votes: 0


I should eat my words. After a "proper" inspection, it seems that some are still under the impression that...

kaled, funny thing, I hadn't thought of simply saving as "webpage complete".

The pursuit of the impossible at nos. 1 and 2?
Something must be done.

3:00 am on Nov 27, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Mar 14, 2004
posts:1181
votes: 0


Actually, the saving of the complete web page would be easy enough to circumvent if IE's JScript interpreter handled garbage collection properly.

A hidden iframe can be loaded with a page that assigns the parent's function to the iframe's code, then loads a different page into the iframe. What you end up saving is the page that is active in the iframe at the time of the save. Since the original page's code hasn't directly been affected, the new functions exist as little more than memory variables.

In theory, garbage collection shouldn't happen on code that still has a live pointer somewhere, even if the class or object the code directly relates to is closed. IE isn't smart enough to pull that off (Moz and Opera are), so it fails.

vinod yadav1919

7:31 am on Nov 27, 2004 (gmt 0)

Inactive Member
Account Expired

 
 


Yes even you can Protect Your javascript code using HTML Protector
:)
Cheers
Vinod
10:55 am on Nov 27, 2004 (gmt 0)

Junior Member

10+ Year Member

joined:Nov 24, 2004
posts:46
votes: 0


Rambo: turing JS off will not stop that anyway, in which case I can look at the source and still get the files I want.

also, making your site so dependent on JS is hardly usable and accessible. about 10-13% of users have no support for JS (either deliberately or by default), so that's a sizeable chunk of your audience being deprived the use of your site. consider potential revenues and that's a lot of income.

1:52 pm on Nov 27, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Mar 14, 2004
posts:1181
votes: 0


jbot, perhaps you overlooked the post I made much earlier wherein I stated that hiding one's code was pointless from the get go. Again, I am not endorsing the hiding of JavaScript code; I am pointing out the way things work as an academic exercise and, while doing it within the context of the current discussion, much of this information has potential ramifications beyond the constraints of the current topic. Understanding garbage collection, for instance, is a critical topic for any OO programmer to know (unless, apparently, they work for Microsoft).
3:16 pm on Nov 27, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Apr 15, 2004
posts:2047
votes: 0


[i]Not so much the destination, but the journey[\i]

Rambo. I have a suspicion that IE's dodgy garbage collection could be used in your favour. IE doesn't, apparently, collect orphaned circular reference chains if they involve an HTML element. Not on reload, and I've heard, not until the window itself is closed.

Any mileage?

7:52 pm on Nov 27, 2004 (gmt 0)

New User

10+ Year Member

joined:Jan 24, 2004
posts:30
votes: 0


But there ARE some "javascript scramblers" out there:

Look at the source code for
[1-4a.com...]

In the middle of the html source there is scrambled Javascript

4:36 am on Nov 28, 2004 (gmt 0)

New User

10+ Year Member

joined:Nov 19, 2004
posts:9
votes: 0


First off, yes, it is impossible to fully protect javascript. It may be possible, however, to make "stealing" javascript so difficult that it becomes easier for an interested individual simply to write code to perform the same function themselves, which should hypothetically be enough.

The PHP route is a good start, but as many have pointed out it is insufficient on its own. Code obfuscation is also a good choice, but again, if given sufficient time, that too can be taken apart.

What I'd suggest is, use PHP to its fullest extent. First-off, any functions which can be handled server-side should be handled server-side; if the results are needed by the JS code, just insert them in at the time of creation.

Second, use some of PHP's data to further encrypt and obfuscate the code. Generate code that breaks when it is executed in a different month, for instance -- since the copy you deliver is always up to date, it will work for your users (with some circumstantial exceptions; I'd avoid using this on a high-volume site.) Use browser data on the PHP end to deliver code that won't work in different browsers (not a hard task at all)... And so forth.

Suddenly, anyone who wants to steal your code has to Save Web Page Complete (it'll likely take a while to figure that out) or use a program to falsify http requests... Now, once they have the code, they have to figure out where some of these static variables are coming from (the code that you handled server-side), rewrite the functions to provide that data, then adapt it to their page. It works, until they go to another browser -- which is sure odd, cause your site seems fully-compatible. Eventually they figure out that trick, download and cross-reference all the browser-specific stuff, eventually disabling your browser-checking. And hey, now it works... Until next month. And now they have to figure out what's going on this time, they download your new code, mull that over, eventually manage to disable your date-checks...

After that, and whatever other wrenches you've thrown in there, this nefarious fellow has stolen your precious javascript -- but at a significant cost of effort. People who steal code are, by definition, trying to avoid effort, so they're probably not going to get this far, and if they do, well, you've at least won a moral victory of some sort.

That said, I can't imagine a piece of javascript so tasty and brilliant as to warrant this kind of defense; but, hypothetically, it could be done.

11:53 am on Nov 28, 2004 (gmt 0)

Full Member

10+ Year Member

joined:July 23, 2003
posts:228
votes: 0


The hard part is dreaming up a cool feature to begin with. Once you see it in action, its not very hard to replicate it one way or the other.
3:27 pm on Nov 28, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Mar 14, 2004
posts:1181
votes: 0


Thanks, Bernard, for the insight. Unfortunately, I haven't been able to figure any way to get IE to maintain the reference to the page's functions, once the page is no longer active. The IE interpreter issues some prattle about a "freed script", as if script emancipation is the goal here. Personally, I prefer my scripts in absolute thrall, or, at very least, highly subjugated. Keep 'em down, keep 'em down, keep 'em down. But, "Nooo!", says Redmond.

One could always include: "Best when viewed without Internet Explorer" on one's pages, I suppose.

I haven't tried any nodal nonsense yet; I suppose there is a flimsy, outside chance that such might be persuaded to provide some relief from the depredations of the apparently Redmond-sponsored, SLF (Script Liberation Front).

5:37 pm on Nov 28, 2004 (gmt 0)

Junior Member from AU 

10+ Year Member Top Contributors Of The Month

joined:June 28, 2003
posts:178
votes: 24


Just a warning about using the referer to test for unauthorised use: I would estimate that the amount of users who deliberately obfuscate their referer string is likely to be around 10-15%; it's certainly what I see from the commercial site I run, and, in particular, is used as default by some anti-virus programs. This means that any use of the referer variable as security is not a very good plan.

I don't quite know what scripts are exciting enough to hide from a user. Gmail uses JavaScript heavily, but much of what's there is used in conjunction with server-side stuff - which is, as has been said already, the best plan if you want to hide stuff.

7:22 am on Nov 29, 2004 (gmt 0)

Junior Member

10+ Year Member

joined:July 18, 2003
posts:63
votes: 0


Accepting the fact (as I happily do) that there is no way to secure your javascript code, and entering into the spirit of this thread, I have got a test system that I think would make it quite hard to capture the javascript source.

It is not obfuscation in the normal sense, but a method of making it difficult for someone to actually see the code at all, regardless of how it looks.

I have set up a test page, but I don't suppose I'm allowed to post a URL. However, if anyone fancies "taking the challenge" to find the hidden code, send me a sticky and you can enjoy telling me what an idiot I am.

Please note jbot, that the right to call me an idiot is earned AFTER you prove it possible in my example - rather than quoting the already established fact that it is not possible to secure your javascript code.

1:21 pm on Nov 29, 2004 (gmt 0)

Junior Member

10+ Year Member

joined:Sept 21, 2004
posts:195
votes: 0


thought u guys might be interested in this:

[siteexperts.com...]

the guy set a challange to crack his code. It took 8 days for someone to do it. Pretty good going. Of course - it was ultimately cracked. Uncrackable is not possible - but it is nice to make them work hard for it.

Haven't checked this out yet. Will write more when looked at it.

1:40 pm on Nov 29, 2004 (gmt 0)

Junior Member

10+ Year Member

joined:Sept 21, 2004
posts:195
votes: 0


The visitor starts on webpage A. Clicks on link - is redirected to webpage B. Webpage B has an automatic redirect to webpage C.

The visitor goes:
webpage A - webpage B - webpage C

The crux is that I want the visitor to get to webpage C, unaware that they have gone through webpage B.

Thus, I want the address in the url locator bar to be for webpage A at the start. Then move to that of webpage C, when the link is clicked. Without displaying the url of webpage B in the interim period.

HOW CAN I DO THIS? HELP!

Would be so grateful for any help.

The relevance of this to protecting javascript. Page B (the "secret" page) will be where my javascript will be!

The visitor will look for my javascript on page C - but of course it is not there.

I will take affirmative action to prevent page B from being cached.

The javascript on page B will be posting javascript variables (for instance users date and time) to my server - for PHP code on page C. Because this code is server side PHP, it will of course be hidden.

I feel that this is quite a novel tact. Would be interested to what people think. By the way - I feel the need to add this now - I know that hiding javascript is ultimately impossible. But if one makes getting it hard enough - then we can deter most persons. Also, as pointed out, this is a nice academic exercise and I am learning lots of things on this journey. For instance, HTTP headers were a bit of a mystery to me before! Now getting my handle on them! I am not writing this to anger other members of the board, who perhaps feel that aiming to take steps to slow the elucidation of source code is not a worthwhile pursuit.

APPENDIX

Below I have put a bit more background on why I felt that having a page B was a good idea:

Having a webpage B in this way also allows me to pass javascript variables to PHP.
Can’t pass JavaScript variables to a PHP script in the same page as the JavaScript. They have to be passed to a PHP script on another page. The reason is that PHP is parsed server side before the page is downloaded and JavaScript is parsed client side after the page is downloaded. The variable values have to be written before they’re passed and this wouldn’t happen if you tried to write them directly to PHP in the same page, since the PHP would be parsed before the JavaScript.

Since Javascript is (usually) a client-side technology, and PHP is (usually) a server-side technology, and since HTTP is a "stateless" protocol, the two languages cannot directly share variables.

It is, however, possible to pass variables between the two:

1) One way of accomplishing this is to generate Javascript code with PHP, and have the browser refresh itself, passing specific variables back to the PHP script.

2) Another way is to have the javascript variables passed to PHP code on a different web page. (this is the method that I am using here).

1:54 pm on Nov 29, 2004 (gmt 0)

Junior Member

10+ Year Member

joined:Sept 21, 2004
posts:195
votes: 0


Another idea that I had was to perhaps change javascript variable names.

Obfusicating the code is one thing - setting it to a trash of random looking letters and digits. But wouldn't it be great if you could actually change the javascript code such that it is quite different from your original code, but doesn;t seem to be altered in any way. Just looks like normal javascript code.

For instance, if the user can see a "user agent" term in your code - can see that you are doing something with this entity. How about if you could hide the "user agent" term as a "screen resolution" term. They would think that you were working with screen resolution when you are in fact working with user agent. What is more - they would not guess that you were trying to hide your code.

Is there any way to do this? Some kind of ciphering system that allows you to hide viable code withg other seemingly viable code.

This idea is a bit out there and there is probably no legs in it whatsoever. Just interested what people think.

2:55 pm on Nov 29, 2004 (gmt 0)

Junior Member

10+ Year Member

joined:July 18, 2003
posts:63
votes: 0



The visitor starts on webpage A. Clicks on link - is redirected to webpage B. Webpage B has an automatic redirect to webpage C.

The visitor goes:
webpage A - webpage B - webpage C

The crux is that I want the visitor to get to webpage C, unaware that they have gone through webpage B.

Thus, I want the address in the url locator bar to be for webpage A at the start. Then move to that of webpage C, when the link is clicked. Without displaying the url of webpage B in the interim period.

HOW CAN I DO THIS? HELP!

Would be so grateful for any help.

The relevance of this to protecting javascript. Page B (the "secret" page) will be where my javascript will be!

The visitor will look for my javascript on page C - but of course it is not there.

I will take affirmative action to prevent page B from being cached.

The trouble with this approach is that it is trivial to write a script to collect page A and see where page B is. Then you simply collect page B from the script and you have the source. The redirects are simply instructions you give to a browser, there is nothing to force them to be followed, meaning I can easily circumvent them.

The example I have built brings together a few seperate elements to produce what I think is one of the trickiest ways of hiding javascript, and I suspect as good as you can get due to the obvious difficulties of this task.

There is no obfuscation of the executed code because this is easily reversible like hex encoding. There is no request to simply not cache the code because that is easily ignored by a custom script.

I figure there probably isn't really a problem with posting the URL as it's not for a site with any content, just this example.

[clockend.co.uk...]

When you load this page, a small piece of javascript is executed that pops an alert to your page. The challenge is to find this code and tell me the comment that is written next to it in plain text.

I can think of 2 ways you can get at it, but I don't believe either are particularly obvious or simple - so please, prove me wrong.

edit: There are a couple of ways that this script can be improved, but this is more a demonstration of an approach than the perfect implementation of it

3:22 pm on Nov 29, 2004 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Mar 14, 2004
posts:1181
votes: 0


Ahhh. Quite refreshing to see there are other tilters about. I've always preferred to keep company with the curious. Or maybe it's a curious company I've always preferred to keep. I get confused on some of these points.
3:30 pm on Nov 29, 2004 (gmt 0)

Junior Member

10+ Year Member

joined:July 18, 2003
posts:63
votes: 0


blimey.... so far 2 people have attempted to access the page, one is clearly trying to work it out.... the other is googlebot! They really are fast these days on the spidering.... now just 9 months for it to rank :)

edit: sorry, being stupid... same guy playing with user agents :)

4:21 pm on Nov 29, 2004 (gmt 0)

Junior Member

10+ Year Member

joined:July 18, 2003
posts:63
votes: 0



Since Javascript is (usually) a client-side technology, and PHP is (usually) a server-side technology, and since HTTP is a "stateless" protocol, the two languages cannot directly share variables.

It is, however, possible to pass variables between the two:

1) One way of accomplishing this is to generate Javascript code with PHP, and have the browser refresh itself, passing specific variables back to the PHP script.

2) Another way is to have the javascript variables passed to PHP code on a different web page. (this is the method that I am using here).

This is a bit off topic but...

Regarding the above, there is a third way you can go with this that provides I think a more elegant solution (even though it's a total fudge).

You can pass parameters by updating the src of a dummy image variable.

So for example:

dummy = new Image();

if (somethingorother)
{
dummy.src = '/myphpscript.php?param1='+my_js_param;
}

this way, you can fire updates back to a php script without needing to reload the page at all. I've used this in some projects where js provided some nice interface functionality for updating lots of little bits of info and where the round trip to reload the page each time just made it too slow.

Back on-topic, still no-one found my hidden js?

11:35 am on Nov 30, 2004 (gmt 0)

Junior Member

10+ Year Member

joined:Sept 21, 2004
posts:195
votes: 0


dear stark,

thanks ever so much for your interest in my idea. You made a very valid point. My idea is perhaps not as generic as I first thought. But I think it could still be a nice way to go, if I can do it, because page A does not really need a link on it to page B.

Page A can have a PHP automatic redirect to Page B. So, as soon as the visitor hits Page A - they will be redirected to page B.

They then immediately go through Page B - there is an automatic redirect from Page B to Page C.

I am hoping to hide the url of Page B in the locator bar, so that the visitor is unaware of going through page B.

They think that they have simply undergone an immediate redirect to page C. Are unaware of the existance of page B.

Page B is where the javascript will be of course!

The visitor being redirected from page A to page C - this could be seemingly for quite good reasons - for instance moved website.

Would be really great if anyone knows how I can hide the url of page B in the locator bar: I want the address in the url locator bar to be for webpage A at the start. Then move to that of webpage C, without displaying the url of webpage B in the interim period.

I realise that this method is not infallable. In fact, quite flawed maybe. But I would really love to learn how to do it. Would be so grateful if anyone can help.

P.S thanks starky for the info on javascript to php on the same page, without refreshment. You really are pretty good at this kind of thing!

12:38 pm on Nov 30, 2004 (gmt 0)

Junior Member

10+ Year Member

joined:July 18, 2003
posts:63
votes: 0



Page A can have a PHP automatic redirect to Page B. So, as soon as the visitor hits Page A - they will be redirected to page B.

I'm afraid this isn't going to make much of a difference either. To do the redirect server side would mean sending out a 301 or 302 header to the client. This is easily readable on any script I might write to collect the page, and in fact, on many utilities used to simulate a web browser, these can be automatically followed just like the browser.

This means that if my script collected page A, and you redirected to page B, my script would happily redirect as well and then collect the source from page B. This means that not only would this not work, many people may not even realise you did it :)

This 72 message thread spans 3 pages: 72