Related
Javascript doesn't let you give private data or methods to objects, like you can in C++. Oh, well actually, yes it does, via some workarounds involving closure. But coming from a Python background, I am inclined to believe that "pretend privacy" (via naming conventions and documentation) is good enough, or maybe even preferable to "enforced privacy" (enforced by Javascript itself). Sure, I can think of situations where this is not true -- e.g. people interface with my code without RTFM but I get blamed -- but I'm not in that situation.
But, something gives me pause. Javascript guru Douglas Crockford, in "Javascript: The Good Parts" and elsewhere, repeatedly refers to fake-privacy as a "security" issue. For example, "an attacker can easily access the fields directly and replace the methods with his own".
I'm confused by this. It seems to me that if I follow minimal security practices (validate, don't blindly trust, data sent from a browser to my server; don't include third-party scripts on my site without inspecting them) then there is no situation where pretend-privacy is less "secure" than enforced privacy. Is that right? If not, what's a situation where pretend-privacy versus enforced-privacy has security implications?
Not in itself. However, it does mean you cannot safely load untrusted JavaScript code into your HTML documents, as Crockford points out. If you really need to run such untrusted JavaScript code in the browser (e.g. for user-submitted widgets in social networking sites), consider iframe sandboxing.
As a Web developer, your security problem is often that major Internet advertising brokers do not support (or even prohibit) framing their ad code. Unfortunately, you have to trust Google to not deliver malicious JavaScript, whether intentionally or unintentionally (e.g. they get hacked).
Here is a short description of iframe sandboxing I had posted as an answer to another question:
Set up a completely separate domain name (e.g. "exampleusercontent.com") exclusively for user-submitted HTML, CSS, and JavaScript. Do not allow this content to be loaded through your main domain name. Then embed the user content in your pages using iframes.
If you need tighter integration than simple framing, window.postMessage() may help, allowing scripts in different frames to communicate with each other in a controlled manner.
It seems the answer is "No, fake privacy is fine". Here are some elaborations:
In javascript as it exists today, you cannot include an unknown and untrusted third-party script on your webpage. It can wreak havoc: It can rewrite all the HTML on the page, it can prompt the user for his password and then send it to an evil server, etc. etc. Javascript coding style makes no difference to this basic fact. See PleaseStand's answer for a discussion of methods to deal with this.
An incompetent but not evil script might unintentionally mess things up through name conflicts. This is a good argument against creating lots of global variables with common names, but has nothing to do with whether to avoid fake-private variables. For example, my banana-selling website might use the fake-private variable window.BANANA_STORE_MODULE.cart.__cart_item_array. It is not completely impossible that this variable would be accidentally overwritten by a third-party script, but it's extraordinarily unlikely.
There are ideas floating around for a future modification of javascript that would provide a controlled environment where untrusted code can act in prescribed ways. I could let the untrusted third-party javascript interact with my javascript through specific exposed methods, and block the third-party script from accessing the HTML, etc. If this ever exists, it could be a scenario where private variables are essential for security. But it doesn't exist yet.
Writing clear and bug-free code is always, obviously, helpful for security. Insofar as truly-private variables and methods make it easier or harder to write clear and bug-free code, there's a security implication. Whether they are helpful or not will always be a matter of debate and taste, and whether your background is, say, C++ (where private variables are central) versus Python (where private variables are nonexistent). There are arguments in both directions, including the famous blog post Javascript Private Variables are Evil.
For my part, I will keep using fake privacy: A leading underscore (or whatever) indicates to myself and my collaborators that some property or method is not part of the publicly-supported interface of a module. My fake-privacy code is more readable (IMO), and I have more freedom in structuring it (e.g. a closure cannot span two files), and I can access those fake-private variables while I debug and experiment. I'm not going to worry that these programs are somehow more insecure than any other javascript program.
A persistent follow-up of an admittedly similar question I had asked: What security restrictions should be implemented in allowing a user to upload a Javascript file that directs canvas animation?
I like to think I know JS decent enough, and I see common characters in all the XSS examples I've come accoss, which I am somewhat familiar with. I am lacking good XSS examples that could bypass a securely sound, rationally programmed system. I want people to upload html5 canvas creations onto my site. Any sites like this yet? People get scared about this all the time it seems, but what if you just wanted to do it for fun for yourself and if something happens to the server then oh well it's just an animation site and information is spread around like wildfire anyway so if anyone cares then i'll tell them not to sign up.
If I allow a single textarea form field to act as an IDE using JS for my programming language written in JS, and do string replacing, filtering, and validation of the user's syntax before finally compiling it into JS to be echoed by PHP, how bad could it get for me to host that content? Please show me how you could bypass all of my combined considerations, with also taking into account the server-side as well:
If JavaScript is disabled, preventing any POST from getting through, keeping constant track of user session.
Namespacing the Class, so they can only prefix their functions and methods with EXAMPLE.
Making instance
Storing my JS Framework in an external (immutable in the browser?) JS file, which needs to be at the top of the page for the single textarea field in the form to be accepted, as well as a server-generated key which must follow it. On the page that hosts the compiled user-uploaded canvas game/animation (1 per page ONLY), the server will verify the correct JS filename string before echoing the rest out.
No external script calls! String replacing on client and server.
Allowing ONLY alphanumeric characters, dashes and astericks.
Removing alert, eval, window, XMLHttpRequest, prototyping, cookie, obvious stuff. No native JS reserved words or syntax.
Obfuscating and minifying another external JS file that helps to serve the IDE and recognize the programming language's uniquely named Canvas API methods.
When Window unloads, store the external JS code in to two dynamically generated form fields to be checked by the server in POST. All the original code will be cataloged in the DB thoroughly for filtering purposes.
Strict variable naming conventions ('example-square1-lengthPROPERTY', 'example-circle-spinMETHOD')
Copy/Paste Disabled, setInterval to constantly check if enabled by the user. If so, then trigger a block to the database, change window.location immediately and check the session ID through POST to confirm in case JS becomes disabled between that timeframe.
I mean, can I do it then? How can one do harm if they can't use HEX or ASCII and stuff like that?
I think there are a few other options.
Good places to go for real-life XSS tests, by the way, are the XSS Cheat Sheet and HTML5 Security Cheetsheet (newer). The problem with that, however, is that you want to allow Javascript but disallow bad Javascript. This is a different, and more complex, goal than the usual way of preventing XSS, by preventing all scripts.
Hosting on a separate domain
I've seen this referred to as an "iframe jail".
The goal with XSS attacks is to be able to run code in the same context as your site - that is, on the same domain. This is because the code will be able to read and set cookies for that domain, intiate user actions or redress your design, redirect, and so forth.
If, however, you have two separate domains - one for your site, and another which only hosts the untrusted, user-uploaded content, then that content will be isolated from your main site. You could include it in an iframe, and yet it would have no access to the cookies from your site, no access to redress or alter the design or links outside its iframe, and no access to the scripting variables of your main window (since it is on a different domain).
It could, of course, set cookies as much as it likes, and even read back the ones that it set. But these would still be isolated from the cookies for your site. It would not be able to affect or read your main site's cookies. It could also include other code which could annoy/harrass the user, such as pop-up windows, or could attempt to phish (you'd need to make it visually clear in your out-of-iframe UI that the content served is not part of your site). However, this is still sandboxed from your main site, where you own personal payload - your session cookies and the integrity of your overarching page design and scripts, is preserved. It would carry no less but no more risk than any site on the internet that you could embed in an iframe.
Using a subset of Javascript
Subsets of Javascript have been proposed, which provide compartmentalisation for scripts - the ability to load untrusted code and have it not able to alter or access other code if you don't give it the scope to do so.
Look into things like Google CAJA - whose aim is to enable exactly the type of service that you've described:
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.
One issue here is that people submitting code would have to program it using the CAJA API. It's still valid Javascript, but it won't have access to the browser DOM, as CAJA's API mediates access. This would make it difficult for your users to port some existing code. There is also a compilation phase. Since Javascript is not a secure language, there is no way to ensure code cannot access your DOM or other global variables without running it through a parser, so that's what CAJA does - it compiles it from Javascript input to Javascript output, enforcing its security model.
htmlprufier consists of thousands of regular expressions that attempt "purify" html into a safe subset that is immune to xss. This project is bypassesed very few months, because it isn't nearly complex enough to address the problem of XSS.
Do you understand the complexity of XSS?
Do you know that javascript can exist without letters or numbers?
Okay, they very first thing I would try is inserting a meta tag that changes the encoding to I don't know lets say UTF-7 which is rendered by IE. Within this utf-7 enocded html it will contain javascript. Did you think of that? Well guess what there is somewhere between a hundred thousand and a a few million other vectors I didn't think of.
The XSS cheat sheet is so old my grandparents are immune to it. Here is a more up to date version.
(Oah and by the way you will be hacked because what you are trying to do fundamentally insecure.)
Question: What precautions should I take when I let clients add custom JS scripts to their pages?
IF you want more details:
I am working on a custom CMS like project for a company, The CMS has number of "groups" that each subscriber "owns" where they do their own thing.
The new requirements is that some groups want to add google analytics to see how they are doing. So I naturally added a column in the table and made code adjustements so if there is some data in that column, I just use the following line in master page to set the script out:
ScriptManager.RegisterClientScriptBlock(Page, typeof(Page), "CustomJs", CustomJs, true);
It works just fine, only, It got me thinking...
It's really easy for someone with good knowledge of how to access cookies etc from from js. Sure, each group is moderated and only super admin can add this javascript, sure, they wouldn't be silly enough to hack their own group. Each group has their own code so its not possible to hack other groups BUT STILL
I am not really comfortable in letting user's add their own javascript codes.
I could monitor each group myself, but the groups are growing really quick and I will hit a time when I will no longer be able to do that.
So, to brief it up: What precautions should I take to avoid any mishaps ?
ps: did try to google, no convincing answers anywhere.
Instead of allowing the users to add their own Javascript files, and given that the only requirement here is for google analytics, why not just let them put their analytics ID into the CMS and if it's present, output the relevant Google Analytics code?
This way you fulfill the users requirement and also avoid the need to protect against malicious scripting.
Letting users use Javascript is in general, a very bad idea. Don't do it unless you have to.
I once I had a problem where I need to let clients use Javascript, but, the clients weren't necessarily trusted, so, I modified cofeescript so that only a small subset was compilable to javascript, and it worked pretty well. This may be waaaay too overkill for you.
You should not let your users access cookies, that's always a pain. Also, no localStorage or webSQL if you're one of the HTML5 people, and, no document.write() because that's another form of eval as JSLint tells you.
And, the problem with letting people have javascript is that even if you believe you have trusted users, someone may get a password, and you don't want that person to get access to all the other accounts in the group.
Automatically recognizing whether some JavaScript code is malicious or sandboxing it is close to impossible. If you don't want to allow hacking your site you are left with only few options:
Don't allow users to add JavaScript at all.
Only allow predefined JavaScript code, e.g. for Google Analytics.
Have all custom JavaScript inspected by a human before it is allowed to display on the site. Never trust scripts loaded from third party sites - these can change from one day to another and turn malicious.
If you have no other choice, you may consider separating path/domain of user javascripts (and cookies).
For example your user have page:
user1.server.com
and you keep user pages at
user1.server.com
So, if you set session cookies to the user1.server.com, it'll render them unobtainable for user scripts from other domains (e.g. user2.server.com).
Another option may be executing all user's javascript at server JS engine (thus controlling all it's I/O and limiting access to browser resources).
There is no simple and easy solution anyway, so better consider using options from other answers (e.g. predifined script API, human inspection).
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.
I have to develop a widget that will be used by a third party site. This is not an application to be deployed in a social networking site. I can give the site guys a link to be used as the src of an iframe or I can develop it as a JavaScript request.
Can someone please tell me the trade offs between the 2 approaches(IFrame versus JS)?
I was searching about the same question and I found this interesting article:
http://prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/
Widgets are small web applications that can easily be added to any web
page. They are sometimes called Gadgets and are vastly used in growing
number of web pages, blogs, social sites, personalized home pages such
as iGoogle, my Yahoo, netvibes etc. In this blog I use several
widgets, such as the RSS counter to the right which displays how many
users are subscribed to this blog (don’t worry, it’ll grow, that’s a
new blog ;-) ). Widgets are great in the sense that they are small
reusable piece of functionality that even non-programmers can utilize
to enrich their site.
I’ve written several such widgets over the time both “raw” widgets
that can get embedded in any site as well as iGoogle gadgets which are
more structured, worpress*, typepad and blogger widgets, so I’m happy
to share my experience.
As a widget author, for widgets that run on the client side (simple
embeddable HTML code) you have the choice of writing your widget
inside an iframe or simply inline the page and make it part of the dom
of the hosting page. The rest of the post discusses the pros and cons
of both methods.
How is it technically done? How to use an iframe or how to implement
an inline widget?
Iframes are somewhat easier to implement. The following example
renders a simple iframe widget: http://my-great-widget.com/widgwt' width="100" height="100"
frameborder='0'>
frameborder=’0′ is used to make sure the ifrmae doesn’t have a border
so it looks more natural on the page. The
http://my-great-widget.com/widget is responsible of serving the widget
content as a complete HTML page.
Inline gadgets might look like this:
function createMyWidgetHtml() { return "Hello world of widgets"; }
document.getElementById('myWidget').innerHTML = createMyWidgetHtml();
As you can see, the function createMyWidgetHtml() it responsible for
creating the actual widget content and does not necessarily have to
talk to a server to do that. In the iframe example there must be a
server. In the inline example there does not need to be a server,
although if needed, it’s possible to get data from the server, which
actually is a very common case, widgets typically do call server side
code. Using the inline method server side code is invoked by means of
on-demmand javascript.
So, to summarize, in the iframe case we simply place an iframe HTML
code and point the source of the iframe to a sever location which
actually serves the content of the widget. In the inline case we
create the content locally using javascript. You may of course combine
usage of iframe with javascript as well as use of the inline method
with server side calls, you’re not restricted by that, but the paths
start differentially.
So what is the big deal? What’s the difference? There are several
important differences, so here starts the interesting part of the
post.
Security. iFrame widgets are more secure.
What risks do gadgets impose and who’s actually being put at risk? The
user of the site and the site’s reputation are at risk.
With inline gadgets the browser thinks that the source of the gadget
code code comes from the hosting site. Let’s assume you’re browsing
your favorite mail application http://my-wonderful-email.com and this
mail application has installed a widget that displays a clock from
http://great-clock-widgets.com/. If that widgets is implemented as an
inline widget the browser thinks that the widget’s code originated at
my-wonderful-email.com and not at great-clock-widgets.com and so it’ll
let the widget’s code ultimately get access to the cookies owned by
my-wonderful-email.com and the widget’s evil author will steal your
email. It’s important to realize that browsers don’t care about where
the javascript file is hosted; as long as the code runs on the same
frame, the browser regards all code as originationg at the frame’s
domain. So, you as a user get hurt by losing control over your email
account and my-wonderful-email gets hurt by losing its reputation.
If the same clock would have gotten implemented inside an iframe and
the iframe source is different from the page source (which is the
common case, e.g. the page source is my-wonderful-email.com and the
gadget source is great-clock-widgets.com) then the browser would not
allow the clock widgets access to the page cookies, nor will it allow
access to any other part of the hosting document, including the host
page dom. That’s way more secure. As a matter of fact, personal home
pages such as iGoogle don’t even allow inline gadgets, only iframe
gadgets are allowed. (inline gadgets are allowed only in rare cases,
only after thorough inspection by the iGoogle team to make sure
they’re not malicious)
To sum up, iframe widgets are way more secure. However, they are also
way more limited in functionality. Next we’ll discuss what you lose in
functionality.
Look and feel In the look and feel battle inline gadgets (usually**)
win. The nice thing about them is that they can be made to look as
part of the page. They can inherit CSS styles from the page, including
fonts, colors, text size etc. Iframes, OTHO must define their CSS from
the grounds up so it’s pretty hard for them to blend nicely in the
page.
But what’s even more important is that iframes must declare what their
size is going to be. When adding an iframe to a page you must include
a width and a height property and if you don’t, the browser will use
some default settings. Now, if your widget is a clock widget that’s
easy enough b/c you know exacly what size you want it to be, but in
many cases you don’t know ahead of time how much space your widget is
going to take. If, for example you’re authoring a widget that displays
a list of some sort and you don’t know how long this list is going to
be or how wide each item is going to be. Usually in HTML this is not a
big deal because HTML is a declarative based language so all you need
to do is tell the browser what you want to display and the browser
will figure out a reasonable layout for it, however with iframe this
is not the case; with ifrmaes browsers demand that you tell it exactly
what the iframe size is and it will not figure it out by itself. This
is a real problem for widget authors that want to use iframes – if you
require too much space the page will have voids in it and if you
specify too little the page will have scrollbars in it, god forbids.
Look and feel wise, inline wins. But note that this really depends on
your widget application. If all you want to do is a clock, you may get
along with an iframe just as well.
Server side vs. Client side IFrmaes require you specify a src URL so
when implementing a widget using an iframe you must have server side
code. This could both be a limitation and a headache to some (owning a
server, domain name etc, dealing with load, paying network bills etc)
but to others this is actually a point in favor of iframes b/c it
let’s you completely write your widgets in server side technologies,
so you can write a lot of the code and actually almost all of it using
your favorite server side technology whether it be asp.net, django,
ror, jsp, struts , perl or other dinosaurs. When implementing an
inline gadget you’ll find yourself more and more practicing your
javascript Ninja.
What’s the decision algorithm then? Widget authors: If the widget can
be implemented as an iframe, prefer an Iframe simply for preserving
users security and trust. If a widget requires inlining (and the
medium allows that, e.g. not iGoogle and friends) use inline but dare
not exploit users trust!
Widget installers: When installing a widget in your blog you don’t see
a “safe for users” ribbon on the widgets. How can you tell if the
widget is safe or not? There are two alternatives I can suggest: 1)
trust the vendor 2) read the code. Either you trust the widget
provider and install it anyway or you take the time to read its code
and determine yourself whether it’s trustworthy or not. Reality is
that most site owners don’t bother reading code or are not even aware
of the risk they’re putting their users at, and so widget providers
are blindly trusted. In many cases this is not an issue since blogs
don’t usually hold personal information about their readers. I suspect
things will start changing once there are few high profile exploits
(and I hope it’ll never get to it).
Users: Usres are kept in the dark. Just as there are no “safe for
users” ribbons on widgets site owners install, there are no “safe to
use” sites and basically users are kept in the dark and have no idea,
even if they have the technical skills, whether or not the site they
are using contains widgets, whether the widgets are inline or not and
whether they are malicious. Although in theory a trained developer can
inspect the code up-front, before running it in her browser and losing
her email account to a hacker, however this is not practical and there
should be no expectation that users en mass will do that. IMO this is
an unfortunate condition and I only hope attackers will not find a way
of taking advantage of that and doom the wonderful open widget culture
on the web.
Happy widgeting folks!
Some blog platforms have a somewhat different structures for widgets and they may sometimes have both widgets and plugins that may
correlate in their functionality, but for the matter of the discussion
here I’ll lously use the term widget to discuss the “raw” type which
consists of client side javascript code
** Although in most cases you’d want widgets to inherit styles from the hosting page to make them look consistent with it, sometimes you
actually don’t want the widget to inherit styles from the page, so in
this case iFrames let you start your CSS from scratch.
Why not doing both ?
I prefer to offer third party sites a script like:
<script type="text/javascript" src="urlToYourScript"></script>
the file on your server looks like :
document.writeln('<iframe src="pathToYourWidget"
name="MagicIframe" width="300" height="600" align="left" scrolling="no"
marginheight="0" marginwidth="0" frameborder="0"></iframe>');
UPDATE:
one disadvantage of using an iframe that points to an url on your server is that you do not generate a "real" backlink if someone clicks on an url from your server pointing to your server.
I'm sure many developers/site owners would appreciate a Javascript solution that they can style to their needs rather than using an iframe. If I was going to include a component from a third party, I would rather do it via Javascript because I would have more control.
As far as ease of use, both are similar in simplicity, so no real tradeoff there.
One other thought, make sure you get a SSL cert for whatever domain you're hosting this on and write out the include statement accordingly if the page is served over SSL. In case your site owners have a reason for using SSL, they would surely appreciate this, because Firefox and other browsers will complain when a page is served with a mix of secure/insecure content.
If the widget can be embedded in an iframe, it will be better for the frontend performance of the hosting site as iframes do not block content download. However, as others have commented there are other drawbacks to using iframes.
If you do implement in javascript, please consider frontend performance best practices when developing. In particular, you should look at Non blocking javascript loading. Google analytics and other 3rd party widget providers support this method of loading. It would also help if you can load the javascript at the bottom of the page.
Nice to know that it's not to be deployed in a social networking site... that merely leaves the rest of the web ;-)
What would be most useful depends on your widget. IFrames and javascript generally serve quite different purposes, and can be mixed (i.e. javascript inside an iframe, or javascript creating an iframe).
IFrames got sizing issues; if it's supposed to be an exact fit to the page, do you know that it renders the same on all browsers, the data won't overflow it's container etc?
IFrames are simple. They can be a simple, static HTML-page.
When using IFrames, you expose your widget quite plainly.
But then again, why not have your third party site simply include the HMTL at a given url? The HTML can then be extended to contain javascript when/if you need it.
Pure Javascript allows for more flexibility but at the cost of some complexity.
The big plus of iframes: all CSS and JS is separated from the host page, so your existing CSS just works. (If you want the host site to style your content to fit in, that's a minus of course.)
The big minus of iframes: they have a fixed width and height and scroll-bars will appear if your content is larger.