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.
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.
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
It's quite hard for me to figure out if this sort of thing has ever been implemented. I want to look for any libraries that may exist so I don't go about reinventing the wheel.
I have this idea of having a web app that connects the people who are on the site. Every user that is connected to the site may communicate to another user also on the site via the server. So the protocols will be implemented in JavaScript, and the server simply helps to identify users, and just echoes data to enable the communication. For instance I can use this to implement my game networking ideas in javascript, and easily test them without having my testers download any executables, they can just log onto the site.
Now obviously this isn't going to be an effective architecture for any kind of serious application. But I think if I can get it working I could build really cool networking apps without having any sort of download.
What I'm thinking about is using ajax for client->webserver and webserver->client (Comet?) and I can code up the webserver echo bit with PHP or a cgi script. And then I can implement an entirely separate protocol in JS that the webserver does not care or know about.
The reason for having the webserver echo everything is because I don't want to use java or anything else that I can open up sockets in. Why make it harder for me? Because I can and because I happen to be really enamored with javascript at the moment. It's the only web technology I trust. Screw java applets.
Does this make any sense to anyone? Am I crazy?
Don't know about the crazy part (there's a proposal at area51, go check that) but it's definitely doable.
You could use a plain old XMPP server and a javascript XMPP client (there are libraries - for example strophe)
You could do it with AJAX and a PHP backend: Making an AJAX Web Chat
You could use the fancy Websockets from HTML5: Start Using HTML5 WebSockets
You could use some existing component if you can find any (I couldn't find any I would use)
Cheers :)
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.
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.