I have implemented a requirement in my website where I can allow my end user to configure a link, to execute any javascript that he may require. Since, he can type in any javascript that he requires he also has the ability to open different web pages, create new pages via javascript, edit elements in the page via javascript and so on.
I have some security concerns over this functionality and would like to get some opinion from everyone. Is it possible that any malicious or unethical script could be added to the page that could bring about law and order problem or credibility issues? If so, is it possible to place in some code that would restrict the type of javascript that my user may add?
There's a thing called ADsafe which was developed for banner ads that is a strict subset of Javascript which is meant to prevent malicious code. I don't think you'd be able to do things like
open different web pages, create new pages via javascript, edit elements in the page via javascript and so on
though. I think you should re-think your needs, and try to determine if you can come up with a way to offer the ability for a user to choose from pre-determined code that you write, perhaps customizing it within certain bounds.
Then again, if you're absolutely sure that the javascript is only going to run for the user who entered it, there shouldn't be anything they can do that will screw it up for anyone else. If a user was determined he or she could simply inject their javascript in through other means, like a rewriting proxy or extension or simply the javascript console.
Related
I'm working on a CMS application, where users can build and manage their own websites. There is a CRUD of HTML pages, in which while creation/updation, we are sanitizing user's input and removing any JavaScript code.
Some user's need to add widgets on their pages, which can be from any source. How can I allow them to do so without compromising the security of their page ? Basically, I want to allow <script> tag from trusted sources and which might have some JavaScript content within them.
If you don't want JS on these pages, then you probably should not open Pandora's box by allowing some 'under certain circumstances'.
A 'trusted' source is hard enough to define and potentially even harder to control. Also, the original source may include 3rd party scripts and it would be near impossible to test and monitor every single one of them.
At the very least, I would recommend to embed widgets in iframes so that they can't interfere with the main page.
As a side note: you're probably already aware of that, but removing all JS code is not an easy task either as it may be included in many different places, be obfuscated, etc.
Just as a quick (and safe) example:
<img src="foo" onerror="console.log(atob('SSBoYXMgaGFja2VkIHRoZSBJbnRlcm5ldHMhIQ=='))">
That said, I doubt that a user would intentionally corrupt his own page. Which raises another question: do you really need to block JS in the first place?
You may have specific reasons that are not obvious in your post, though.
All of this is based on my own understanding of your problem, so don't hesitate to provide us with more details if I missed the plot.
Ok so im learning javascript and I just wanted to know if its possible to make it do actions on external pages. For example if I wanted to say 'onload redirect to somesite.com/page1 then once on somesite.com/page1 fill in register form with these details'
is that possible?
You cannot do this.
This would represent, for lack of a better word, an enormous security hole.
The only way to make an external page "do stuff" is to write code that is on or explicitly included in that page itself. Period.
I have however, seen external pages get loaded INTO the current page as strings, and then have the javascript that loaded those pages modify that markup directly. But that is ugly.
On the first page you could modify some variables/values in a database. Then, in the second page you could check the values in your database, and do different "stuff" depending on those values.
You would need to set up a database and use some server-side scripting along with Javascript (server-side scripting is used to interact with your server/database). In your first page, the server-side script, like PHP, would fetch info from your Javascript. In your second page, your Javascript would fetch info from your server side script and then do stuff to that page.
This is a much safer way. If you are taking user input from things like HTML fields, you need to look into cleaning the input to prevent something called "cross-site scripting (XSS)".
You could do this IF you were rendering the other page in a frame of some sort.
There are multiple ways in which you can render an entire external page as a piece of your page. Many pages take precautions to block being rendered in a frame for just this very reason though (Not to mention copyright issues).
Once you're rendering the external page inside your page you should be able to reference components nested in your frame and do the sort of thing that you're describing.
There's no way to do this with JavaScript. The developers of all the major browsers work very, very hard to prevent this sort of thing. If this were possible, it would open up pretty massive security holes.
If you really want to use something like this for testing, you can look at browser automation software like Selenium. This allows you to automate various testing scenarios in your browser, but it does not affect other clients using your site.
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 am trying to work out if I can alter the functionality of a website preferably through vba (access) or any other way that I can centrally manage. What I am trying to achieve is, depending on permissions, I would like users to log onto a website and the website is then changed on the fly to stop the user using normal functions of the website. For example some users have access to a submit button while others do not.
I have seen that you can use VBA to parse websites and auto logon. I'm just not sure if its capable of doing any local scripting like greasemonkey does.
Maybe I am looking at this wrong and can achieve this at the firewall level instead of running website scripts.
Any ideas?
You should not manage website permissions using a client-side technology like JavaScript. Users can easily either just disable JavaScript/VBScript or tamper with the page.
The best approach is to manage permissions by emitting the HTML from a server-side scripting language such as ASP.Net or PHP.
ASP.Net has built-in, generally adequate support for membership, roles and permissions that would meet this need.
http://msdn.microsoft.com/en-us/library/yh26yfzy(v=vs.100).aspx
If that is not an option for whatever reason, and you can accept the risk of someone tampering with the permissions you setup, you can certainly use something like jQuery to hide portions of an HTML document that a user should have no access to. You can accomplish the same thing using JavaScript without jQuery, but I would suggest jQuery because it abstracts away many of the cross-browser issues.
If you do that, hide everything by default and then show selectively based on permissions. That way, the simplest method of just disabling JavaScript will not reveal anything special (though it is still quite easy to hack).
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.)