0

I am exporting a js module via module.exports. The caller function requires this module and calls the exported functions.

Code looks something likes this:

file1.js

module.exports = {
 Info: showInfo
}

function showInfo(param1, callback) {
 callback(null, getInfo(param1))
}
let secretCode = 'xyz';

function getInfo(p1) {
 return EncodeInfo(param1, secretCode);
}

function EncodeInfo(p2, p3) {
 //some code
}

file2.js

var f1 = require('./file1');

f1.Info("some value");

Now the thing is that file2.js is provided by the customer at runtime and code gets deployed to the server. Server entry point functions call an entry function in file2.js. file2.js just has access to core node libraries, a logging functionality and request module.

I need to hide whats written inside file1.js. Customer can do something like this to see the code

console.log(f1.Info.toString());
//this will print following
/*
function showInfo(param1, callback){
    callback(null, getInfo(param1)) 
}
*/

This is ok, as getInfo() code is hidden. Also, other private functions and variables are hidden. Also to mention that customer cannot install any other node modules and only provides file2.js

Please note that I cannot control what he is writing in file2.js, neither I can scan before merging the file2.js with rest of the code.

Question 1: The question is simply that is my assumption correct? Or is there any way where he can see the rest of the code implementation or any other details of imported(require) modules? Maybe through prototype?

Question 2: Is there any way he can see the details of servers entry point function implementation. The customer does have access to process and hence process.env, but that is ok. I am more bothered about other file's code.

Dipak
  • 2,248
  • 4
  • 22
  • 55
Mangesh V. Devikar
  • 90
  • 5
  • 1
    Why are you trying to hide the code like that? If they can run the code, they can read the source directly. - What I'm trying to say is what is stopping them from directly opening `file1.js` as they have to be able to read it in order to use it. – scagood Feb 16 '18 at 15:07
  • The best I can think of for preventing the reading of the implementation would be either mangleing and uglifying (https://github.com/mishoo/UglifyJS2) the script, or possibly an obfuscator (https://javascriptobfuscator.com/Javascript-Obfuscator.aspx) (Not that you cant just do exactly the same thing) – scagood Feb 16 '18 at 15:14
  • @scagood To add more details, customer is writing the code in a online editor. This we publish to aws lambda that executes for the customer, wrapped inside our own implementation.Hence they have access to environment but not the rest of the code files directly. Also they cant install any additional modules – Mangesh V. Devikar Feb 16 '18 at 15:20

1 Answers1

0

Yes, it's correct that file2 cannot access the secretVariable of file1, it's hidden well enough through closure.

file2 is provided by the customer at runtime and code gets deployed to the server

Then you have lost. Do not just run untrusted code on your server! It would be trivial for the code to use var f1 = fs.readFileSync('./file1'); instead of require('./file1'), exposing your code and its "secret" variables. There's probably a myriad of other ways.

If you want to run untrusted code, you need to use a proper sandboxing solution.

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • yes you are right. In my case as the lambda function is dedicated for that particular customer, its ok if he done something malicious as its not impacting anyone else. Sandboxing is hence not required. I was asking this question basically to see if i can extend the capability further by calling other external lambda functions to which some parameters will be passed by customer implementation of which will be wrapped under hidden code. But after ur comment i tested fs.readFileSync('./file1') and as u said, its displaying the code. – Mangesh V. Devikar Feb 16 '18 at 16:31