With all the recent hype about JavaScript and HTML5 replacing Flash, I wanted to know - How would it be possible to protect client-side js code? Of course, it is possible to obfuscate it, but that would only make it a little harder. Also, for games which submit high scores to the server, wouldn't it be incredibly easy to modify those scores before they are sent to the server? I know even Flash files can be decompiled, but they can be obfuscated and flash decompilation is not as easy as modifying data in JS - could be done easily using a plugin such as Firebug. I'd like to know everyone's views on this.
Javascript, being parsed on the client, is never 100% safe. There will always be ways to find out what it does. A few days ago I've even seen a tool which unpacks packed javascript so the only thing you can really do is using "ugly" variable names (or actually, make a javascript packer transform your "good" variable names into short/ugly/nonsense ones)
To protect game results, you have to move some of the game logic to the server so the client cannot send arbitrary results.
Summarizing it: Don't put secrets in javascript code and don't trust anything coming from the client - no matter if it's from a form or generated/submitted via javascript.
You say that for game that sends high scores to the server it would be too easy to modify javascript and forge request?
Except for case, when you use some cryptography on the client, it is the easiest way to forge such request not even analysing the script but sending false request itself. Everything you send between server and browser can be easily viewed on computer, analysed and changed.
Related
Is there a way to 'hide' structure and content of javascript objects?
I have fairly extensive JavaScript objects on my client side holding information about the users UI (and other things). It holds a lot of information about the resources that the user will be operating on. As it is, someone with Firebug can just open the console and see the structure of all that data. I'm not crazy about that for security reasons.
Are there any ways I can protect this data?
Thanks,
No, you cannot protect that data. Anything that can be seen and used by the browser can also be seen and used by a person inspecting what the browser has.
You really need to think about why is this a problem for you? If you're concerned about a man-in-the-middle snoop who might intercept that data, then you should run your connections over https.
If you're concerned about the end-user themselves seeing this data, I'd ask why are you concerned about that? It's the user's own state. There should be no secrets in there.
If you're concerned that the user might manipulate things to do things on your server that they shouldn't be allowed to do, then you need to implement protection on your server for things the user shouldn't be allowed to do. Clients cannot implement such protection because clients are, by definition, not secure in this regard.
If there is actually secure data on the client that the end-user themselves shouldn't have access to, then you need to rethink how your app works and keep that data only on the server. The client should only have data that is absolutely required to be on the client. It's possible to implement a UI with very little actual data in the client except specific fields that are being edited if you generate most of the UI server-side.
So ... in summary. Don't put data in the client that the end-user shouldn't have access to. Rethink how your app works if that's a problem. If the end-user can have access to it, then don't work. If nobody else should have access to it, then run your pages over https.
As for obfuscation, it's barely worth any effort. Obfuscation does not provide any true security as it can always be defeated. At best, it provides a level of annoyance to someone trying to look at your code. A determined hacker will be able to get through the obfuscation by just spending a little more time on it and running it through some tools. Certainly there is no harm in minifying your javascript code as that makes it smaller and makes it less readable by humans, but do not count it as any form of real security.
No, there is not.
However, you have some options:
You can obfuscate your javascript -- this will help slightly as it makes it harder to read and understand your code. There are plenty of good obfuscators out there. I advice against this!
You can minify your javascript -- this might look like an obfuscation method, but is not. It can easily be reverted back to readable javascript and is mainly intended for limiting bandwidth. I encourage this, but advice against it for this reason!
You can try to put as much of your sensitive data and code on your server. This might make sense, or it might not.
You can encrypt your data and decrypt it on-the-fly via your own javascript decryption library. Not a good idea, as it is fairly easy to by-pass this security and it is resource intensive. However it will slightly discourage "theft" of your data. I strongly advice against this!
If you can accept to only target Google Chrome (for now) or Chromium, you can implement your code and data in Native Client, which basically is compiled C code running in a sandbox in your browser (Chromium/Chrome). The only way to get access to your code is decompilation. If you are really paranoid over data theft, you can obfuscate your C code before compiling, to try to kill debuggers from snatching your data, and possibly fetch all your data over SSL from your server in real time rather than having it in your binary.
Though, remember, even with option 5 there are ways to claim your data, though it will be very few who both have the will, time and know-how to get it.
And also remember, if you are looking for a way to conceal sensitive data on the web, it is highly likely you have thought out your solution wrongly. Never ever put sensitive data on the client or use client side verification as your only verification. Perhaps the web is not the platform you are looking for? Perhaps you're looking for a distributed solution?
If it's a security concern, don't send it to the client. Even if you obfuscate it, you're not making it more secure.
Obfuscation can only get you so far, because the nature of Javascript is that it is downloaded to the user's system so that their browser (and user) can read it. Making something harder to read is not hiding it completely. You cannot encrypt it without giving your users some way to decrypt it, thus defeating the purpose. What you're looking for is a server-side language that's compiled before the user sees it, such as PHP, Python, Java, etc.
No, not really. You can obfuscate, pack and do all kinds of stuff to make the source code harder to read. Hell, you can even give your objects really weird and indescript properties. But that's it really, you only make it harder to read. The data is there, and a determined attacker can find out what he wants if sensitive data is sent to the client.
So don't store sensitive data client side. Anyway, what's so horribly secret about UI state? If a user wants to break his state, let him?
I would not suggest to try to obfuscate the javascript logic. But you can minify it (i.e. uglifying it). at least you would make it more difficult to read.
If you are concerned about the security of your client side code, then there is no way but to use server side code. Perhaps making more code available through services and then calling your services through $.ajax or someting similar.
I am working on an in-browser game, taking advantage of the Canvas available in HTML5. However, I realized that I have a big vulnerability in the system. The game score and other statistics about game play are calculated on the client-side in Javascript, then submitted to the server for storage and comparison to other players through XMLHTTPRequest. This obviously exposes the statistics to manipulation and potential cheating.
I am worried about moving these to the server-side due to latency issues. I expect the timing to be close.
Are there other smart ways to deal with this problem? I imagine more and more games will deal with this as HTML5 grows.
Not really. Your server in this scenario is nothing more than a database that trusts the client. You can obfuscate but people will be easily able to figure out what your api is doing. This is an intractable problem with all standalone games, and is why for example, you see Blizzard making Diablo3 a client-server game. The fact that it's a javascript game just makes it even more transparent and easy for people to debug and exploit.
Why don't you just send data to the server every time the client scores a point and then keep a local score of points.
Unfortunately there is not much you can do about this. Minifying/obfuscating your code is always a good option. I'm not entirely sure, but I think putting your code inside
(function() { /* code */ })();
should protect any variables from users editing (unless you have them attached to an object like window). But users can still exploit your ajax call and send whatever score they want to the server. Just, never trust anything that is done client side. Validate everything server-side.
EDIT: Another thing I thought of: maybe generate a code server-side, and send that to the browser. Then with every ajax-call send that code to verify that it is you and not some malicious user.
The 100% security is not achievable when you have to trust to data from client. However, you can make it hard to cheat by obfuscating the js code and also the data that you send from client.
I have got an idea that is similar to gviews comment.
On the server, you should keep track of the players process of the game by batch updates, that you will send from client regularly in some interval... Player will not recognize it in the latency, and you will have the tool to detect obvious cheaters. You know the starting point of the players game, so you can easily detect the cheating right from the beginning.
Also, i would suggest to use some checkpoints where you would check the real state of the game on client and the state on the server. (the state of the client would not change if the cheater changes only the server updates by xhr).
There is lot of ways to make it harder to cheat, and it is quite individual for each game... there is no standard that solves it all.
When I say "Vanilla Coding", I am referring to websites that don't utilize server side coding (such as PHP, ASP, etc.), only HTML, JavaScript, and CSS.
I know that there are a plethora of sites that already exist that don't utilize (to my knowledge) any of the common, server side languages used by many others (PHP, ASP, etc.), but still function just fine!
I am confused! How do these sites continue to save login information, keep records, etc. etc. without using a server side scripting language? Is there something that I am missing? Can JavaScript access more (such as databases and local files) than what I thought it could?
EDIT
Turns out I've made a serious and shameful mistake in assuming that just because it ended with a .html extension that it was client-side only. That is okay though because I'm learning. Thanks so much for the help everybody!
Essentially, unless you have some sort of server-side programming, you don't stand a chance at making a site with any amount of functionality. To break it down for you:
What you can do without server-side scripting:
Serve static pages
What you need server-side scripting for:
Absolutely everything else
Even something so simple as keeping a site consistent and up to date is a nightmare on wheels without, at the very least, some some sort of management system that pre-generates the static pages to be served. (Technically, one could argue that Copy+Paste in Notepad counts as this.)
As has been mentioned elsewhere; obfuscating the true nature of precisely what system is being used is trivial; and having URLs ending in, say, .html while using PHP is no issue.
Edit: In the most perverse case I can think of off the top of my head, you could have a lighttpd server masquerading as an IIS server, serving pages generated by an offline renderer fed to it by a Perl FastCGI script, sent together with PHP signature heading and using a mix of .asp and .jsp file extensions.
Of course, noone would do something as silly as that. I think…
No client side script can access server side information (like a database) without some sort of server side communication (through something like ajax or the like)
If you really ( i mean really as in don't do it ) want to do logins and the like on clients side, you would have to make some sort of cookie that you store on the user's computer, also you would need a list of users (which anyone can read) to use against
This answer is very late but I leave this reply for anyone who may stumble upon it.
Using javascript/jQuery, and various APIs a simple site can be created only using client-side coding.
For instance, a simple shopping cart type of site can be created. I've done it before.
There are few (not many) strictly 100% jQuery based shopping cart solutions that are open-source.
How does the PG (pay gateway) get taken care of? You are limited to accepting payment through paypal, google checkout, and direct deposit.
What about allowing customers to leave comment? You can use API's like Disqus. What about chat support? Zopim is pretty handy.
How do you get notified when purchase is made? Paypal & google checkout notifies you.
What about sending mass email? Mail Chimp.
Personally, I almost always use WordPress or some other types of CMS but using only vanilla coding to build a simple site is not only feasible but very sensible in certain circumstances.
You're not going to see whether a site is using a server side language unless they let you see the file extensions. With URL rewriting, MVC patterns, etc., it's easy to hide, or even fake that information. Therefore, chances are very good that the sites that you think aren't using a server side language are actually using one.
Now, a site can save certain information in cookies, such as some basic preferences, but any authentication they appear to be doing wouldn't actually be doing anything without a server-side script accessing a database somewhere.
As a side note - I have worked on a site where the content was actually static, but made to look like a blog or CMS. It was an absolute nightmare and hugely error-prone.
What are these sites that you think aren't using server-side scripting?
Nowadays a lot of sites are using Javascript as a server side solution, Node.js being the most popular. Check out this list: https://github.com/joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node
I'm thinking of implementing my web application in a certain way as an optimization, and I'd like to get people's opinions on whether this is a good idea or not.
Here's the details:
For most of my pages, instead of determining server side whether the user is logged in, and then modifying the page I send based on that, I want to send the same page to everyone, this way I can make use of my reverse caching proxy and for most requests not even have to run any dynamic code at all.
The differences that need to be done for logged in users will be done in javascript. The necessary information to make the changes (what their user name is, their user id, and if they are logged in or not) will be stored in a cookie that can be read by javascript.
I don't need to worry about the users not having javascript because my web app requires javascript to be used anyways.
Only the most popular pages that are accessible to both logged in and logged out users will do this.
What do you guys think? Pros/cons? Is this something that websites commonly do?
Doing it for 100% of your application would be a little problematic, however, it sounds like you are seeking to use something called the Model-View-Presenter pattern:
http://en.wikipedia.org/wiki/Model_View_Presenter
Be wary that, when using javascript, your code is exposed, meaning that any security measure taken is potentially hackable through the browser. Add protection on the server side and you are set.
Also, since you are going to rely heavily on javascript, I really recommend you using Mootools, which is an object-oriented approach to javascript. That way you can keep your code really modular, work around messy implementations using custom and class events, etc.
Major con: If you are determining what content a viewer can access with JavaScript alone, it stands to reason that a malicious user can potentially access premium content with just a little glance at your source code.
I'm not sure what you are optimizing really - you need to fetch the user data anyway, and only the server has that. Do you plan on sending an AJAX request requesting for data and using javascript to format it? you are only saving on output generation which is usually not the bottleneck in web application. Much more often the database / IO (files) / network (HTTP requests) are the bottlenecks.
The major con here is that by moving all output generation to javascript, you will increase substantially the download size and reduce overall responsiveness. Since none of the big sites use this approach, you can be sure it doesn't solve scalability problems.
I have got a particular requirement where some critical algorithms have to be handled in the client-side script and it got to be secured. Using javascript will just expose the algorithm. I am currently evaluating ways to secure the algorithm on the client script. Appreciate any suggestions and alternative approaches.
One option I am thinking about is to download a small applet to the local PC, get the calculations done in it and update the results back. Before deciding on this, I want to know if a client script itself can be made secure coz that would be much easier.
Thanks in advance!
You CANNOT secure anything on a client PC.
Everything you are doing client-side is crackable and spuffable.
That's the PC of the client. It will be doing anything the client has requested it to do.
Script is not secure, also what level of security do you need? If you download anything to the client the client will be able to look at the algorithim. Of course if you download a native dll, then decompiling it will be harder, the question is if this is good enough.
That an important thing most people miss when evaluating security nothing is trully 100% secure. Because your server admin could go in and steal the binaries off your server. And if your using third party hosting who knows who has access to the server.
The idea is to raise the bar. Do you want to prevent the average script kiddie? Obfuscate it, make it hard for them to understand the gain of understanding the algorithim might not justify the pain in trying to understand it.
The best that you can probally do is keep the algorithim on the server and expose it via a web service.
Everything that the end-user is controlling to 100% may be tampered with, and this is especially true with JavaScript that is so easily exposed.
You are going down the wrong path. You need to rethink your approach.
You could build a web-service containing the critical algorithm and call it from javascript.
Bottom line is, if someone wants your logic ... they will get it unless it is server-side and they never obtain it in any way.
What you want is a Javascript obfuscator
Nothing on the client side can be totally "secure".
Anything you make them download will have to be run on the client PC, and so can be analysed. If you have them download an applet or a native executable, it will still contain machine instructions that can be analysed at the very least to an assembly level.
Is there no way you can have the client upload the data to your server instead and perform the calculation on the server side?
It it's client-side, then it's not secure. Anything with critical security concerns should be done on the server.
An NPAPI plugin will execute on the client-side and make reverse-engineering much more difficult.... but of course a determined hacker will be able to reach-through...
Theoretically (and I mean this is a Comp.Sci. sense) this is possible. The cryptographical technique is known as "fully homomorphic encryption". For now, the method isn't practical yet. There are no compilers available that are able to transform your algorithm in its equivalent secure form.