We're using node.js with express as a server gateway to AES256 individually encoded data. The data (and server code) are on a single server in a heavily locked room in our facility, accessible by hard wire ethernet only. Access points are dedicated hardwired devices. If someone were ever able to steal that server they could get access to the source code. They would have the keys and decoding algorithms to our encoded data.
What if we compiled the JavaScript node.js code and left only that on the server (instead of JavaScript source code)?
Does the compilation process offer enough security such that a motivated thief wouldn't be able to identify the encoding/decoding techniques that are in use to protect the stored encrypted data?
Does the compilation process offer enough security such that a motivated thief wouldn't be able to identify the encoding/decoding techniques that are in use to protect the stored encrypted data?
No.
First off, you don't say what you really mean by "compilation process". There is no process with Javascript that is analogous to compiling C++ into binary assembly code. Javascript is an interpreted language, not a compiled language. The Javascript interpreter may do a compile step internal to the JS engine, but that's not something you can do yourself. The node.js Javascript engine requires plain text legal Javascript as an input.
So, any compilation process you would run on your Javascript code would just be compacting and perhaps obscuring it. It's still plain text Javascript code. It's still runnable by anyone. Anyone can still diagnose what it does or how it works. Obscuring it (like replacing descriptive variable names with short one or two letter names) makes it a little more work to analyze the code and understand it, but it is only a temporary obstacle that can still be overcome by any determined hacker.
If someone were ever able to steal that server they could get access
to the source code. They would have the keys and decoding algorithms
to our encoded data.
You will need to physically secure access to your server and the code on that server in order to protect it and you will need to rely on that protection.
If you are using a packaging tool that creates a runnable .exe file, then keep in mind that that is not really compiling your Javascript. It's just packing it into a shell of a .exe so that the native code .exe can run, can extract your Javascript from within the .exe, can put that in a temp file on the hard disk and can then execute node.js passing it that Javascript source file. This is a packaging step, not a binary compilation step. Now, the package in the EXE may be binary compressed, but when the code is passed to node.exe it's still going to be plain text Javascript which can still be seen by a determined hacker.
Your problem is not properly mitigated that way. No matter how many jumps you'd make a bad actor jump through, it's still all on one server no matter how opaque.
Look into solutions where decryption requires a key that is never saved to disk on that machine, instead securely retrieved each time your application (or better yet, your entire server) starts such as hard drive encryption programs that must succeed before the main operating system can even load.
Related
I am using Javascript wrapped in HTML to simplify the task of one of my students. Her task is to create a text file for a research project, which will act as a configuration file for the analysis software.
I decided on Javascript, because I wanted portable, transparent code, with zero dependencies (no libs, no server, no installation), yet a familiar feel from the web that is easy to get started with. However, client side Javascript appears to have its limits when it comes to handling file output.
There are multiple questions and answers on Stackoverflow that address the issue by appealing to server-side solutions, external dependencies, and the newer HTML5 download element.
I have considered if I should use a complementary script or batch file that reads the output, but I am not sure about how to best implement such a layer. The file is complex to generate and this is achieved using form elements.
Another idea would be to package the script as an executable. For example, a browser could be called from Java, or the HTML/JS could be converted somehow. Perhaps there is a wrapper that I am not familiar with.
This is one of those side projects that is fast to code and so I would assume that there is a go-to solution among programmers for this type of problem. On the one hand, this is a packaging problem. On the other hand, it is about some of the limitations with Javascript for projects that run without a server backbone.
How can I deliver a no-bells-and-whistles Javascript application that is local only and capable of handling file I/O?
I have been using JS for simple front-end scripting for a while now, but am absolutely new to Node.js. After some surfing, I found out certain stuff about Node.js that it is fast, event-driven,uses modules, can be used both on server and client side, can be run from command line, etc.
As a project, the following task has been given to me:
"To develop a graph algorithm (such as minimum spanning tree) in javascript using node.js. Use the larger of the following graphs as inputs: http://snap.stanford.edu/data/ " [the link contains data from various network sites organised as nodes and edges and stored in .txt files]
Now I know how to implement a graph algorithm in a language (such as C), can even do it in JS using arrays. But I need some help regarding the "using node.js" part of the problem. What is its purpose in the problem ? Which of its features should I look up ?
Typically JS was made to run inside a browser.
Node.js is actually a javascript runtime invokable. You can invoke it from commandline. This means you can execute files of code from commandline like many other languages which you might be already familiar with. Beyond, that there is nothing much from your context.
But, yes it is fast, event-based, async and like server-scripting languages has server-handling capabilities inbuilt. That said it can be used for non-server contexts as well. Like computation in your case.
Node JS helps you to run backend logic, which is written on Javascript Language.
For example, in PHP, when you write backend code, you need some kind of application which will get all clients requests and run specific code to handle it. In PHP it will be done via Apache Server. In Java it will be done via Glassfish/JBoss/Tomcat.
Node JS is something like them, but for Javascript code.
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.
Now that JavaScript libraries like jQuery are more popular than ever, .js files are starting to contain more and more of a site's logic. How and where it pulls data/information from, how that info is processed, etc. This isn't necessarily a bad thing, but I'm wondering to what extend this might be a security concern.
Of course the real processing of data still happens in the backend using PHP or some other language, and it is key that you make sure that nothing unwanted happens at that point. But just by looking at the .js of a site (that relies heavily on e.g. jQuery), it'll tell a person maybe more than you, as a developer, would like. Especially since every browser nowadays comes with a fairly extensive web developer environment or add-on. Even for a novice manipulating the DOM isn't that big of a deal anymore. And once you figure out what code there is, and how you might be able to influence it by editing the DOM, the 'fun' starts.
So my main concerns are:
I don't want everyone to be able to look at a .js file and see exactly (or rather: for a large part) how my site, web app or CMS works — what is there, what it does, how it does it, etc.
I'm worried that by 'unveiling' this information, people who are a lot smarter than I am figure out a way to manipulate the DOM in order to influence JavaScript functions they now know the site uses, possibly bypassing backend checks that I implemented (and thus wrongly assuming they were good enough).
I already use different .js files for different parts of e.g. a web app. But there's always stuff that has to be globally available, and sometimes this contains more than I'd like to be public. And since it's all "out there", who's to say they can't find those other files anyway.
I sometimes see a huge chuck of JavaScript without line breaks and all that. Like the compact jQuery files. I'm sure there are applications or tricks to convert your normal .js file to one long string. But if it can do that, isn't it just as easy to turn it back to something more readable (making it pointless except for saving space)?
Lastly I was thinking about whether it was possible to detect if a request for a .js file comes from the site itself (by including the script in the HTML), instead of a direct download. Maybe by blocking the latter using e.g. Apache's ModRewrite, it's possible to use a .js file in the HTML, but when someone tries to access it, it's blocked.
What are your thoughts about this? Am I overreacting? Should I split my JS as much as possible or just spend more time triple checking (backend) scripts and including more checks to prevent harm-doing? Or are there some best-practices to limit the exposure of JavaScripts and all the info they contain?
Nothing in your JavaScript should be a security risk, if you've set things up right. Attempting to access an AJAX endpoint one finds in a JavaScript file should check the user's permissions and fail if they don't have the right ones.
Having someone view your JavaScript is only a security risk if you're doing something broken like having calls to something like /ajax/secret_endpoint_that_requires_no_authentication.php, in which case your issue isn't insecure JavaScript, it's insecure code.
I sometimes see a huge chuck of JavaScript without line breaks and all that. Like the compact jQuery files. I'm sure there are applications or tricks to convert your normal .js file to one long string. But if it can do that, isn't it just as easy to turn it back to something more readable (making it pointless except for saving space)?
This is generally minification (to reduce bandwidth usage), not obfuscation. It is easily reversible. There are obfuscation techniques that'll make all variable and function names something useless like "aa", "bb", etc., but they're reversible with enough effort.
Lastly I was thinking about whether it was possible to detect if a request for a .js file comes from the site itself (by including the script in the HTML), instead of a direct download. Maybe by blocking the latter using e.g. Apache's ModRewrite, it's possible to use a .js file in the HTML, but when someone tries to access it, it's blocked.
It's possible to do this, but it's easily worked around by any half-competent attacker. Bottom line: nothing you send a non-privileged user's browser should ever be sensitive data.
Of course you should spend more time checking back-end scripts. You have to approach the security problem as if the attacker is one of the key developers on your site, somebody who knows exactly how everything works. Every single URL in your site that does something to your database has to be protected to make sure that every parameter is within allowed constraints: a user can only change their own data, can only make changes within legal ranges, can only change things in a state that allows changes, etc etc etc. None of that has anything at all to do with what your Javascript looks like or whether or not anyone can read it, and jQuery has nothing at all to do with the problem (unless you've done it all wrong).
Remember: an HTTP request to your site can come from anywhere and be initiated by any piece of software in the universe. You have no control over that, and nothing you do to place restrictions on what clients can load what pages will have any effect on that. Don't bother with "REFERER" checks because the values can be faked. Don't rely on data scrubbing routines in your Javascript because those can be bypassed.
Well, you're right to be thinking about this stuff. It's a non-trivial and much misunderstood area of web application development.
In my opinion, the answer is that yes it can create more security issues, simply because (as you point out) the vectors for attack are increased. Fundamentally not much changes from a traditional (non JS) web application and the same best practises and approaches will server you very well. Eg, watching out for SQL injection, buffer overflows, response splitting, etc... You just have more places you need to watch out for it.
In terms of the scripts themselves, the issues around cross-domain security are probably the most prevalent. Research and learn how to avoid XSS attacks in particular, and also CSRF attacks.
JavaScript obfuscation is not typically carried out for security reasons, and you're right that it can be fairly easily reverse engineered. People do it, partially to protect intellectual property, but mainly to make the code download weight smaller.
I'd recommend Christopher Wells book published by O'Reilly called 'Securing Ajax Applications'.
There is free software that does JavaScript Obfuscation. Although there is not security though obscurity. This does not prevent all attacks against your system. It does make it more difficult, but not impossible for other people to rip off your JavaScript and use it.
There is also the issue of client side trust. By having a lot of logic on the client side the client is given the power to choose what it wants to execute. For instance if you are escaping quote marks in JavaScript to protect against SQL Injection. A Hacker is going to write exploit code to build his own HTTP request bypassing the escaping routines altogether.
TamperData and FireBug are commonly used by hackers to gain a deeper understanding of a Web Application.
JavaScript code alone CAN have vulnerabilities in it. A good example is DOM Based XSS. Although I admit this is not a very common type of XSS.
Here's a book by Billy Hoffman about Ajax security:
http://www.amazon.com/Ajax-Security-Billy-Hoffman/dp/0321491939/ref=sr_1_1?ie=UTF8&s=books&qid=1266538410&sr=1-1
Html can contain little bits of Javascript embedded in it (e.g. defined in onclick event handlers).
If I were writing an Html browser using a dotNet language like C#, what technologies or APIs could I use to run such Javascript fragments, given that I don't receive it until run-time (and receive it as string data, not as executable code)?
Is it any easier or harder if the code to be run were C# snippets rather than Javascript?
Is there any technique which doesn't require my code to have unusual priviledges? For example, a method like CodeCompiler.FromSource requires SecurityPermissionFlag.UnmanagedCode (which seems to me excessive: I don't see why it's so risky to compile code).
If I controlled the server-side as well as the client-side code, I could also consider compiling such script fragments on the server instead of on the client, and then sending it as precompiled code to the client side to be executed. Is there a way to send such code (a dotNet assembly, presumably) over the network to the client, have client-side code receive it from the network into client-side RAM, and invoke it on the client side without storing it as a file on a client-side disk drive?
Edit
I have answer to the first three questions: I've resigned myself to the fact that compiling takes high privileges. I don't see why; maybe (although I don't find this a very convincing reason) it's because the compiler is implemented using unmanaged code. Maybe this will change when they reimplement the compiler using managed code, in maybe the "C# version 5" timeframe. In any case, whatever the reason, that seems to be the way it is, and there are no work-arounds (other similar APIs but which require fewer privileges).
My remaining question then is how to get an Assembly instance from one machine to another. When I have time I'll find out whether untrusted code can run the Assembly.Load(byte[] rawAssembly) method.
Server side Javascript is one of the languages supported by the .NET platform. I used it many times in the scenrios when you need to insert small code snippets into existing code. Runtime it can be loaded from i.e. database and compiled, so there is no preformance penalty.
From the standpoint of making the plumbing work (retrieveing the source, compiling it, etc.) there is no difference. With strongly typed languages though it is much more difficult to assemble code snippets into a compilable compilation unit.
Permissions is certanly a challenge. I am not sure about the specific permission you mentioned, but security is a concern, after all the source you compile can be anything and if you are not careful about the source of your code it can become the backdoor into your system
The answer to this one is - yes of course. You can load an assembly from anywhere, not necessarily from a file, you can also compile in memory - that's what I do. There is no dll file in this case.
You're asking several questions, sort of, so I'll give you an idea on one of them.
There's a very good article and some code samples from:
http://www.west-wind.com/presentations/dynamicCode/DynamicCode.htm
which talks about compiling and executing C# code at runtime. I found it very useful and I am using this in a standard c# application. Seems like it would be usable for your problem as well.