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.
Related
I'm looking for a simple method of encrypting a small portion of my personal developer website. I'd like to display my resume directly on the site, but would prefer to protect it with a password so as to prevent those who are not potential employers from viewing it. What is a safe way of doing so while imposing a limited strain on potential employers (e.g. not requiring them to create an account)?
Notably, I will not be including information like my SSN or anything particularly sensitive -- just regular resume info. For this reason, would it be okay to provide all potential employers with the key, and rotating it every month-or-so?
I'm using Lit as a web component tool, but otherwise the site is vanilla JS + html.
Thanks for any guidance!
Some shared hosting providers offer password protection as part of their package. You could contact your host and see if that's an option.
Otherwise the simplest password protection solution which doesn't require any third party tools would be to update your .htaccess file to require a password. See this question for examples on setting it up.
Please note, that this should not be considered a completely secure solution, because it's only basic authentication which can be vulnerable to brute force attacks. However it should satisfy your requirement of adding some protection your personal information.
What are the techniques and the tools, libraries and frameworks necessary to make a SPA in java (and javascript)?
Consider an application served by a server A. This server might go offline.
What I need is a partially functional, read-only version of that application on a second server B, but fully navigable.
Server B can only serve static files: html, css, js, images.
Server A has access to server B and can push data to it as required and on a regular basis.
My second requirement is to suffer as less as possible from vendor lock-in, so I should be using as little frameworks as possible.
The third requirement is: there should be no necessity of any tool on the client's side, in the browser.
Please list the possible techniques, and where applicable, also at least one tool/framework/library, so I can search for alternatives to that one if, for whatever reason, it doesn't fit my bill.
If you accept any client-side code:
Yes, the best answer are service workers.
You can read about various caching techniques on Jake's site
Easiest plugin to make your website accessible offline is https://github.com/GoogleChrome/sw-precache.
Service workers are framework-agnostic, you can use them with all frameworks or without one in JavaScript.
You will need typical backend (Java/PHP?) or even static html files, and JavaScript client-side code.
If you don't accept any client-side code and accept 3rd parties:
The only solution is to have some kind of proxy like CloudFlare - your DNS will point to CloudFlare, and they you set up what will happen.
If you don't accept any cliend-side code and don't accept 3rd parties:
If you want your solution exactly as you've described, you should use some kind of load balancer like HAProxy (http://www.haproxy.org/), which will route your traffic to failover server. You can read about this here: http://blog.haproxy.com/2013/12/23/failover-and-worst-case-management-with-haproxy/
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.
We are going to design and implement a UI for a big website. Owner of the site is really cautious about security issues. I wonder if there is a check list for client-side security recommendations, when designing and coding in Javascript.
You may use the OWASP guide as a start. It offers a suite of tests that you can systematically use to check your application for common vulnerabilities.
Web application pen testing is a buzz word for what you are trying to achieve. Scan the net for automated tools and background information.
Edit:
You mentioned that not only the client side is your concern, but the overall security of the entire application including the server. My advice would be that if you have never done security assessment of an application before, your boss/the owner of the site should probably consider hiring an external company/consultant for the job. They will do the job for less than it would probably cost if you and your team had to learn the details first. Plus, they have the advantage of having this done over and over again, so they are much less likely to overlook important details.
Javascript can easily be tricked. You need to build a system with server side has all the security and the client side will only acts as a interface similar to browser.
Encrypting using strong security certificate will also be an option you may consider.
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.