I've written an intercepting proxy and I'm working on adding a feature to it wherein it removes all JavaScript (and VBScript and any plugin content such as Flash, Silverlight, ActiveX components, and Java Applets which can run arbitrary, if sandboxed, code which interacts with the page) from the webpages which are received through it. If removing the page content is "the easy part", getting an exhaustive list of places where such things can hide might be the "hard part".
Of course, JavaScript can include other JavaScript in various ways such as adding a new script element to the dom. This doesn't concern me because if I head off all ways in which the HTML and/or CSS can pull in JavaScript, I don't need to be concerned that JavaScript can pull in other JavaScript. (Or that Flash can pull in JavaScript or that JavaScript can pull in Flash content etc.)
The ways I've identified in which a page can include JavaScript (or VBScript) are:
A script tag, either inline or with a "src=" attribute for an external file.
An "onload=", "onclick=", "onmouseover=", or other "on_event_=" attribute.
"javascript:" urls in "href=" attributes on a tags.
There's the CSS 'background-image: url("javascript: ...")' trick (though it doesn't work in all browsers).
One question I have is whether I need to worry about "javascript:" urls in places other than "href=" attributes on a tags. I know some older browsers (such as IE6) execute the JavaScript in a "javascript:" url in a "src=" attributes in img tags. That doesn't concern me simply because I'm not writing my intercepting proxy for use with browsers as old as IE6. But if there are other "tricky" places in which "javascript:" urls might be executed, that would be good to know. (Maybe in frame and iframe "src=" attributes?)
And, of course, any other ways JavaScript might be executed that I haven't considered.
The ways I've identifid in which a page can include other (sandboxed) code are:
embed tags.
object tags.
applet tags.
One question I have here (and this may be considered "future-proofing") regards how WebAssembly bytecode is loaded. Just my cursory googling hasn't determined how that works exactly.
While PDF's can be loaded in most modern browsers without extensions or anything, I consider PDF's to be outside of the scope of this question because while they can include arbitrary (sandboxed) code, this code cannot interact with the webpage.
I also consider things such as HTML5 video to be outside the scope of this question because they don't run arbitrary code.
I'm also not concerned with any ways in which JavaScript or plugins might execute which require the presence of browser extensions unless said extensions are extremely widely used.
I do, however, desire for this script and plugin stripping feature to be ironclad. If somebody were able to use tricky measures to slip code by this feature, the tricky measures which might be employed are relevant to this question as far as I'm concerned.
And, ways to include code which only work in some browsers and not others are also in-scope.
Are there any other kinds of plugins or languages that can be included in a webpage that I haven't considered above?
I am building a tool which uses (dynamically inserted) JavaScript to modify webpages. Any webpage.
The idea is to allow a user to use it to record a series of changes to an existing webpage like google.com, (for the sake of example suppose a change is to apply a 10 pixel solid black border to all <img> tags, this change can obviously be encoded as a short and sweet snippet of jQuery), and the tool generates a link (or identifier) that contains this metadata and the url representing the "starting point" if you will (in this case google.com).
Now the problem I've run into is the entire Same-Origin security policy, whose purpose is to expressly deny the exact kind of thing that it seems like I need to do.
What I need to do is essentially navigate to a particular site, and then execute javascript in the context of that site. Neither I (the author of the tool) nor the user with whom I share my script necessarily have control over the site, so in theory the security model if implemented properly should prevent this concept from working.
Because of this I cannot have a single clickable link that kicks off the process of running my code on some site. It totally makes sense too. It would make it trivial for an attacker site to send a disguised clickable link that will run code that acts as me on any site they want.
But, the way to get around it is to tell the recipient to do a single additional step. First they open the URL of the site just like normal, then they paste a bit of javascript:(function(){.....})(); into the URL/omni bar. That is (AFAICT) completely legitimate and should be permissible because the user understands that this script is being executed. Whether or not it should be allowed to run JS so easily at this point is more or less irrelevant, as it basically just works everywhere now.
This isn't too bad but I think the user experience suffers unnecessarily. For example it looks like a native app would be necessary to get any better than pasting the JS into the URL bar on an iOS device for example, but on a plugin-accepting full browser it seems like a plugin can achieve what I want.
Which is: a navigation to an arbitrary URL followed by code execution (this code originating from an authorized source) with one click.
But I'm not sure where to start. What API could provide me this ability? I am hoping I can get away with Greasemonkey-type scripting (as Greasemonkey compatible plugins are available for pretty much all the good browsers), but I can't tell if there is enough power available.
I am actually still a little unsure about security related problems with this. I used to have a huge paragraph here but it all boils down to "social engineering".
This kind of things are generally done with bookmarklets.
On your website featuring your script, create a link that has href="javascript:(function(){/* ... */})()". Then a user could simply drag and drop that link into his favourites (bookmark it). And use it as button in a favourites bar.
Your bookmarklet could contain directly your script, or a simple loader that injects a <script src=http://mywebsite.com/script.js"> tag into the document, this way you can update your script and "distribute" it directly to all users.
Security is always about knowledge. Or to put it the other way around: Not knowing something makes you feel insecure.
There is no secure way to do what you want which is my web browsers forbid it by default. There are workarounds (like pasting the URL as you explained above) but all of them are only secure as long as the user knows what she is doing.
That being the social implications. Now the technical solutions:
You try a bookmarklet
You can use a browser plugin like Greasemonkey
Both allow to run arbitrary JavaScript. The former needs explicit permission from the user each time, the later one does it automatically.
Of course, if you move the core of the functionality to a remote place, it would be hard for even knowledgeable users like me to understand and trust what is going on.
That is when the meat of the function isn't in the bookmarklet or the greasemonkey script and when you instead add a <script> tag with a remote URL. That would make it harder to make sure your script doesn't do something "odd". For example, you could return a different script when I try to download the JavaScript without using your bookmarklet.
I have a page which displays a different website (say www.cnn.com) in an iframe.
All I want, is to make links inside the iframe open in the parent window, and not inside the frame.
I know that this is normally impossible for security reasons, which makes good sense to me. However, the page I'm working on is not going to be public, but only on my private computer, and if I have to switch off certain security features to make it work, it's OK.
Is there any way at all to do this?
I have been combing through the web all day for a solution. If I missed a post here or elsewhere, please point me to it.
I read that in Firefox (which I'm using), it's possible to get extended permissions in javascript if the script is "signed" (or a particular config entry is changed). However, I don't know how to exploit these extended permissions for my purpose...any hints?
I'd also consider different approaches, e.g. not using iframes at all. Whatever the method, I want to be able to embed several websites, which I have no control over, within one page. Links clicked in any of the embedded websites should open in the parent window. It's just supposed to be a handy tool for myself. I should say that I have basically no knowledge of javascript and am just learning by doing. If you can confidently say that what I want is not possible with any client-side methods, that would help as well. I guess it would be rather straighforward to do it e.g. with php but I don't want to setup a webserver if it's not necessary. Thanks for any tips!
This is a bit different solution than you asked for, but might be a better way to attack the problem as it might give you the ability you seek without compromising any normal web security.
I wonder if Greasemonkey (add-on for Firefox and other browsers) might be a useful solution for you as it allows you to run local javascript against other pages to modify them locally, somewhat regardless of normal security restrictions. So, you could run through all the links in a CNN page and modify them if that's what you needed to do.
To use it, you would install the greasemonkey add-on into Firefox, write a script that modifies CNN.com the way you want to, install that script into Greasemonkey, then target the script at just the web page CNN.com. I think it should work on that site whether it's in an iframe or not, but your script could likely detect whether it was in an iframe if you needed to.
It would appear the HTML5 seamless attribute would be what you are looking for. But it doesn't appear that anything supports it yet...
http://www.w3schools.com/html5/att_iframe_seamless.asp
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)
According to this page it would seem like they don't, in the sense that they don't actually run it, but that page is 2 years old (judging from the copyright info).
The reason I'm asking this question is because we use Javascript to replace text on our site with other more typographically sound content. We're worried that this may affect the crawlability/seo of our sites, since generally what we're replacing is headers; ie. <h1>, <h2>, etc.
Will search engine bots see our original code, or will they run the Javascript and see the replaced text?
Google now officially processes JavaScript.
In order to solve this problem, we decided to try to understand pages by executing JavaScript. It’s hard to do that at the scale of the current web, but we decided that it’s worth it. We have been gradually improving how we do this for some time. In the past few months, our indexing system has been rendering a substantial number of web pages more like an average user’s browser with JavaScript turned on.
Sometimes things don't go perfectly during rendering, which may negatively impact search results for your site. Here are a few
potential issues, and – where possible, – how you can help prevent
them from occurring:
If resources like JavaScript or CSS in separate files are blocked (say, with robots.txt) so that Googlebot can’t retrieve them, our
indexing systems won’t be able to see your site like an average user.
We recommend allowing Googlebot to retrieve JavaScript and CSS so that
your content can be indexed better. This is especially important for
mobile websites, where external resources like CSS and JavaScript help
our algorithms understand that the pages are optimized for mobile. If
your web server is unable to handle the volume of crawl requests for
resources, it may have a negative impact on our capability to render
your pages. If you’d like to ensure that your pages can be rendered by
Google, make sure your servers are able to handle crawl requests for
resources.
It's always a good idea to have your site degrade gracefully. This will help users enjoy your content even if their browser doesn't have
compatible JavaScript implementations. It will also help visitors with
JavaScript disabled or off, as well as search engines that can't
execute JavaScript yet.
Sometimes the JavaScript may be too complex or arcane for us to execute, in which case we can’t render the page fully and accurately.
Some JavaScript removes content from the page rather than adding, which prevents us from indexing the content.
Search engines don't process JavaScript as such.
There is some evidence that Google may have started processing inline script content in some cases, in order to catch content that is entered into the page parse queue using document.write. However certainly DOM methods such as you might use for font-replacement are not affected and no onload code is invoked.
Generally no. Google has mentioned that they are working on a system of indexing ajax content, but I don't think any of the major search engines index dynamic content as a rule. See this page for Google's take on it: http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=81766
The bots will certainly not run the Javascript code, but they might recognise some commonly used scripts.
You shouldn't count on it though. Clear markup, proper content and real links is still what counts.
Also, if the bots happen to recognise your script, it might not be in your favor. If the code is recognised as something that is commonly used to try to fool bots, it could even hurt your page ranking.
I'd use metadata to ensure bots pick up the content on your pages.
I know the general consensus is that google does not process javascript or index anything with a <script> tag, however, the general consensus appears incorrect.
Try searching for the following, with the surrounding quotes (or click here):
"Samsung Public Interest Statement by Thomas Fusco, Fish & Richardson P.C., for Samsung."
You should only get one result. Now click on that result (or just click here) and view the source.
Do a CTRL-F for the text you searched for in Google. Notice that the text is in a javascript variable, and not html. Google must be processing some javascript to pull those words into its index.