This question is mainly for security purposes. I need to know if it is possible to view by any means (plugins, programmatically or whatever) a list of all variables and their values in a gwt application compiled to javascript.
Let's say I have a variable x created by gwt in its normal deployment mode.... let's just ignore how did the value get there... Can the user somehow get to know that there is a var called x and its value...
Please note that I am not looking for software engineering best practices, the question is over simplified so that we get to the point. I know that I should not have anything sensitive on the client on the first place... but please let's just skip that since the case is a much bigger story...
Thanks a lot..
Short awnser... yes..
GWT compiles to javascript and obfuscates everything, that said, all information is available from the compiled source if one knows what to look for. If someone succeeds in injecting a simple script tag into your application, they can simple retreive all scripts through XMLHttpRequest and parse them as text. No matter how obfuscated, it's theoretically possible to get what you want from any javascript source. If you can see it in the raw script file, it's attainable, doesn't really matter if it's locked away in anonymous closures or whatnot, any JS security mechanism can be circumvented.
Main condition is to get control of the page (script injection).
To quote yourself: " I know that I should not have anything sensitive on the client on the first place..."
If it's worth hacking, people will try it.
GWT code is compiled to javascript. So ultimately user can use javascript introspection to discover all objects and their properties.
Short answer - No, not unless you know what you are looking for.
GWT compiler does something called as cross-compiling, it transforms java code into java script/ECMA script. The mapping between a variable in java to that in generated script is not straight forward. The language semantics are not the same; the compiler tries to optimize and generates obfuscated JS (to reduce the size). You can tweak this to certain extent by passing arguments at compile time (by setting PRETTY). This still does not guarantee a one on one mapping.
On different quote, even decompiled java code does not look like the original source. ( thats' the complexity of the problem)
I have written some javascript which reads data in a textarea (inside a browser)
and outputs the result in a string (as innerHTML) in a div.
It's brilliant and it does its job.
I would like to port it out of the browser.
I would like to reuse the same javascript (which effectively is just a function that given a string returns another string) out of the browser.
Ideally I would like to run it a commandline tool and say read file c:\input.txt and writes the response on c:\output.txt
Can somebody suggest how best I can achieve this ?
I looked around and came across to commonjs.org (which is very interesting) and node.js
(which is interesting too) as well as other obscure projects.
Yet, I still don't know how to do this. If somebody has done something similar I would like to hear.
Many Thanks,
p.s.
I tagged this question 'server-side javascript' mainly to say that it's not a browser question.
Rhino from Mozilla is javascript interpreter written in java which might do what you need.
If your're on a windows system, you could the native c-/wscript interpreter using the FileSystemObject to read and write files. Otherwise jsdb may be an option, where you can use the Stream-object.
http://RingoJs.org
It's a thin wrapper on top of Rhino. Makes dealing with files, modules, etc a lot easier, see for example: http://ringojs.org/api/master/fs/
Is there some way to make Firebug not work at all on a website?
If the performance of your website suffers when Firebug is enabled, you may want to display a warning, asking users to switch it off. You can easily detect if Firebug is enabled through JavaScript.
WARNING: EXTREME EVIL. NEVER EVER USE THIS CODE. Also, it won't deter someone who is resourceful.
setTimeout(checkForFirebug, 100);
function checkForFirebug()
{
if (window.console && window.console.firebug) {
while(true); //Firebug is enabled
}
setTimeout(checkForFirebug, 100);
}
EDIT: I figured I would provide an answer to the real question behind the question. The fact is, Javascript is an interpreted language and that interpreter is in the browser. This makes it literally impossible to provide Javascript that is both secure and runnable. The same goes for HTML and CSS. The best you can do is minify the Javascript to make it a little less easy to reuse. If the company in question really wants "secure" Javascript, you just have to tell them it's not truly possible.
Ummm....
What does using Firefox (with or without Firebug) have to do with this?
I use IE and I can just as easily view your JavaScript. Likewise with Google Chrome. Hell, I can download your JavaScript when viewing your webpage on my Palm Treo.
Anything which can be accessed directly from a browser can be downloaded and analyzed at leisure. As others have said (better than I), JavaScript which runs on your website should be considered to be "open source". Find another way to do it (i.e. processing on your server) or accept that someone will hack in and look at it.
Mind you, are your routines so obviously good (in terms of what they do to your webpages) that a user will go to your website and immediately say "Hey, this is cool, I wonder how they do it?" If not, don't worry about it - most people won't be interested enough to try to look at your JavaScript.
You could try minifying your JavaScript, but that's not 100% going to stop someone who's determined. You could try encrypting it, but I've never tried. Or put a copyright notice in your JavaScript files, so at least someone else won't be able to subsequently pass off your work as yours without getting into legal trouble.
No. Nobody wants your javascript routines anyway. :-)
And if you're worried about unsecure code, you should rewrite your site to be secure instead of trying to hide its problems.
If you want to hide your HTML/CSS/JavaScript from visitors, that is not possible. Even if one cannot use Firebug, one can simply view the HTML source code. Any external JavaScripts and stylesheets can be downloaded as the plain text files they are. Because HTML, CSS, and JavaScript are client-side technologies, that are downloaded as plain text and interpreted by the web browser, it is theoretically impossible to hide your code. The best thing you can do to make the code harder to understand, is to obfuscate it. See Wikipedia.
You could click on the Off button to disable it.
Or are you trying to prevent your users from running it? If so, good luck...
"My javascript routines" belong to the company I work for and my company wants the stuff we develop secured.
You do not secure stuff by lightly patting "hackers" on the fingers when they use one specific debugging tool. Try to prevent them from using the ultimate hacker tool: "View Source".
If it's out there it's out there. "Secure" means something different in this context. It means securing whatever important data you have by employing techniques that are impenetrable* even with full knowledge of the source code. The source code itself is not securable, and neither does it need to be.
*) "impenetrable" = difficult enough to subvert in a reasonable amount of time, nothing is 100% :)
You could develop your site in Flash, Silverlight, or Java. Firebug will then be limited to displaying your base HTML.
I'm assuming you're worried about reverse engineering with FireBug.
Anything you send to the client, all your javascript, is open to whoever you send it to. Don't have anything there that you don't want people to see. There is no way to prevent someone else's browser from using Firebug, or a lot of other tools, to analyze your code. You could try to make your html, css, and javascript really bad, and that might slow them down! There are obfuscation programs to make it difficult to read. If you want to hide functionality, you'll need to have it happen on the server.
No, of course not. If Firebug is revealing something that you must prevent your users from seeing, then you are approaching this problem completely wrong. I am not trying to be rude or degrading, but attempting to block one particular program in an effort to fix a bug in your web application is about as logical as a bucket of steam. Firebug does nothing magical; I can do anything it does by writing some code. Having said that, there must be an underlying issue that you should be more concerned about.
Just to provide a little trick that i use helps lower people seeing your code,
One of the tricks i do that does not prevent the JavaScript from being found by the experianced developer or hacker, but deters the few people playing with Firebug / inspector,
use jQuery or another lib with a grate selector
the second port of call is all you files put them into a loader file E.G
Loader.js
(function($){
function loader(type, addr){
var head = $("head")[0];
switch(type){
case "script":{
var element = $(document.createElement("script"));
element.attr("type", "text/javascript");
element.attr("src", addr);
element.attr("loaded", "loader")
$(head).append(element);
}
case "style":{
var element = $(document.createElement("link"));
element.attr("rel", "stylesheet");
element.attr("type", "text/css");
element.attr("loaded", "loader");
element.attr("href", addr);
$(head).append(element);
}
}
}
loader("css", "path/to/your.css");
loader("script", "path/to/script.js");
loader("script", "unloader.js")
})(jQuery);
So to start with were using a closure this prevent anyone from using the console input of the inspector to see the code that has been run.
so once this file has been passed it will load your CSS and JS but you can still see there loaded in the head element of your inspector, thanks to browsers and the they way they work you can remove and not unload them this means the code will not be removed from execution but will prevent them being shown in the inspector this is what goes in the unloader.
unloader.js
(function($){
$("head *[loaded=loader]").remove();
})(jQuery);
The above will remove the the files loaded though the loader.
The only thing you need to remember is to add loaded="loader" to your scrip that that includes the loader, now this does not make it impossible for some one to see your files but stops the inspector from showing them in the HTML,
the ways around this can be to "View Source" code see the loader file and read that so make sure you minimize the code i use Google Closure Compiler (http://closure-compiler.appspot.com/home)
even this does not stop them it just make it more difficult. one of the steps i have tested but dont use is on the loader and files your loading use a .HTAccess rule to check that they have a reffer link form your site this will prevent them browsing directly to your js/css code files
another tip don't store them in normal places and don't use common names E.G scripts in /scripts/ CSS in /style/ or style.css
Here is an example of the loader Closure Compiled then Obfuscated
Loader.js
var _0xc596=["\x68\x65\x61\x64","\x73\x63\x72\x69\x70\x74","\x63\x72\x65\x61\x74\x65\x45\x6C\x65\x6D\x65\x6E\x74","\x74\x79\x70\x65","\x74\x65\x78\x74\x2F\x6A\x61\x76\x61\x73\x63\x72\x69\x70\x74","\x61\x74\x74\x72","\x73\x72\x63","\x6C\x6F\x61\x64\x65\x64","\x6C\x6F\x61\x64\x65\x72","\x61\x70\x70\x65\x6E\x64","\x6C\x69\x6E\x6B","\x72\x65\x6C","\x73\x74\x79\x6C\x65\x73\x68\x65\x65\x74","\x74\x65\x78\x74\x2F\x63\x73\x73","\x68\x72\x65\x66","\x73\x74\x79\x6C\x65","\x63\x73\x73","\x70\x61\x74\x68\x2F\x74\x6F\x2F\x79\x6F\x75\x72\x2E\x63\x73\x73","\x70\x61\x74\x68\x2F\x74\x6F\x2F\x73\x63\x72\x69\x70\x74\x2E\x6A\x73","\x75\x6E\x6C\x6F\x61\x64\x65\x72\x2E\x6A\x73"];(function (_0x76e5x1){function _0x76e5x2(_0x76e5x2,_0x76e5x3){var _0x76e5x4=_0x76e5x1(_0xc596[0])[0];switch(_0x76e5x2){case _0xc596[1]:var _0x76e5x5=_0x76e5x1(document[_0xc596[2]](_0xc596[1]));_0x76e5x5[_0xc596[5]](_0xc596[3],_0xc596[4]);_0x76e5x5[_0xc596[5]](_0xc596[6],_0x76e5x3);_0x76e5x5[_0xc596[5]](_0xc596[7],_0xc596[8]);_0x76e5x1(_0x76e5x4)[_0xc596[9]](_0x76e5x5);;case _0xc596[15]:_0x76e5x5=_0x76e5x1(document[_0xc596[2]](_0xc596[10]));_0x76e5x5[_0xc596[5]](_0xc596[11],_0xc596[12]);_0x76e5x5[_0xc596[5]](_0xc596[3],_0xc596[13]);_0x76e5x5[_0xc596[5]](_0xc596[7],_0xc596[8]);_0x76e5x5[_0xc596[5]](_0xc596[14],_0x76e5x3);_0x76e5x1(_0x76e5x4)[_0xc596[9]](_0x76e5x5);;} ;} ;_0x76e5x2(_0xc596[16],_0xc596[17]);_0x76e5x2(_0xc596[1],_0xc596[18]);_0x76e5x2(_0xc596[1],_0xc596[19]);} )(jQuery);
unloader.js
var _0xc2fb=["\x72\x65\x6D\x6F\x76\x65","\x68\x65\x61\x64\x20\x2A\x5B\x6C\x6F\x61\x64\x65\x64\x3D\x6C\x6F\x61\x64\x65\x72\x5D"];(function (_0x3db3x1){_0x3db3x1(_0xc2fb[1])[_0xc2fb[0]]();} )(jQuery);
to reproduce of to: http://closure-compiler.appspot.com/home put your code in under the // ADD YOUR CODE HERE
Then the result that is given back use: http://www.javascriptobfuscator.com/Default.aspx to make it even more unreadable.
Hope this helps any one else looking to make the JS as Secure as possible
But please remember as every one else has said this will not stop the pro hackers just make it very difficult to read and understand
No...............
Ultimately, no, as the browser (in this case firefox) on their machine can choose to run whatever javascript (such as firebug) it wants to. You cannot prevent users from running it along with your website.
if you want to protect your code, you could try encrypting your javascript source code
google encrypt javascript source
My reputation is too low to comment, but I just wanted to point out something that I noticed after learning about window.history.pushState(); it seems that you can change what is currently in the address bar, and once you do that, "view page source" doesn't work. So if there was a way to block developer tools from working, I wouldn't know how to view the source code.
EDIT: After using window.history.pushState(), when I view developer tools, it tells me to reload the page to view what is in a javascript file (but then again it does show the address to the JS file so that doesn't help much)
I would like to check a large number of HTML files with inline JavaScript for JavaScript errors. What I'm envisioning doing is this: Script a browser to load a given page, wait a few seconds, and finally check the browser logs. I'm unsure though both on how to script a browser to load a given page and on how to access the JavaScript error log. I think the type of errors I'm worried about should show up in any modern browser so I would just go with whatever makes it most convenient. I'd be working either under Mac OS X or Linux.
Anybody already tackle a similar problem? I've thought a bit about hacking something together based on a unit testing framework -- generate a trivial (assertTrue(true)) test for each page and rely on the errors making it fail -- but I'm hoping for something more elegant. Thank you.
There are several routes you could take, though I'm not convinced that automation is really necessary in this case.
If your Javascript wasn't inline, you could try something adventurous like Rhino with DOM support, and completely eschew the browser. I would heartily recommend separating your JS and your markup anyway.
If you're dead-set on creating an automated solution for this, I would perhaps take a look at the Selenium plugin/testing framework for Firefox. It enables automated UI testing, and if you're thorough enough with it you should be able to uncover any error cases you would have run into in using the site. It should also be able to report JS errors to you. If not, using it in conjunction with a service like ExceptionHub or Hoptoad will get you what you need.
You shouldn't have to resort to trying to unit-test JS in the DOM. That's a recipe for complication.
I wanted to hide some business logic and make the variables inaccessible. Maybe I am missing something but if somebody can read the javascript they can also add their own and read my variables. Is there a way to hide this stuff?
Any code which executes on a client machine is available to the client. Some forms of code are harder to access, but if someone really wants to know what's going on, there's no way you have to stop them.
If you don't want someone to find out what code is being run, do it on a server. Period.
That's one of the downsides of using a scripting language - if you don't distribute the source, nobody can run your scripts!
You can run your JS through an obfuscator first, but if anyone really wants to figure out exactly what your code is doing, it won't be that much work to reverse-engineer, especially since the effects of the code are directly observable in the first place.
Javascript cannot be compiled, that is, it is still Javascript.
But, there's this: http://dean.edwards.name/packer/
Generally, this is used to reduce the code footprint of the Javascript, if say your script is being downloaded thousands of times per minute. There are other methods to accomplish this, but as for hiding the code this sort of works.
Granted, the code can be unpacked. This will keep out a novice but anyone who is determined to read your source code will find a way.
It is even this way with compiled languages, even when they have been obfuscated. It's impossible to hide your code 100% of the time -- if it executes on your machine, it can be read by a determined hacker.
You could encrypt it so no one can read it.
For example
http://daven.se/usefulstuff/javascript-obfuscator.html
You must always validate the data you send back. I've had a rather entertaining time playing pranks on a forum I'm a mod of by manipulating the pages with the Web Developer Toolbar. Whether or not you obfuscate it, always assume that data coming to the server has been intentionally manipulated. Only after you prove it hasn't (or verify the user has permission to act) do you handle the request.