Is there a way to expire unobfuscated javascript? - javascript

Currently, our developers unobfuscate the javascript code so they can better QA our code in staging before we release to production.
However, sometimes, they forget to obfuscate the code before releasing to production.
I was wondering if there is a way to expire unobfuscated javascript so that, even if the QA developers forget to obfuscate the js it will auto obfuscate the js after a certain time frame (say 12 hours)?

No, what you are asking for does not make sense.
The problem is with your process: why is the obfuscation happening before your QA developers get the product? Why is it not between them and the final customer release (even if it is necessary)?
Try redesigning the path the code takes between your core developers and the customers' hands instead of looking for a technical solution for a business problem.

Javascript does not obfuscate itself so this question doesn't make a whole lot of sense.
Obfuscation is done by a separate tool in the build/release process. What you need is to improve/automate part of the release process to remove the chances of human error in that process. This can either be done with a more rigorous manual process or with more automatation.
In general, the QA team should be testing the EXACT same code that gets deployed on the final site so if that's obfuscated, that's what QA should test. So, first of all, I'd review what QA is doing and why. They should be testing the obfuscated code.
If QA needs to review the unobfuscated code for any reasons (I can't think of any likely reasons myself), then they should make their own copy of the code on their own systems that is unobfuscated and should not be putting the unobfuscated code anywhere in the release process.
Lastly, it sounds like you would benefit from building an automated release process that does the obfuscation and deploys to both the QA test environment and the same process deploys to your production servers. That guarantees that obfuscation is in place and that QA is testing the exact same bits that would go to production when it's released.

Your process is wrong. If the devs need unobfuscated javascript for debugging, make it such that the server itself has a debug flag to return unobfuscated code. Default to obfuscated code. Require both be present. Work the obfuscation into a release script in the release process.
You don't want QA testing something other than the build you're deploying, so obfuscating after the fact is unideal (imagine you hit a bug in the obfuscator... as likely as it seems, would you rather catch it in QA, or not until it hits prod?
By defaulting to obfuscated code, but allowing plain code via say session state or cookie, you get both correctly tested releases, and easily debuggable ones.

Related

How to prevent access to my website via JavaScript

I was wondering if it would be possible to create a JavaScript function to check a condition, and if that is True then I deny access to the code? Right now I am checking the user agent, and if it doesn't meet given criteria then I delete the HTML tag. However, if they go to the network tab then they can still see the GET requests and responses for my code.
This is a website running on localhost because it's an Electron app by the way.
I thought maybe I could issue a 403 error but I'm not sure if that's possible via JS.
Thanks
In an Electron app, your code is still JavaScript source code. You can obfuscate it and/or put it in a ASAR archive to make it harder to read and fine, but the code is still there and accessible to anyone who wants to go to the effort. (For instance, if you use VS Code, you can see the source in resources/app/out directory and its subdirectories.)
You can make it even harder to find and understand the source if you're willing to put in more work. V8, the JavaScript engine Node.js uses, has a feature called startup snapshots: You run V8 and have it load your script (your obfuscated code), take a heap snapshot (after GC), and write it to a file. Then you specify the heap snapshot when loading V8, and it just hauls in the snapshot instead of reading and parsing code. The Atom team have done this on top of Electron. In their case the motivation was startup performance, not hiding the source code, but it has the effect of making your code even harder to find.
Note I said harder, not impossible. At the end of the day, if you want the code to execute on the end-user's computer, that code is going to be accessible to the end user. This is true even of compiled applications, although of course in that case a lot of organizational information that helps a human understand the code is lost in compilation, which happens less with obfuscated code. (But a good obfuscator makes code extremely opaque to human beings.)

Do comments in NodeJs affect performance?

I am in the process of having to refactor an entire NodeJs project which is quite large. One of the biggest problems I'm facing is that my predecessor included literally no documentation.
I'm used to clientside js, where comments can be stripped via uglify (or similar) before deploying to a production environment.
Is there something similar for node, or how do people handle this? Is the performance impact of comments negligible?
Comments do not affect code performance in a significant way. Neither in the in client nor in the server.
What happens in the client is that if you're including JavaScript with comments those lines are still being downloaded by the browser, without no extra benefit for the user.
In client side code, comments add to the file size that needs to be sent to the browser, so that is why tools at used to remove comments. On the other hand, the comments in server side code doesn't make much difference.
Comments do not affect performance in a significant matter. How I understand it, the javascript program is being loaded into the memory. In this process the comments are being ignored and are not loaded into the memory. Meaning that only during the loading of your application you could experience extremely minor increase of loading time while having a lot of comments. But this is negligible.
Using uglify would not be necessary since users cannot read your NodeJS code. And it would make the newly refactored code less readable for you (which would be counterproductive).
Like Alberto and Konst are pointing out is that uglify can be used to reduce file size for downloading by the client.
Note: I do not know if i am exactly correct, please do correct me if i am wrong.

MVC Project often recompiles after JS changes, don't know why, results in problems

I have a medium-sized ASP.NET MVC project with a lot of Javascript (Single-Page-App). Very often (dozens of times a day), when I edit the Javascript files and refresh it, I see in VS' output that it goes through the whole Application_Start process (as in (re-)starting the app).
This results in unwanted delays during development and after 2-4 such restarts, I get an InvalidOperationException "Not running in a hosted service or the Development Fabric.". Since I do run it in the emulator, it seems to be that after a few app-restarts, it loses its connection to the emulator. Apart from that, I even got (although very rare) OutOfMemoryExceptions, which I can't find out where they are coming from, because nothing in the web app should allocate much memory and my workstation does have quite a lot (32 GiB).
It can't be related to an idle timeout for the IIS (Express) worker process, since the JS changes often only took seconds. I tried to reproduce it by adding spaces to the JS file and saving it, repeating that a few times and then trying to refresh. Weirdly, I was unable to reproduce it this way.
I am out of ideas, help would really be appreciated :)
[Edit]
Not an answer yet, but a possibility. It seems like Web Essentials is compiling my LESS files each time I save them (even after I specifically deactivated that because ASP.NET Bundling and Minification already handles that), which result in quite a few additional writes because I have the habit of saving VERY often. Already contacted the developer, maybe it's a bug.
This is actually due to IIS behaviour. IIS recycles any app if there is any change in the files in its file structure.
I had a similar experience and detailed my understanding here: http://www.geekays.net/post/2008/10/14/ASPNET-webdomain-recycle-on-subfolder-changes.aspx

Is that possible to develop a ACM ONLINE JUDGE system using NODE.JS(or PYTHON)?

I'm a newer and if the question is so easy I apologize for that.
Assume I want to dev a classical online judge system, obviously the core part is
get users' code to a file
compile it on server
run it on server (with some sandbox things to prevent damage)
the program exit itself, then check the answer.
or get the signal of program collapsing.
I wonder if it's possible to do all the things using Node.js, how to do the sandbox things. Is there any example for compile-sandbox-run-abort-check thing?
additional:
is it more convenient to dev a such system using PYTHON?
thanks in advance.
Most of these steps are standard --- create a file, run a system call to compile something, muck around with I/O --- I think any language should be able to do them, except the very crucial step of "run in a sandbox." I am aware of several solutions for sandboxing:
use OS commands to restrict or remove abilities (chroot, setrlimit, file system permissions in linux)
remove all dangerous functionality from the language being graded
interrupt system events
run the sandbox inside a virtual machine.
This list is probably not exhaustive. The system I am involved with, http://cscircles.cemc.uwaterloo.ca uses option #1. Again, most of the work is done in system calls so I can't imagine that one language is so much better than the other? We use php for the big-level stuff and C to do the sandboxing. Does that help answer your question?
To accomplish the sandbox, it would be fairly easy to do this by simply running your code inside of a closure that reassigns all of the worrisome calls to NaN
for instance, if the code executes inside a closure where eval=NaN

Is using an obfuscator enough to secure my JavaScript code?

I'm working on building a development tool that is written in JavaScript.
This will not be an open source project and will be sold (hopefully) as a commercial product.
I'm looking for the best way to protect my investment. Is using an obfuscator (code mangler) enough to reasonably secure the code?
Are there other alternatives that I am not aware of?
(I'm not sure if obfuscator is the right word, it's one of the apps that takes your code and makes it very unreadable.)
I'm going to tell you a secret. Once you understand it, you'll feel a lot better about the fact that Javascript obfuscation is only really useful for saving bandwidth when sending scripts over the wire.
Your source-code is not worth stealing.
I know this comes as a shock to the ego, but I can say this confidently without ever having seen a line of code you've written because outside the very few realms of development where serious magic happens, it's true of all source-code.
Say, tomorrow, someone dumped a pile of DVDs on your doorstep containing the source code for Windows Vista. What would you be able to do with it? Sure, you could compile it and give away copies, but that's just one step more effort than copying the retail version. You could painstakingly find and remove the license-checking code, but that's something some bright kid has already done to the binaries. Replace the logo and graphics, pretend you wrote it yourself and market it as "Vicrosoft Mista"? You'll get caught.
You could spend an enormous amount of time reading the code, trying to understand it and truly "stealing the intellectual property" that Microsoft invested in developing the product. But you'd be disappointed. You'd find the code was a long series of mundane decisions, made one after the other. Some would be smarter than you could think of. Some would leave you shaking your head wondering what kind of monkeys they're hiring over there. Most would just make you shrug and say "yeah, that's how you do that."
In the process you'll learn a lot about writing operating systems, but that's not going to hurt Microsoft.
Replace "Vista" with "Leopard" and the above paragraphs don't change one bit. It's not Microsoft, it's software. Half the people on this site could probably develop a Stack Overflow clone, with or without looking at the source of this site. They just haven't. The source-code of Firefox and WebKit are out there for anyone to read. Now go write your own browser from scratch. See you in a few years.
Software development is an investment of time. It's utter hubris to imagine that what you're doing is so special that nobody could clone it without looking at your source, or even that it would make their job that much easier without an actionable (and easily detectable) amount of cut and paste.
I deeply disagree with most answers above.
It's true that every software can be stolen despite of obfuscation but, at least, it makes harder to extract and reuse individual parts of the software and that is the point.
Maybe it's cheaper and less risky to use an obfuscation than leaving the code open and fighting at court after somebody stole the best parts of our software and made dangerous concurrency.
Unobfuscated code whispers:
Come on, analyze me, reuse me. Maybe you could make a better software using me.
Obfuscated code says:
Go away dude. It's cheaper to use your own ideas than trying to crack me.
You are going to be fighting a losing battle if you try to obfuscate your code in the hopes of someone not stealing it. You may stop the casual browser from getting at it, but someone dedicated would almost certainly be able to overcome any measure you use.
In the past I have seen people do several things:
Paste a lot of whitespace at the top of the page with a message telling people that the code is unavailable, when in actuality you just need to scroll down a few pages to get at it.
Running it through an encoder of some kind, this is so so useful as it can just be run through the decoder.
Another method is to reduce variable names to one character and remove whitespace (this is also an efficiency thing).
There are many other methods.
In the end, your efforts are only likely to stop the casual browser from seeing your stuff. If someone dedicated comes along then there is not much you will be able to do. You will have to live with this.
My advice would be to make a really awesome product that attracts the most people and beat off any competition by having the best product/service/community and not the most obfuscated code.
You're always faced with the fact that any user that comes to your webpage will download some working version of your Javascript source. They will have the source code. Obfuscating it may make it very difficult to be reused by someone with the intent to steal your hard work. However, in many cases someone can even reuse the obfuscated source! Or in the worst case they can unravel it by hand and eventually comprehend it.
An example of a situation like yours might be Google Maps. The Javascript source is clearly obfuscated. However, for really private/sensitive logic they push the data to the server and have the server process that information using XMLHttpRequests (AJAX). With this design you have the important parts on the server side, much more tightly controlled.
That's probably about the best you can do. Just be aware that anybody with enough dedication, can probably de-obfuscate your program. Just make sure you're comfortable with that before embarking on your project. I think the biggest problem with this would be to control who's using it on their site. If somebody goes to a site with your code on it, and likes what it does, it doesn't matter that they don't understand what the code does, or can't read it, when they can just copy the code, and use it on their own site.
A obfuscator won't help you at all if someone wants to figure out the code. The code still exists on the client machine and they can grab a copy of it and study it at their leisure.
There is simply no way to hide code written in Javascript since the source code has to be handed to the browser for execution.
If you want to hide your code, you have the following options:
1) Use an environment where compiled code (not source) is downloaded to the client, e.g. Flash or Silverlight. I'm not even sure that's foolproof, but it's certainly much better than Javascript.
2) Have a back end on the server side that does the work and a thin client that just makes requests to the server.
I'd say yes, it's enough if you also make sure than you compress the code as well using a tool like Dean Edward's Packer or similar. If you think about what is possible with tools like .NET Reflector in terms of reverse engineering compiled code / IL in .NET, you realize that there's nothing you can do to completely protect your investment.
On the other hand, remember that folks who release their source code also seem to make do quite nicely anyway - it's their experience that people want more than their intellectual property.
code obfuscator is enough for something that needs minimal protection, but I think it will definitely not enough to really protect you. if you are patient you can realy de-mangle the whole thing.. and i'm sure there are programs to do it for you.
That being said, you can't stop anyone from pirating your stuff because they'll eventually will break any kind of protection you create anyway. and it is espcially easy in scripted language where the code is not compiled.
If you are using some other language, maybe java or .NET, You can try doing things like "calling home" to verify that a license number matches a given url. Which works if you your app is some sort of online app that is going to be connected online all the time. But having access to the source, people can easily bypass that part.
In short, javascript is a poor choice for what you are doing.
A step up from what you are doing is maybe using a webservice backend to get your data. Let the webservice handle the authentication/verification process. Requires a bit of work to make sure it is bulletproof, but it might work
If this is for a website, which by its very nature puts viewing of its code one menu click away, is there really any reason to hide anything? If someone wants to steal your code they will most likely go through the effort of making even the most mangled code human readable. Look at commercial websites, they don't obfuscate their code, and no one goes out and steals code from the google apps. If you are really worried about code theft, I would argue for writing it in some other compiled language. (which does of course destroy the whole webapp thing...) Even then, you aren't totally safe, there are many de-compilers out there.
So really, there is no way to do what you want in the face of anyone with sufficient motivation.

Categories