www.webdeveloper.com
Results 1 to 8 of 8

Thread: the (il?)legitimacy of hiding your javascript

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Location
    Wisconsin
    Posts
    2,120

    the (il?)legitimacy of hiding your javascript

    It's not uncommon that we stumble across a new thread asking how to hide source code. And, out of curiosity, I've been playing with some strategies and pondering to what extent client-side code can be hidden. I've made more progress than I expected, but I also see pretty clearly where the journey ends (customized browser). So, I've become curious as to what strategies other developers have been using to address some of the concerns that source-hiding might be used to address:


    API Protection
    If you can hide an API key in the source, you can use it to sign requests and ensure that they originate from your code, which can be tied to a domain or page, theoretically without relying on the HTTP referer header, which I'm lead to believe is pretty unreliable. (Does anyone know if the FB API, for instance, required a referer header alongside the API key when used client-side?)

    Anti-Cheat
    Three general concerns here: hiding "the goal" when "the goal" can't realistically be checked on the server due to the frequency of the check; protecting the game logic from tampering; protecting the API from spoofed events (same as API protection above).

    Internal Property Protection
    Most "owned" algorithms [or data] should simply be operated [on] server-side. But, if one such set of algorithms [or data] is useful only at a high frequency of use (tens, hundreds, thousands, millions of times per second, etc.), it may need to operate client-side. But, your business may be built on creating and maintaining those algorithms and/or data. And if they're trivial to siphon off the site, as JavaScript usually is, your clients may feel they only need to pay for a month's subscription.

    Copy Protection
    An application built on the KISS principle is often easy to steal, in part or entirely. There may be very few individual scripts and images involved. Thus, the application may simply be lifted and dropped on another site. It may be modified and used to spoof the original site or steal business.

    User Data Protection
    As a curtesy to visitors, you may want to project against aggressive script/request caching by sending a user's more sensitive information in a hidden format, one that is later un-usable after the page is not active in the browser.


    What methods are currently in play to address these sorts of concerns? If your answer entails legal action or cautions, please describe the theft/cheat/scam-detection methods you'd use to catch your TOS infringers.

    Are there any other concerns you would add to the list? How do you currently address them?

    Is anyone of the mindset that scripts should all be as open and obvious as possible, so that if anyone can cheat/hack the system, everyone can, ensuring that no one has special privileges on account of their hacking skills?

    Is anyone of the mindset that any or all of the above concerns are best protected by "keeping things fresh?" I.E., that keeping the site/application updated on a regular basis discourages theft, cheating, hacking, etc.?

    Anyone interested to see, test, and criticize my feeble educational pursuits in the matter?

    Thanks!
    Jon Wire

    thepointless.com | rounded corner generator

    I agree with Apple. Flash is just terrible.

    Use CODE tags!

  2. #2
    Join Date
    Nov 2002
    Posts
    2,632
    Quote Originally Posted by svidgen View Post
    It's not uncommon that we stumble across a new thread asking how to hide source code.
    It's why there is a sticky thread about the subject. Personally speaking, I like learning from people and their code. I'll never understand why people seem to want to go such great lengths to hide their code.

  3. #3
    Join Date
    Jan 2007
    Location
    Wisconsin
    Posts
    2,120
    Quote Originally Posted by spufi View Post
    I'll never understand why people seem to want to go such great lengths to hide their code.
    As indicated above, source hiding could potentially simply assist in hiding API or signing keys, prevent cheating, or apply another layer of security to user data. In those particular cases, it's not necessarily about hiding anything you'd care to learn from.

    But, thanks for your response, which addresses two of the concerns (IP protection and Copy Protection) with the usual response.
    Last edited by svidgen; 04-10-2012 at 12:53 PM.
    Jon Wire

    thepointless.com | rounded corner generator

    I agree with Apple. Flash is just terrible.

    Use CODE tags!

  4. #4
    Join Date
    Feb 2003
    Location
    Aberdeen, Washington, USA
    Posts
    1,859
    I've always thought this was kinda cool: mathiasbynens.be/demo/css-without-html
    Obviously not good for a real world scenario though...

    Not really a direct response though... But, in my opinion, if you need to hide your client-side code because it contains sensitive information, "you're doing it wrong™".

  5. #5
    Join Date
    Jan 2007
    Location
    Wisconsin
    Posts
    2,120
    Quote Originally Posted by Jick View Post
    But, in my opinion, if you need to hide your client-side code because it contains sensitive information, "you're doing it wrong™".
    I generally agree. But, I'm not really looking for folks to jump on the source hiding is evil, stupid, and impossible bandwagon. I'm looking for serious alternatives that address the concerns for which source hiding is often proposed. Because I'm fully ware that at the end of the day, the browser needs to read the code to execute it. So, a modified browser (or plugin) can in theory be easily made to dump any and all script that's executed.

    So, given that there are active concerns, of which I presume there are best-practice solutions, you can interpret the question not as, how do we hide our code, but how do we address these concerns, assuming that source code hiding is more of a business man's fantasy than a reality.

    If the proposition of source code hiding means you're doing it wrong, what's the right way to do it? If you can even supply the best practice (preferably with some citation) on any one or two of the items, I'd appreciate it.
    Jon Wire

    thepointless.com | rounded corner generator

    I agree with Apple. Flash is just terrible.

    Use CODE tags!

  6. #6
    Join Date
    Jan 2007
    Location
    Wisconsin
    Posts
    2,120
    Quote Originally Posted by Jick View Post
    I've always thought this was kinda cool: mathiasbynens.be/demo/css-without-html
    Obviously not good for a real world scenario though...
    I forgot to ask: What am I supposed to be seeing here? I see nothing. Nothing at all ...


    ADDENDUM: Nevermind. Found the article. Tried it in FF. Cute trick.
    Last edited by svidgen; 04-10-2012 at 11:24 PM.
    Jon Wire

    thepointless.com | rounded corner generator

    I agree with Apple. Flash is just terrible.

    Use CODE tags!

  7. #7
    Join Date
    Aug 2007
    Posts
    3,767
    Someone, JMarker I think, used to have a sample page where the JavaScript was encrypted with an asymmetric encryption algorithm (RSA I think) and then decrypted and ran provided the correct password was entered. Doesn't address hiding the JavaScript obviously, but is a way to hide information using JavaScript alone.

    For user data protection, some "No cache" headers should do the trick?
    Great wit and madness are near allied, and fine a line their bounds divide.

  8. #8
    Join Date
    Jan 2007
    Location
    Wisconsin
    Posts
    2,120
    Quote Originally Posted by Declan1991 View Post
    Someone, JMarker I think, used to have a sample page where the JavaScript was encrypted with an asymmetric encryption algorithm (RSA I think) and then decrypted and ran provided the correct password was entered. Doesn't address hiding the JavaScript obviously, but is a way to hide information using JavaScript alone.

    For user data protection, some "No cache" headers should do the trick?
    Thanks for the feedback.

    I've actually been able to perform some semi-reasonable code-hiding just using a DH key exchange and some really simple 8-bit XOR "encryption." Nabbing source code becomes a little annoying. And while a more serious encryption could prevent brute-forcing the key, it's probably just easier for most folks to just find the decoded script using a debugger anyway:

    http://staging.svidgen.com/hidden_javascript_demo

    If you've got FireBug or Chrome, you can likely find the decoded source in a matter of minutes, if not seconds. If you can't happen to catch the source, the encryption key is also pretty easy to get ahold of.

    So, in terms of securing user data, if a stronger key and encryption algorithm were used, I think user data is sufficiently protected from aggressive caching without asking for an additional password, or even sending a decryption key. The user data would be usable only for the duration of the page-load.

    But, after taking a peek at my Gmail DOM, it looks like Google isn't worried about this sort of thing at all -- or at least they don't think my email is worth protecting. In fact, a quick look reveals that my initial inbox view is sent pretty plainly in the initial request.

    For user data protection, some "No cache" headers should do the trick?
    So yeah, that's probably right. If browsers aren't respecting those headers, to hell with 'em! At least for normal application. If anyone's looking for an ultra-high security solution, a DH key exchange and/or an addition password-based encryption key might be necessary.

    Regarding the other issues, I think the average developer could be left searching for a good long time with a little added trickery and stronger encryption. The keys and decoded script, for instance, could theoretically be used without storing them in a named variable, which could make finding them very difficult. You could further complicate things by override the toString() and/or valueOf() methods to alter important values immediately after their first use -- upon execution, for instance.

    But again, this all just delays the inevitable, making it difficult or tedious for someone to find the source (potentially very tedious). Ultimately, the browser executes JavaScript, so the browser needs to see the JavaScript. Any amount of work put into hiding the script can just as easily be undone by a skilled FireBug user (or just an update to the plugin that exposes timeout code in the same manner that eval code is exposed).

    So, without code-hiding solutions, I'm interested to know what folks do to address these three concerns in particular:

    API Protection
    reliance on referrer header?
    reliance on browser compliance with cross-domain scripting policies?

    Anti-Cheat
    obfuscation?

    Copy Protection
    frequent, "deep" dependence on server-side functionality?
    any clever ways to create an artificial dependence when no true dependence is necessary?

    Sorry for being rambly ...
    Last edited by svidgen; 04-13-2012 at 04:51 PM. Reason: i keep typing DF when I should be typing DH ...
    Jon Wire

    thepointless.com | rounded corner generator

    I agree with Apple. Flash is just terrible.

    Use CODE tags!

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center



Recent Articles