I'm trying to find a solution for the following situation:
I've a web application made of HTML, javascript, AJAX, ad so on.
I want users to contribute to my application/website creating plugin that will embedded in it.
This plugin will be created using similar technologies (ajax, HTML, etc) so i need to allow plugins to run their own javascript code.
Each plugin will work in a page that will contain some user information and the plugin (like old fbml facebook applications)
The problem is that in this way the plugin can also made calls to get users information. (because since plugin's code is embedded it's domain will be the same of the main website, and the code will be entirely on my website).
So the question is: how can I avoid it and have a precise control about what information a plugin can get about the user?
The plugin will not be checked and can be changed anytime, so reading all the plugin code is not a solution.
I'm open to any proposal, possibly easy and effective, and possibily not putting the whole plugin in a iframe.
--
EDIT:
How did facebook do when there was the old way to create applications? (now it's only iframe, but there was FBML application way, how did they get this secure?)
Have you ever heard of exploits allowing arbitrary code execution. Which is one of the most dangerous attacks ?
Well, in this case you are explicitly and willingly allow arbitrary code execution and there's almost no way for you to sand box it.
1) You can run the "plugin" within an iframe from a different subdomain to sandbox it in there, as you've mentioned. This way plugin can't reach your cookies and scripts.
Note that, if you want the plugins to communicate with your services from this domain, then it will be cross-domain communication. So you either need to resort to JSONP or use new cross domain access control specifications. (i.e. return appropriate headers with your web service response -- Access-Control-Allow-Origin "plugins.domain.com")
2) Create your own simple scripting language and expose as much as you want. This is obviously tedious, even if you manage to do that, plugin developers will endure a learning curve.
Facebook had their own "JavaScript" coined FBJS which did the sandboxing by having control over what could run.
Without a juicy backend, this really limits the impact of your script.
However you still have to worry about DOM based xss and Clickjacking
It's 6 years later, but I feel it's important to provide a modern solution to this. The new(er) sandbox attribute can be used to limit the capabilities of an IFrame.
A simple implementation of this system would allow only the allow-scripts permission to the IFrame, perhaps with a simple JS file which would be included along with each plugin containing a few custom library functions.
In order to communicate with your HTML page, you would use postMessage. On the plugin end, a library like I mentioned above could be used to transfer commands. On the user side, another system would have to validate and decode these requests then execute them.
Since a sandboxed IFrame doesn't have cross origin capabilities, it cannot directly modify the page. However, this also means the origin of the postMessage can't be verified, so some sort of code would have to be created for security reasons.
Related
I've made a tool take people can use and its made in Javascript.
They generate the code and then paste it into their webpage code.
I am just wondering how would I go about making it work in forum posts, or other site posts or do the websites normally block this sort of thing?
Would it be possible to convert it for social media sites also? Like have it so the users can interact with it inside posts? Thanks!
So first a warning: DO NOT DO THIS THE WAY THAT YOU HAVE IT RIGHT NOW
You are forcing people to inject a script directly into their website directly from your servers. This script sets and users global variables and can break other things. I would be very very angry if someone added something like this to a site I ran. For example your script creates a function called clicked() in the global scope. What if the site already had a function named that on it? Then all of a sudden that site breaks. It is possible to do this without these issues (see how twitter buttons work for example) but it still has limitations.
Doing this in the way you have it set up looks to another site exactly like an XSS (Cross Site Scripting) attack so no, you cannot do this in forums/etc - they specifically disallow it.
Occasionally a forum might allow iframes (they have much better security for the including site). In your case using iframes would actually be a much cleaner solution. Simply have them include an iframe that points to your site. Your site then (using php, .Net, node, perl, whatever server scripting language you want) would reply with the markup that you want. You can pass the parameters you want as parameters in your url.
I am building a 3rd party widget
We drop a script on a clients page and load some content.
The problem I face is how do I secure my widget. As a thrid party widget I know there is no 100% way to secure it. But trying to work out a 'good enough' approach.
I want to make it difficult for a non customer to just rip our script off their competitor site and use it on theirs.
The solutions I see is pull validate requesting domain (which I know could be spoofed, not sure if I can guard against this?)
I had a look at other widgets like olark and olapic that use unique id's per client in their script , but cannot see how helpful that is.
What are the best practices to secure a third party widget?
Securing a tenant's client access
Securing a tenant's 3rd party client access to your Javascript poses a unique set of challenges. Most of the difficulty in this solution stems from the fact that the authentication mechanism must be present in the tenants web content and delivered from their clients browser. Standard client<>server authentication mechanisms such as sessions, cookies, custom headers, referrers and IP address restriction do not apply well due to the extended nature of the transaction.
This article by Bill Patrianakos provides a solution by using a dynamic key request that provides an access token to the tenant's client.
Patrianakos provides some good information on Third Party tenant relationships and discusses some the limitations of this model in his article.
Securing the Javascript code
Protecting your code in Javascript is difficult due to the requirement that the code is interpreted at runtime by the client browser. However, it is possible to obfuscate your Javascript by using the Google Closure Compiler. The advanced optimization features of the compiler offer low-level reference renaming and also provides more compact code for delivery of your widget.
To compile your Javascript using advanced optimizations use the following command line:
java -jar compiler.jar --compilation_level ADVANCED_OPTIMIZATIONS \
--js myWidget.js --js_output_file myWidget.min.js
There are some important caveats. This article covers some of the things to avoid in your code to ensure that the code will function correctly. I would also recommend a good qunit test frame to ensure that your widget will operate properly.
To secure the widget, if you want to prevent forged requests then you need to open a popup and open a page from your server which is completely under your control, and confirm any actions such as 'publish tweet' there.
See the answer for this question for some more extended discussion.
For preventing your Javascript from being stolen, minification is not sufficient - it's better to use an obfuscator. Have a look for example [JScramble], this is a presentation on how it works.
I've got a complex page that can be customized and should be embedded in some clients' websites. For each client it should look the same, but the parameters can be little different. The page also contains a custom object that uses a plugin in the browser.
I had 2 idea to accomplish this:
Using an iFrame - so I just embed my page and pass parameters in the
querystring.
Using a remote JS file - like Facebook SDK and others
work. Passing parameters in the JS code. As I understand, I can just put some 'parent' div on the page and the remote JS file, which should fill the parent div with the needed elements.
Which one should I use? What are the cons / pros of each one?
Thanks!
Take a look at this article which has an in depth look into the ways of what you're trying to achieve.
Pros of IFrame:
If the owner of the mashup page is really concerned with security, malicious scripts running in the widget, then the IFRAME approach is preferable, because the widget’s script will have limited access to the host page and hence couldn’t make much harm to the page where it's embedded into.
Also, this approach is preferable if the owner of the widget wants to control the layout and styling of his/her widget. Since the IFRAME is essentially a separate web page, the mashup’s CSS scripts can’t do much harm to the widget.
Cons:
it is slow, resource intensive [on the browser], and does not give the owner of the mashup page an ability to style the widgets the way s/he wants.
I've had similar issue some time ago. You bassicaly have three options to choose depending how secure and flexible your plugin should be.
iframe
pros
fairly secure - you can present data that should be viewed to specyfic user only and allow passing sensitive data to your service. Page that includes your plugin will not have access to it.
page that includes your iframe will not be able to modify it's content to confuse user
cons
slow
limited communication between your plugin and the page(may be solved by between-window post message/porthole, but this is not perfect)
page still may scam users into beliving they see your plugin, while present own copy or use click jacking
if you include any assets from 3-rd party server that bit of security you had is lost
limited to rectengular box
script
pros
extremly flexible
easy to implement variety of callbacks to react on events on the page
fast
may integrate with interface of the page in many different ways and spots
cons
basically can be modfited in any possible way by page that includes it. You have no controll what users will see in the end.
redirect through your service and then back
pros
most safe solution
cons
hardest to seamlessly integrate
may not interact with other elements of website that uses plugin(since when users see your plugin they are't seeing source website anymore)
Besides Google Libraries API what other services are there for hosted javascript libraries?
Please only list trusted sources, not some unknown third party.
Microsofts CDN
http://www.asp.net/ajaxlibrary/cdn.ashx
Before you go in search of hosted JavaScript libraries, you should consider the fact that any JavaScript that you include in your web page runs within the context of your domain and can access any data rendered on the web page or that the user can normally access on your domain. Using Google's hosted JavaScript is fine, but if its some third party you never have heard of, you might want to think twice.
Perhaps it would be better to search for high-quality JavaScript libraries and download your own copy that you maintain within your domain on your own servers (and can audit for security purposes)?
Out of curiosity... what specific functionality are you looking for?
There's also Yahoo YUI (http://developer.yahoo.com/yui/) though I believe they only host YUI itself. Make sure you pay attention to Michael Safyan's answer, too - who you're willing to trust with your users' code should be a carefully made decision. Beyond that, if you're looking for generic JS hosting you should make sure you really need it - a minified version of jQuery or MooTools is incredibly tiny, and shouldn't make any real difference either to your server's CPU usage or bandwidth expenditure.
It also doesn't meaningfully affect the maintainability of your HTML or JS, and it introduces another point of failure in your implementation.
Soon I'll be needing to build a widget that some of our clients can embed in their own websites.
To future proof my widget the embed code would be something like this:
<script type="text/javascript" src="path/to/remote/file.js"></script>
<div id="my_widget"></div>
What are the strengths and weaknesses of iframes vs JSONP?
Are there any common SEO based issues with iframes?
First of all, iframes and jsonp are not mutually exclusive: one is a rendering mean, the other is a communication mean.
Your choice is rather between in-document inclusion (that is creating the widget within the host DOM) or in-iframe inclusion (that is having a new, separate DOM for the widget).
The advantage of an iframe is sandboxing: no collision between your widget and the host's javascript and css. That means you can safely:
use/define any javascript library you want
use simple html code together with simple css rules (which is a clear bonus for maintenance)
As for the drawbacks:
an iframe is heavy-weight and may seriously slow down host page rendering
the iframe will also consume much more memory and resources, which may be a problem if the host page is targetted at mobiles
So, if it is reasonable to assume people using your widget will be willing to "adapt" their pages for it, go the in-document way. If not, use an iframe but understand the limits.
As for SEO issues, as long as you dynamically create the widget (whether it's in-document or with an iframe), search engines won't see it. I dunno if that's what you want, but that's what you'll get ;)
Heres some slides from a presentation on cross domain scripting by Alex Sexton
http://www.slideshare.net/SlexAxton/breaking-the-cross-domain-barrier
Unfortunately its just the slides so is missing the accompanying explanations but could be helpful
If you're making API calls and only fetching data, JSONP will result in better performance. If you're rendering things, then you must use iframes. If you want to prevent the host site from access to your widget data, iframes are the way to go. But if your data is public, then JSONP will result in a simpler implementation (since iframes will mean you need to deal with resizing). On the flip side, iframes provide for good CSS sandboxing, so you won't collide with the host page's CSS.
I chose to go with JSONP. You can see the details of how I implemented it here:
if I allow partner sites to republish my RSS feed, will that boost my SEO ranking?
Some people gave their opinions on SEO. I'm still not sure, however, if it helps SEO. I just got an idea to test it though, and I'm going to carry it out right now! I'm going to make a page with just the JavaScript that renders the widget (feed in this case). Then, I'll use Google's Webmaster Tools to see if Google picks up any of the keywords in the feed content. I'll post the answer to the link above after I get the results.
Wish us the best!
Matt