I've read http://www.json-p.org/ which states a safer and stricter subset of JSON-P.
The most critical piece of this proposal is that browser vendors must
begin to enforce this rule for script
tags that are receiving JSON-P
content, and throw errors (or at least
stop processing) on any non-conforming
JSON-P content.
My question is Is that subset of JSON-P already implementable?
No, there is no current way to implement/enforce what is proposed, as changes to how browsers process the script tag are required. If you really wanted to implement the proposal, you could build a proxy service on your server which does the JSONP verification for you.
The only real problem this proposal is trying to solve is to make JSONP requests more secure for consumers of JSONP enabled services. However, I honestly think this security problem is a non-issue.
As long as web service consumers are using trusted JSONP services, there is no JSONP specific security threat. If you think the service you are consuming might be untrustworthy, simply don't use it. You can find an alternative service or proxy the untrustworthy service through your own server to clean/verify the response.
The same vulnerabilities which exist for JSONP also exist for ordinary script tags. People link to third party JavaScript libraries all the time with few issues. As an example, people everywhere use Google's copy of jQuery. Google could easily poison this file and fish user data from any webpage which uses this library.
The moral of the story: Only use APIs/services you trust
Related
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'm in the process of building out an infrastructure to support a gaming platform we intend to scale out to hundreds of thousands of users. Since this is in the entertainment / gaming industry, we are expecting a heavy load from each user session, therefore, performance is of upmost importance.
We are trying to parallelize as much of the architecture as possible, meaning API, databases, and applications run off of different servers that can be horizontally scaled. One of the applications is a web app, and we're having the most trouble with this due to a specific scenario involving the same origin policy on legacy browsers.
This application running in the web browser will need speedy access to the models only available through the centralized API. While this is great for our dedicated mobile clients, browsers unfortunately need fully CORS support to interface directly with our API. This is problematic because some of the HTTP verbs are not supported on all browsers (put / delete). Our only known workarounds are, rewrite the API to create more abstraction (we believe this is not a best practice and will increase development time and potentially performance) and work with only POST using JSONP or create a proxy (which will add an extra two leg to the trip and double the latency performance).
Bottom line is, we have boiled this question down to... are these the only two options, or is there something else we aren't considering, and if so, which of these solutions would be better suited to a gaming platform.
Another option to consider is JSONP. By wrapping a JSON response to enable it to be loaded as a script tag, you can avoid problems with the same origin policy.
I can't speak to performance issues of your specific application without knowing the app in detail. I would think that you would see similar performance on the server with JSONP, since your major difference over other methods would be that you are concantenating an extra string.
SOP should not be the problem. Use JSONP for domain-across requests. Wrapping the answer in in a callback method should not be the problem for your server-side part and sould be transparent for the rest of the application. Doesn't break REST style. On client-side library the use of JSONP should also be transparent for the rest of the application.
So, what's about PUT and DELETE? Simply perform a POST and set the X-HTTP-Method-Override header with the intended method. Your webservice handler on the serverside should recognize the header and imply the request with the method from the header. All transparent to the rest of the application.
While JSONP certainly does have "universal" support - it's still a bit hacky and has a few negative side effects: mainly that you can't capture errors.
The reason JSONP works everywhere is because requests made by the script tag fall within the confines of a "simple request", as defined by the CORS specification.
My point? Instead of using JSONP, you could also modify your API (or at least the most commonly accessed parts of it) to fit within the confines of a simple request. Then you get full ability to handle errors without any of the performance impact of preflight requests.
For the places you must use preflight requests, you can cache the preflight responses.
I have a full write up on this technique at Two Strategies for Crossing Origins with Performance in Mind
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.
I'm developing a scripting extension, similar to Greasemonkey or Chrome's content-script engine. This extension will allow script writers to do very dangerous things like access local files.
If I ever release this extension to the public, I would like it to be able to warn novice users if a script will use a "dangerous" function. I'd like this warning to be as hard to circumvent as possible.
For example, the extension can search for the protected string GM_openSQL_Connection and warn the user -- maybe like this:
Assume that the base web page will never be able to access GM_openSQL_Connection thanks to sandboxing mechanisms. Likewise, no <script> node will be able to.
But, the script writer could still circumvent the simple search, from above, with something like:
eval (decodeURI ("GM_op%65nSQL_Connection (...);") )
So the question is what are the kinds of ways in which an evil scripter can fool the check for restricted function usage, and how might I prevent such mischief?
Note: false warnings can be okay. For example if the script author uses the text "GM_openSQL_Connection" in an otherwise static string, then he will just have to put up with the (false) warning.
What are the ways in which an evil scripter can fool the check for restricted function us[age]?
There are thousands of combinations, for example, with eval(), new Function(), combinations of String.fromCharCode() and decodeURI() (like in your example).
How might I prevent such mischief?
Could you overload/shadow specific bad functions/objects/variables?
GM_openSQL_Connection = function() {
warnUser();
};
To set a flag if the extension attempts to access a forbidden function or variable, simply have a var isDangerous = false which is set to true if a forbidden function is called or the get/set on a forbidden property is accessed/modified.
If the isDangerous is true, then you can mark that extension as potentially having dangerous function/property calls/accesses.
Trying to scan the script to detect whether it uses any of these interfaces is the wrong approach. It is too easy to evade through obfuscation, as you seem to be discovering. It's fundamentally insecure: there's no way to make it work.
Here is a better approach. Require the script-writer to include a manifest that declares what special APIs it needs access to. Then, run the script in a secure Javascript sandbox which only exposes the allowed APIs and APIs it has requested, but nothing more. If the script doesn't request GM_openSQL_Connection in its manifest, don't expose that API to the script.
Because Javascript is a dynamic language that allows monkey-patching and unrestricted access to the global object, it takes some doing to build a secure sandbox that restricts what APIs the script can access. Therefore, I recommend that you use an existing sandboxing solution. One approach is to run the user script in a sandbox, and give the sandboxed code a library that's full of stubs for the sensitive APIs, where the stubs just use postMessage to send a RPC request to your extension code. This avoids having references that cross the sandbox boundary, which is good as (depending upon sandboxing technology) those kind of references typically carry a substantial potential for security vulnerabilities.
Then, you can drive your user warnings based upon the contents of the manifest. Important: please think carefully about this from a user's perspective. Will ordinary users be able to make sense of the warnings? Will they be able to make sensible decisions? Will users be in a better position to make good decisions than you will? Will users be overwhelmed by constant warnings, and just start ignoring them and clicking 'ok' (the cry-wolf effect)?
For information on technology for Javascript sandboxing, please read the following question on IT Security: How to scan Javascript for malicious code?. In the future, you might get answers on the IT Security site for this kind of question.
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.