0

Consider a site for frontend devs/designers to host their portfolio apps - pages with arbitrary JS, each hosted on a user's separate profile.

What attack vectors would that enable against the site? Some suggestions and comments:

  1. Defacing the site (user's own profile, not interesting)
  2. Phishing (by rewriting the UI to ask for credentials while using the safe domain)
  3. Credential theft of user logged-in users, by pulling auth cookies (irrelevant if auth cookies are HTTP-only?)
  4. Request forgery (by triggering a POST request from within the approved domain)
2

What you're describing is just XSS.

Alice and Bob both use example.com. Untrusted script is added by Alice into her profile page, and executed by Bob's browser upon visiting Alice's profile.

It doesn't matter whether example.com intendes to allow Alice to inject arbitrary script into Bob's page view, or if Alice discovers an XSS that allows her to do so, the result is identical, it's a simple stored XSS.

Don't do this, unless each site runs on its own origin (ie alice.example.com and bob.example.com) and Same Origin Policy prevents profiles from attacking each other.

Lots of sites do do this, for example Shopify, but every shop runs on a user-specified domain or subdomain.

Enumerating every type of thing an XSS can do is probably outside the scope of this site. Yes, the obvious things like request forgeries apply, but there is an ever-growing list of features that browsers support. If Alice tries to attack these features, they often require permission, but example.com may have already prompted Bob for permission for legitimate reasons, giving Alice free rein.

  • Is there a big blob of sensitive data stored in localstorage that Alice can steal from Bob via her profile JS?
  • Has Bob authorized example.com to use his webcam to take a profile photo? Maybe Alice can activate the webcam and surreptitiously record Bob.
  • Has Bob allowed example.com to use notifications? Alice can spam Bob with bogus notifications
  • Has Bob allowed the example.com to read his device's GPS? Alice knows where Bob lives.

The list is as long as the list of available browser features that example.com my have tried to make legitimate use out of.

| improve this answer | |
0

The most severe risk appears to be #4; the ability to forge requests.

XSS is typically able to bypass CSRF protections since the code is executing on the same site as the target. This could allow an attacker to perform sensitive actions on behalf of a visitor's account (changing email/password, defacing their page, distributing the malicious code further by embedding it in the victim's portfolio, etc.). You're basically giving any user the ability to perform actions on other user's accounts and user experiences while appearing to be coming from the trusted site.

| improve this answer | |

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.