0

I'm planning a tool that will allow users to publish collections of their writing for publish consumption.

Any modification of content or account settings will be done through a secure management / admin server foo.com.

When users choose to publish a collection, they will be allowed to choose a subdomain from a different TLD, reserved specifically for published content: <subdomain>.foo.pub.

I'd like to offer users the ability to inject custom javascript into the published HTML. This way they could modify their theme, or include 3rd party comments, for example.

Since the published collections are on their own subdomain of a TLD that's completely separate from the management server, I think that users would be protected from XSS attacks.

What other risks, if any, would I be exposing readers to by allowing custom JS execution?

  • 1
    Not enough for a full answer, but: just having a subdomain will not be enough to protect against tampering with cookies. See for example Cookies Lack Integrity: Real-World Implications. – Steffen Ullrich Jun 19 '17 at 17:27
  • Other than elevated cookies and securing your provided API from robots, you should be fine, given that your users log-in and thus you won't be running a huge zombie farm. it's scary, but the web rules should be safe. I would use frame-blocking headers and a weak CSP just to be sure. – dandavis Jun 19 '17 at 18:11
2

Being able to execute custom code in someone else's environment is the very endgoal of most web exploits. Your design consideration bypasses any pretense of security and facilitates this by default.

The service you'd actually be offering is a platform for anybody to publish malware, adware and drive-by downloads, or to use your service as a node in a botnet.

There are better ways to do what you want to do than allowing execution of arbitrary code.

  • Theming can be handled through some degree of custom css (look at the subreddit css system).
  • Comments and hitting third-party APIs can be facilitated through the use of approved widgets or plugins that you write and author based on popular demand.

It's just a bad idea, and there's a reason only a limited few sites (jsfiddle, etc) allow execution of arbitrary code-- they're sandboxed to hell and back again, and implement modified interpreters that don't allow execution of potentially malicious commands (eval(), etc).

  • those ill effects can be easily mitigated; JS doesn't have to be all or nothing, and OP's users are logged in... – dandavis Jun 19 '17 at 18:19
  • 2
    @dandavis If it was so easily mitigated, more sites would allow it. Code injection is #1 on the OWASP top 10 for a reason. – Ivan Jun 19 '17 at 18:31
  • agreed, but there's no reason for most sites to allow it. The trouble happens when sites don't know they are re-hosting arbitrary JS (and they have secrets), not when they carefully plan on safely supporting it... – dandavis Jun 19 '17 at 19:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.