0

I have a web app where I allow users to create a one-page portfolio using drag and drop, also I allow them to add custom HTML freely (basically any html or js code)

I'm aware that I shouldn't allow the custom HTML to be executed while they are in the EDIT mode, so I save it in the database but never render it into the editor page.

However, I need that custom HTML/JS to be rendered in their built portfolio page, to prevent security issues here is what I did:

  1. In addition to the private IP related to my app, I added another private IP
  2. I purchased another domain, let say for example my app domain is portfolio-app.com, I purchased another domain portfolio-show.com and pointed that domain to my app (using the second private IP), means: I have 2 domains pointing the same app but each domain has its own private IP.
  3. In my app I have a route in place that detects if the request is coming from portfolio-show.com host, if so, then it lookups the path and show the specific user portfolio,

The routing logic basically goes like this:

if request.host == 'portfolio-show.com'
   get ':any-id', to: 'portfolioController#showAction'
end

The showAction is rendered only on portfolio-show.com but never under portfolio-app.com,

so if you are a user 1 your portfolio will be visited under portfolio-show.com/user-1-portfolio

My concern is: is showing the custom HTML/JS under a different domain enough to protect my app? am I safe if some user put malicious code on their portfolio page?

medBouzid
  • 129
  • 3

2 Answers2

1

Based on this description you have a "secure" and "insecure" domain. Both domains have the same possibilities, use the same layout etc. The only difference is that the insecure domain also allows insecure things in addition to all the other things.

In this case an attacker could likely motivate the user to actually use the insecure domain instead of the secure one. It looks the same and behaves the same so it seems to work. Only now attacks like XSS can be mounted successfully since insecure things are allowed on this domain.

To prevent this you not only need to allow insecure things only on the insecure domain but also prevent any confusion between these domains, best by not allowing sensitive things on the insecure domain at all (i.e. no login, no user sessions etc - or at least no shared user base).

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • thank you a lot for the answer, the "insecure" domain is dedicated to showing the user portfolio, and that's all it does, nothing else, all logins and user sessions are done in the "secure" domain, that's where the user logs in and create his/her portfolio, my thinking was that because both domains are just pointers to the same app, maybe some user can affect my app by putting something malicious in his portfolio, do you think am safe in this case? – medBouzid Nov 26 '20 at 17:39
1

My concern is: is showing the custom HTML/JS under a different domain enough to protect my app? am I safe if some user put malicious code on their portfolio page?

It depends what you mean by "protect my app". If you mean prevent users from using your platform to host malware, then no, changing the domain name does nothing to prevent that. If you mean that you will not be held criminally responsible for malware that's hosted on your platform, well, that's a question for a lawyer. If you mean that your primary app, on your primary domain, will not host malware then you're probably ok; though you should see @Steffen's answer about reducing confusion between the two domains.


I will say that the pattern you are trying is a well-known pattern; for example githubusercontent.com and googleusercontent.com serve files that github / google want to make sure didn't come from them.

For example, when you click the "Raw" button on github

GitHub "Raw" button

you get taken to that file on raw.githubusercontent.com. Presumably this is so that A) there is no ambiguity about GitHub (the company) being responsible for this file, and B) so that if this file contains malware, it can't access any of the cookies / login info for github.com. Again, as @Steffen says, you want to make sure that your usercontent domain has no login mechanism, no content of yours, etc, nothing that can be attacked except what users have uploaded.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207