By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,630 Members | 1,313 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,630 IT Pros & Developers. It's quick & easy.

Hiding my javascript

P: n/a
I have developed a javascript application that can be used by my clients just by inserting the following in one of their web pages:

<script>
document.write('<iframe src="http://www.dynamicwebsitesystems.com/PGSampleTable.asp"></iframe>')
</script>

Anyone looking at the page containing the above will only see the the above lines, not all the javascript source. Someone with a little more savy though could just paste http://www.dynamicwebsitesystems.com/PGSampleTable.asp into their browser and then they will see the javascript.

Is there some way that my PGSampleTable.asp could know it has been called from outside the iframe and then just not serve the javascript?

Any other way to hide your javascript? (The above is only a prototype, it will eventually be a full costing system for the printing industry - I don't want anyone else to be able to steal it!)

Sep 19 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a

"Simon Wigzell" <si**********@shaw.ca> wrote in message news:cfFXe.524275$s54.368146@pd7tw2no...
I have developed a javascript application that can be used by my clients just by inserting the following in one of their web pages:

<script>
document.write('<iframe src="http://www.dynamicwebsitesystems.com/PGSampleTable.asp"></iframe>')
</script>

Anyone looking at the page containing the above will only see the the above lines, not all the javascript source. Someone with a little more savy though could just paste http://www.dynamicwebsitesystems.com/PGSampleTable.asp into their browser and then they will see the javascript.

Is there some way that my PGSampleTable.asp could know it has been called from outside the iframe and then just not serve the javascript?

passing a parameter ???
Sep 19 '05 #2

P: n/a
Simon Wigzell said the following on 9/19/2005 4:32 PM:
I have developed a javascript application that can be used by my clients
just by inserting the following in one of their web pages:

<script>
document.write('<iframe
src="http://www.dynamicwebsitesystems.com/PGSampleTable.asp"></iframe>')
</script>
And if JS is disabled or not present? Then the app is broken.
Anyone looking at the page containing the above will only see the the
above lines, not all the javascript source. Someone with a little more
savy though could just paste
http://www.dynamicwebsitesystems.com/PGSampleTable.asp into their
browser and then they will see the javascript.
Yep, thats how the web works.
Is there some way that my PGSampleTable.asp could know it has been
called from outside the iframe and then just not serve the javascript?
No.
Any other way to hide your javascript?
Delete it from your hard drive, delete it from your servers, then it
can't be seen. If it's on a website, it can be seen.

(The above is only a prototype, it will eventually be a full costing
system for the printing industry - I don't want anyone else to be able
to steal it!)


Then don't deploy it on the web. And do not fall prey to the likes of
people who will attempt to tell you that the commercial product they
sell can do what you want, it can't. Ira Baxter is the first name that
comes to mind.

But, I do not even need to load it independently, I only need to know
how to read the source from my cache while the pages is open and you can
not stop that.

If someone manages to tell you that "obfuscation" will help you, try the
obfuscation on a test page, open it in IE, then paste this into the toolbar:

javascript:'<code><ol><li>'+(document.documentElem ent||document.body).outerHTML.replace(/&/g,"&amp;").replace(/</g,"&lt;").replace(/%20%20/g,"&nbsp;%20").replace(/(\n\r?|\r)/g,"<li>")+'<\/ol><\/code>';

And press GO and find out how "safe" your code is.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Sep 19 '05 #3

P: n/a

"Zoe Brown" <zo***********@N-O-S-P-A-A-Mtesco.net> wrote in message news:r6******************@newsfe1-win.ntli.net...

"Simon Wigzell" <si**********@shaw.ca> wrote in message news:cfFXe.524275$s54.368146@pd7tw2no...
I have developed a javascript application that can be used by my clients just by inserting the following in one of their web pages:

<script>
document.write('<iframe src="http://www.dynamicwebsitesystems.com/PGSampleTable.asp"></iframe>')
</script>

Anyone looking at the page containing the above will only see the the above lines, not all the javascript source. Someone with a little more savy though could just paste http://www.dynamicwebsitesystems.com/PGSampleTable.asp into their browser and then they will see the javascript.

Is there some way that my PGSampleTable.asp could know it has been called from outside the iframe and then just not serve the javascript?

passing a parameter ???

No, the parameter would be visible in the source.
Sep 19 '05 #4

P: n/a
alu
"Simon Wigzell" <si**********@shaw.ca> wrote
Is there some way that my PGSampleTable.asp could know it has been called

from outside the iframe and then just not serve the javascript?

-------------------------------------------------------
It's basically impossible to hide script (probably a good thing),
but to make it a bit more difficult to access casually,
within PGSampleTable.asp <head> you could insert a kickout;
something like:
if (self == parent) {self.location.href="parentpage.html"}

// or some other variation

if (self == top) {top.location.href = "parentpage.html"}

------------------------------------------------------

It's not foolproof of course (disabling javascript will still give anyone
access).
For fun, I've converted entire scripts to hex, but really,
anyone with patience can decode it.
-alu
Sep 20 '05 #5

P: n/a
Simon Wigzell wrote:
I have developed a javascript application that can be used by my clients
just by inserting the following in one of their web pages:

<script>
document.write('<iframe
src="http://www.dynamicwebsitesystems.com/PGSampleTable.asp"></iframe>')
</script>

Anyone looking at the page containing the above will only see the the
above lines, not all the javascript source. Someone with a little more
savy though could just paste
http://www.dynamicwebsitesystems.com/PGSampleTable.asp into their
browser and then they will see the javascript.

Is there some way that my PGSampleTable.asp could know it has been
called from outside the iframe and then just not serve the javascript?

Any other way to hide your javascript? (The above is only a prototype,
it will eventually be a full costing system for the printing industry -
I don't want anyone else to be able to steal it!)

In addition to what Randy posted:
If you consider your formulas of any value - do your calculations
server side. Also better from accessibility standpoint.

--
Vladdy
http://www.klproductions.com
Sep 20 '05 #6

P: n/a
Simon Wigzell wrote:
I have developed a javascript application that can be used by my clients
just by inserting the following in one of their web pages:

<script>
document.write('<iframe
src="http://www.dynamicwebsitesystems.com/PGSampleTable.asp"></iframe>')
</script>

Anyone looking at the page containing the above will only see the the
above lines, not all the javascript source. Someone with a little more
savy though could just paste
http://www.dynamicwebsitesystems.com/PGSampleTable.asp into their
browser and then they will see the javascript.

Is there some way that my PGSampleTable.asp could know it has been
called from outside the iframe and then just not serve the javascript?

Any other way to hide your javascript? (The above is only a prototype,
it will eventually be a full costing system for the printing industry -
I don't want anyone else to be able to steal it!)


Offiscation could be interesting. Heres a variation on something
I've used before

When the browser first fetches
http://www.dynamicwebsitesystems.com/PGSampleTable.asp
with no arguments have it output something like

<script>
var szSerialNo="SN";for(i in top){ee=eval("top."+i);
if(typeof ee=='number')szSerialNo+=ee+String(i).substring(0, 1);}
document.location.href=document.location.href+"?"+ szSerialNo
</script>

This will result in a second call something like
http://www.dynamicwebsitesystems.com...asp?SN105s0l4s

Now depending on this value you can send back script for your
application or a fake script for the nozy to stare at.

The reason to have a fake script is to keep the curious
from realizing what exactly you did.

The clue for your asp script is checking for the presence
of "0l" That's the number "1" fallowed by the lowercase
letter "L" in the faux serial number. This indicates no frames

There are more things you can do to verify the serial number
but the idea is not to let the nozy person know what your looking for.

--
--.
--=<> Dr. Clue (A.K.A. Ian A. Storms) <>=-- C++,HTML, CSS,Javascript
--=<> http://resume.drclue.net <>=-- AJAX, SOAP, XML, HTTP
--=<> http://www.drclue.net <>=-- SERVLETS,TCP/IP, SQL
--.
Sep 20 '05 #7

P: n/a
Dr Clue wrote:
The clue for your asp script is checking for the presence
of "0l" That's the number "1" fallowed by the lowercase
letter "L" in the faux serial number. This indicates no frames


typeo , that should be

( "0l" That's the number "0" fallowed by the lowercase "l" )

--
--.
--=<> Dr. Clue (A.K.A. Ian A. Storms) <>=-- C++,HTML, CSS,Javascript
--=<> http://resume.drclue.net <>=-- AJAX, SOAP, XML, HTTP
--=<> http://www.drclue.net <>=-- SERVLETS,TCP/IP, SQL
--.
Sep 20 '05 #8

P: n/a

"Simon Wigzell"
Any other way to hide your javascript? (The above is only a prototype,
it will eventually be a full costing system for the printing industry - I

don't want anyone else to be able to steal it!)

geesh what's the big deal...if you have to ask this q
your stuff aint sophisticated enough to be worth "stealing"


Sep 20 '05 #9

P: n/a
JRS: In article <PTKXe.7183$LV5.7178@trndny02>, dated Tue, 20 Sep 2005
02:56:47, seen in news:comp.lang.javascript, Vladdy
<vl**@klproductions.com> posted :
If you consider your formulas of any value - do your calculations
server side. Also better from accessibility standpoint.


Not necessarily. A page with reader-side calculation can be fetched and
later operated off-line, and operating off-line is becoming more
important as the number of portable computers increases.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Sep 20 '05 #10

P: n/a
Dr Clue wrote:
<snip>
<script>
var szSerialNo="SN";for(i in top){ee=eval("top."+i);
if(typeof ee=='number')szSerialNo+=ee+String(i).substring(0, 1);}
document.location.href=document.location.href+"?"+ szSerialNo
</script>

This will result in a second call something like
http://www.dynamicwebsitesystems.com...asp?SN105s0l4s

Now depending on this value you can send back script for
your application or a fake script for the nozy to stare at.

The reason to have a fake script is to keep the curious
from realizing what exactly you did. <snip> There are more things you can do to verify the serial number
but the idea is not to let the nozy person know what your
looking for.


Given that pulling the files actually downloaded from the browser's
cache is a fairly normal strategy for examining complete 3rd party
scripts, this will be a less than successful strategy.

But since Simon Wigzell frequently asks trivial questions on this group
it is likely that his expectation of interest in his script greatly
exceeds reality, and that much of that script is not actually his own
work anyway.

Richard.
Sep 21 '05 #11

P: n/a
Richard Cornford wrote:
Dr Clue wrote: <snip> Given that pulling the files actually downloaded from the browser's
cache is a fairly normal strategy for examining complete 3rd party
scripts, this will be a less than successful strategy.


I think the key word in my response was "Offiscation".
Of course one could do so even further by getting
the scripts via post , fiddling with the cache headers
and having faux versions of key functions that overlay
one another.

But heck , much of this stuff is like cheap bicycle locks,
in that they are meant to discourage theft, but can hardly prevent it.

--
--.
--=<> Dr. Clue (A.K.A. Ian A. Storms) <>=-- C++,HTML, CSS,Javascript
--=<> http://resume.drclue.net <>=-- AJAX, SOAP, XML, HTTP
--=<> http://www.drclue.net <>=-- SERVLETS,TCP/IP, SQL
--.
Sep 21 '05 #12

P: n/a
Dr Clue wrote:
Richard Cornford wrote:
Dr Clue wrote: <snip>
Given that pulling the files actually downloaded from the
browser's cache is a fairly normal strategy for examining
complete 3rd party scripts, this will be a less than
successful strategy.


I think the key word in my response was "Offiscation".
Of course one could do so even further by getting
the scripts via post , fiddling with the cache headers


If it is in the browser it is in the browser's cache, so post requests
and fiddling with headers will make no difference (except that implied
need to repeatedly download the same script would represent a needless
(and pointless) performance hit).
and having faux versions of key functions that overlay
one another.
But given the full set of scripts and HTML (and images, etc) from the
cache it is not that difficult to work out what is going on.
But heck , much of this stuff is like cheap bicycle locks,
in that they are meant to discourage theft, but can hardly
prevent it.


If you use a cheep bicycle lock in London your bicycle _will_ be stolen,
no question about it (unless it is self evidently such a wreck that an
observer would not believe it was even functional).

The whole obfuscation business is protection against individuals who
don't know enough to actually have a use for any script they discover.
Once they have learnt to understand and use any script they may find
they have learnt enough to defeat any 'protection'. After all, the
ability to search with google is pretty much all that is required.

Richard.
Sep 21 '05 #13

P: n/a
Richard Cornford wrote:
Dr Clue wrote:

<snip
But heck , much of this stuff is like cheap bicycle locks,
in that they are meant to discourage theft, but can hardly
prevent it.


If you use a cheep bicycle lock in London your bicycle _will_ be stolen,
no question about it (unless it is self evidently such a wreck that an
observer would not believe it was even functional).

Thats exactly why the asp script would return the
faux code (crappy bike).

This faux code would would have enough code to look genuine
perhaps having deliberately flawed yet running functions.

So as far as the person doing a view-source , is concerned
they've stolen my crappy bike, and have no reason to suspect
that the crappy bike is a sham that hides my good bike.
--
--.
--=<> Dr. Clue (A.K.A. Ian A. Storms) <>=-- C++,HTML, CSS,Javascript
--=<> http://resume.drclue.net <>=-- AJAX, SOAP, XML, HTTP
--=<> http://www.drclue.net <>=-- SERVLETS,TCP/IP, SQL
--.
Sep 21 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.