Solution to allow JavaScript input but prevent XSS
https is all about encryption and ensuring server identity to prevent other people from listening to the traffic. So it does not help at all against malicious JavaScript code within the bounds of the same origin policy.
There is a flag on cookies called httpOnly which prevents simple JavaScript code on modern browser to access the cookie. But this does not fix the issue, it just makes exploits a bit less simple: The JavaScript code can directly trigger form submissions with the permissions of the current user. Since the JavaScript is on the same domain, it has access to CSRF tokens. The browser will include the cookie on the form submission without the JavaScript code needing to access it. (And there is a number of bugs around HttpOnly, for example some browser allow to read the cookie from an XMLHttpRequest object.)
Furthermore the JavaScript author may replace the current page content with "Your session has timed out, please login again" and its own login form. But the form he adds does not point to the login URL of your server but to a server he controls. Or even more subtle, there may be a cross-domain Ajax call in the event handler of the submit-button.
There is a rather simple solution in two steps:
- Filter all non trusted markup, including all JavaScript. If you are using PHP, you can use HTML-Purifier. There are similar libraries for all common languages.
- Provide harmless placeholders ("widgets"). So instead of letting your users embed JavaScript code directly, they must write something like
<div id="googleadd">identifier</div>. A piece of trusted global JavaScript code can replace those code fragments with the real add code. Make sure to properly escape input parameters. This will limit your users a little in what they can do, but it is pretty easy to cover all common use cases.
It does make sense to google a bit as there are already a number of Widget libraries out there; although most of them still require JavaScript calls.
HTTPS doesn't prevent stealing cookies, HTTPOnly flag does. I would recommend (if it's possible) to have a library of "widgets" users can include in the page and configure. Then you can just insert the JavaScript code with configured parameters without allowing user to write JavaScript code.
If you enable your users to insert their own JavaScript code, they can do things like updating the login form of your blog system to send credentials to another server, so that if some user visits the malicious blog page and decides to log in to your system on that page, his credentials could be compromised.
No, HTTPS doesn't stop this threat.
If your users must be allowed to include Javascript they have written into the page, this is a very challenging problem. What you want is some kind of Javascript sandbox. @Mike Samuel's recommendation of Caja is a good choice of Javascript sandboxing technology. Other possibilities in this space include Microsoft's Web Sandbox, Yahoo's AdSafe, Facebook's FBJS, and probably others I have missed.
Please understand that while solutions do exist, they won't be entirely trivial to deploy. You've stumbled upon a hard problem in web security; the web just wasn't designed to support this kind of thing, and as a result, the solutions necessarily end up being a pretty complex piece of technology. So you will probably need support from a capable developer to deploy and integrate one of these solutions into your web site.