After some security concerns about user plugins running spyware, I'm looking for a way to disable all JavaScript before and after my site's JS. Ideas?
Is there a way to unset all native JavaScript, or block plugins from modifying a site's code with JavaScript? This is a huge security threat and I'm hoping it's easily remedied.
EDIT: I'm referring to browser add-ons. Basically, any JavaScript code that I didn't write myself and put on my site.
Is there a way to unset all native JavaScript, or block plugins from modifying a site's code with JavaScript?
No.
This is a huge security threat and I'm hoping it's easily remedied.
It is, yes: get your users to stop installing spyware.
Look, even if the spyware isn’t able to use an add-on to modify your site, there are any number of other possibilities for mucking about at a level above the browser. You can’t fix a fundamentally unsafe computer from the web side.
The solution that I found that was effective against the spyware in question was putting some garbage JavaScript below the JavaScript on my site. Here's an example:
(function() {
....
});
thisIsGibberish
This sort of solution can be countered easily with placing a semi-colon in front of any code, but this was the kind of thinking I was trying to inspire.
Related
Is there any way to hide the CSS and JavaScript file from the client-side user and still embed it in the webpage shown to the user?
No. CSS and Javascript must be parsable and readable by the browser, therefore a human can get access to the same data.
It is possible to obscure/compress/minify the javascript, but all that generally does is remove whitespace and rename/shorten variable names. The script is still functional and anyone interesting in how it really works can still figure it out (perhaps by using some tools to reformat it) with a little more time.
The typical reasons for minification is to reduce the download size of your scripts (speeding up site performance), but it also has the side effect of making the code harder to read by a human. One should not count on minification providing any real protection as the code can be reformatted and still understood by anyone determined to do so.
If you need to keep something private, keep the logic on the server and don't put it in the client. Clients can access server-based functionality via ajax if need be.
I've never heard of anyone thinking there was a business reason to protect CSS. It's layout/presentation formatting.
You can always minify the JavaScript file to make it harder for someone to reads it or to modify it.
For example : http://www.minifyjavascript.com/
You can also do the same thing with CSS.
http://developer.yahoo.com/yui/compressor/
(it can do both JavaScript and CSS)
There are other sites that offers a way to minify the files, but there is no way to hide it completely from the client-side.
Minification and base64 encoding. Here's SO questions about base64 encoding. Be mindful that all you're doing is making the process of looking at your code miserable and no more.
Online encoder/decoder.
Is there any way to hide the CSS and JavaScript file from the client-side user and still embed it in the webpage shown to the user?
No. CSS and Javascript must be parsable and readable by the browser, therefore a human can get access to the same data.
It is possible to obscure/compress/minify the javascript, but all that generally does is remove whitespace and rename/shorten variable names. The script is still functional and anyone interesting in how it really works can still figure it out (perhaps by using some tools to reformat it) with a little more time.
The typical reasons for minification is to reduce the download size of your scripts (speeding up site performance), but it also has the side effect of making the code harder to read by a human. One should not count on minification providing any real protection as the code can be reformatted and still understood by anyone determined to do so.
If you need to keep something private, keep the logic on the server and don't put it in the client. Clients can access server-based functionality via ajax if need be.
I've never heard of anyone thinking there was a business reason to protect CSS. It's layout/presentation formatting.
You can always minify the JavaScript file to make it harder for someone to reads it or to modify it.
For example : http://www.minifyjavascript.com/
You can also do the same thing with CSS.
http://developer.yahoo.com/yui/compressor/
(it can do both JavaScript and CSS)
There are other sites that offers a way to minify the files, but there is no way to hide it completely from the client-side.
Minification and base64 encoding. Here's SO questions about base64 encoding. Be mindful that all you're doing is making the process of looking at your code miserable and no more.
Online encoder/decoder.
I want to allow user contributed Javascript in areas of my website.
Is this completely insane?
Are there any Javascript sanitizer scripts or good regex patterns out there to scan for alerts, iframes, remote script includes and other malicious Javascript?
Should this process be manually authorized (by a human checking the Javascript)?
Would it be more sensible to allow users to only use a framework (like jQuery) rather than giving them access to actual Javascript? This way it might be easier to monitor.
Thanks
I think the correct answer is 1.
As soon as you allow Javascript, you open yourself and your users to all kinds of issues. There is no perfect way to clean Javascript, and people like the Troll Army will take it as their personal mission to mess you up.
1. Is this completely insane?
Don't think so, but near. Let's see.
2. Are there any Javascript sanitizer scripts or good regex patterns out there to scan for alerts, iframes, remote script includes and other malicious Javascript?
Yeah, at least there are Google Caja and ADSafe to sanitize the code, allowing it to be sandboxed. I don't know up to what degree of trustworthiest they provide, though.
3. Should this process be manually authorized (by a human checking the Javascript)?
It may be possible that sandbox fails, so it would be a sensible solution, depending on the risk and the trade-off of being attacked by malicious (or faulty) code.
4. Would it be more sensible to allow users to only use a framework (like jQuery) rather than giving them access to actual Javascript? This way it might be easier to monitor.
JQuery is just plain Javascript, so if you're trying to protect from attacks, it won't help at all.
If it is crucial to prevent these kind of attacks, you can implement a custom language, parse it in the backend and produce the controlled, safe javascript; or you may consider another strategy, like providing an API and accessing it from a third-party component of your app.
Take a look at Google Caja:
Caja allows websites to safely embed DHTML web applications from third parties, and enables rich interaction between the embedding page and the embedded applications. It uses an object-capability security model to allow for a wide range of flexible security policies, so that the containing page can effectively control the embedded applications' use of user data and to allow gadgets to prevent interference between gadgets' UI elements.
Instead of checking for evil things like script includes, I would go for regex-based whitelisting of the few commands you expect to be used. Then involve a human to authorize and add new acceptable commands to the whitelist.
Think about all of the things YOU can do with javascript. Then think about the things you would do if you could do it on someone elses site. These are things that people will do just because they can, or to find out if they can. I don't think it is a good idea at all.
It might be safer to design/implement your own restricted scripting language, which can be very similar to JavaScript, but which is under the control of your own interpreter.
Probably. The scope for doing bad things is going to be much greater than it is when you simply allow HTML but try to avoid alloing JavaScript.I do not know.Well, two things: do you really want to spend your time doing this, and if you do this you had better make sure they see the javascript code rather than actual live JavaScript!I can't see why this would make any difference, unless you do have someone approving posts and that person happens to be more at home with jQuery than plain JavaScript.
Host it on a different domain. Same-origin security policy in browsers will then prevent user-submitted JS from attacking your site.
It's not enough to host it on a different subdomain, because subdomains can set cookies on higher-level domain, and this could be used for session fixation attacks.
During a recient PCI audit the auditor said that we had major security risks because
It was possible to download static resources from our website such as images css and javascript without prior authentication.
Our javascript had comments in it.
Personally I think that this is not a security risk at all. The images css and javascript where not dynamically created and they contained no data on our backend, our customer details and on mechanisms.
The comments within the javascript were just simply explaining what the methods in the javascript file did. Which anyone who reads JS could have found out anyway.
How does that show "information leakage"?
Are comments within javascript really a security risk?
Depending on how strict the audit, downloading images etc without authentication COULD be seen as a security risk (think diagrams, charts, graphs...).
Removing comments in the javascript is like obfuscating the code: it makes it a bit harder, but still not impossible to understand what's going on. JavaScript should be seen as enhancing-only anyway, all your security should be (duplicated) at server-side. Having anyone understand what the JS does should not be considered a risk.
It depends on the content of the commentary. Because there is no way, without human intervention, to examine the content of comments to determine whether they are risky, the most efficient way to audit this is to declare all comments in client-facing source code to be risky.
The following are examples of potentially risky comments.
// doesn't really authenticate, placeholder for when we implement it.
myServer.authenticate(user,pass);
or
// don't forget to include the length,
//the server complains if it gets NaN or undefined.
function send_stuff(stuff, length) {
...
}
or
function doSomething() {
querystring = ""
//querystring = "?TRACING_MODE=true&"
...
//print_server_trace();
}
Another example might be if you include a source code history header, someone might be able to find some security weakness by examining the kinds of bugs that have been fixed. At least, a cracker might be able to better target his attacks, if he knows which attack vectors have already been closed.
Now, all of these examples are bad practices anyway (both the comments and the code), and the best way to prevent it is by having code reviews and good programmers. The first example is particularly bad, but innocent warnings to your team mates, like the second example, or commented-out debugging code, like the third, are the kinds of security holes that could slip through the net.
Without getting into if they are a security risk or not, minify your JS on production environment, this will prevent the "information leakage" and help (in some way at least) to secure the information of your website.
regarding the security risk, I don't think JS comments are a risk at all, every website content (static) can be downloaded without authentication. (unless defined otherwise)
Not if they only reveal how the code works. Any sufficiently determined person could find that out anyway.
That said, it is probably a good idea to minify the JavaScript; not because of security, but because it will reduce download times and therefore make your site a bit more responsive.
JavaScript comments can be. depends on your logic, but certainly as it is publically available, you are giving more visibility to the workings of your code.
There are other reasons for removing this as as well, such as file size, and as a result download size.
Tools such asd JSMin can help you remove the comments and perfrom a crude obfuscation of the code.
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)