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.
Related
I'm looking for a way to protect some javascript code from reading/modifying. I know many people consider that impossible, but still...
From what I see the Chrome's V8 engine does a number of optimizations when it sees JS code, probably compiles it (?) and then runs it.
So I'm wondering is it possible to use V8's C++ api to compile the JS code into machinecode/chromecode and then feed that directly into Chrome (I don't care about other browsers)?
Supposedly it will not only be faster, but also non-humanly readable, something like ASM.
Is this possible?
WebAssembly is doing this thing so I don't understand why we can't do it with JS code.
There's also EncloseJS and pkg that are doing a very similar thing.
V8 developer here. No, it is not possible to compile JavaScript ahead of time and send only the compiled code to the browser. V8 (and other virtual machines like it) contain compilers, but they cannot be used as standalone compilers to produce standalone binaries.
In theory, you could compile JavaScript to WebAssembly -- any two turing-complete programming languages can in theory be compiled to each other. As far as I know, no such compiler exists today though. One big reason for that is that performance of the end result would be horrible (see the discussion with Andreas Rossberg for details); so considering that browsers can execute JavaScript directly, people have little reason to develop such a thing. (It would also be a large and difficult task.)
As for your stated goal: your best shot at making JavaScript code unreadable is to minify it. In fact, that is effectively just as good as your idea to generate assembly, because disassemblers exist that turn assembly back into minified-like higher-level language code; they cannot reconstruct variable names or comments (because that information is lost during compilation), but they can reconstruct program logic.
What I ended up doing is moving some of the logic from JavaScript into C++ and compiling that into NodeJS native modules (that's possible for Electron apps).
It works pretty good, it's very fast, the source is... as protected as it can get, but you may need to worry about cross-platform issues, also compiling/linking can be a bit of a pain, but other than that it's great.
WebAssembly is not doing that. And no, it's not possible either. The web is supposed to be both browser- and hardware-independent.
Moreover, a language like JS would not be faster if compiled offline -- it only is anything close to fast because it is dynamically compiled and optimised, taking dynamic profile information into account.
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.
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 some html files that I need to do automated processing on, basically regex replaces, but also some more complex actions like copying select blocks of text from one file to another.
I want to create a series of scripts that will let me do this processing (it will need to be done more than once on different batches of files). It would be trivial to use Go for this (read the file into memory, regex, save to disk) but I am the only member of the project that's familiar with Go.
Javascript is a tad more ubiquitous, and I do have project members who are familiar with the language, so it's a better fit in that respect. If I'm not around later, someone else could edit the scripts.
Is there a simple way to write some JS scripts to do on-disk text processing? I'm looking for a cross-platform solution (OSX, Windows). Ideally, once the scripts are written, they can be executed by double-clicking an icon--there will be "not computer people" involved at some point.
Also, I'd like to be able to do some kind of alert/message box to inform the user of the success/failure of the script. (This may be a tall order, and is of secondary importance.)
What I've looked at:
Node.js was the first thing that popped into my head, because I know that it has file system access tools, and obviously regex capacity. But I've never used Node before, and based on the tutorials I've read, it seems like overkill for something this simple.
There's a whole slew of "javascript compiling" tools that you can find by googling around. Some are not cross-platform, some seem old or not actively maintained, etc. None of them caught my eye as easy to pick up and just write some JS scripts with.
Any thoughts?
Node.js is a simple solution and with it's framework you can create or later modify your script to your needs. This way you will not be locked down by someone else's code. And it is not that difficult to to use.
Here is a quick tutorial on accesing files using node.js
http://www.sitepoint.com/accessing-the-file-system-in-node-js/
And here is a quick tutorial on using a node module called Cheerio. It allow you to access html files using "jquery like syntax". You don't need to use regex.
http://maxogden.com/scraping-with-node.html
I worked on a project for a client once and it required parsing thru hundreds of html files to check and replace certain image files based on certain criterias. I wasn't familiar with node at the time so I read some tutorials and wrote the script in about an hour.
And as long as Nodejs' path is set, you can run it on the command line.
Some tips:
You need any kind of DOM HTML parser, not only JS nor specifically JS.
You can do that thing with Java with use of jTidy or jSoup libraries (I've used second one few times). It's pretty simple language to learn if you know JS and IDE like Netbeans helps a lot. So can be made quickly with that.
You can use PhantomJS to create some job files and create shell/batch code to run them on some files. You might need to write a generator for job files (like taking a list of files, creating job files for each and running them).
You can use Node.js which isn't much overkill, I'm sure any solution won't be trivial.
You can create an ETL for processing with for example Pentaho ETL (which has JS embedded as one of two scripting languages... but without DOM parser - for that one you would need to use a bit of Java there and some library in way similar to this article).
You can also do that with PHP with Simple HTML DOM Parser - so you can make a service online (or on local server) that takes those html files and throws out processed ones.
First I think you underestimate the complexity. The statement
"It would be trivial to use Go for this (read the file into memory,
regex, save to disk) but I am the only member of the project that's
familiar with Go."
is probably false. Parsing HTML with RegExp is just a bad idea. (Google it and you will see why)
Second, if you can trivially write the code using RegExps in Go, you can just as easily write the same thing in Javascript. They both support RegExp and file operations. If you are unsure about the Javascript/Node.js details, I suggest writing the trivial solution in Go and then translate the thing into Javascript with a colleague.
Since Javascript is a script language, writing command line utilities in Node.js is straight forward.
Some pointers to get you started
RegExp in Javascript
Building command line apps in Node.js
Something I've been learning (and teaching) in Software Engineering is that code duplication is the root of all evil. On the other hand, I find it quite hard to explain how this concept should be applied to the development of web apps.
Allow me to clarify... Input & data validation can be an important part of a web app. Sometimes this validation can be quite complex. For example, I worked on a puzzle editor and the validation consisted of checking whether an operation or a move was valid. Non-trivial rules then had to be checked.
Naturally, validation must be done server-side in order to ensure the consistency and quality of the stored data. However, it's a must to do validation client-side to ensure a smooth user experience.
In most instances, client-side and server-side code are written in different languages (i.e. javascript/Python), so validation code has to be written twice. However, in my only experience with GWT/Java (Java on both sides), I found that a large portion of the validation code could be reused. This seemed to make everything easier: maintenance, refactoring, debugging...
So my question to you is: how do you manage issues related to code duplication in projects where the client-side and server-side languages are different?
The way I usually handle this is to write the validation code on the server side and expose it via a web method (in .NET, similar functionality exists in most other languages) so that it can be called from javascript. As a result, you have a single method that can be called both synchronously and asynchronously from the client side and also called from the server side. This isn't applicable in every case but it's worked very well for me so far.
Typically, it's really hard to avoid duplicating the generated code, but a common approach is to use a code generator to build either the server or client side code so you only code one half of it. The most popular approach is writing the server-side common and then having the code generator build the JavaScript code for you. For instance, the language we use at my company is Coldfusion and Form-o-matic solves that problem for us. People have also approach the problem from the opposite direction by writing JavaScript which can be executed server side. I'd look for a framework that will do this for you.
A possible solution is that you abstract the actual validation in a validation description file (in XML or any other means) using a DSL. This way you only need to implement the validation engine in both client and server language and base the validations on the same description file.