Hacker News Reader

Comment by An0n1m1ty | Hacker News Reader

This site is subject to severe XSS via the post mechanism. Just entering <script>alert(1)</script> works. So be careful when going to links. See https://hacker.thoughts.page for a demo

View on HN

Hey! I'm the person who made this — I don't believe there's an actual problem here, since login cookies are set on the top-level domain (and thus are inaccessible to content on subdomains), and are HTTPOnly as well.

I do notice that Stripe sets a tracking cookie (which only happens for people who pay for the service, since I don't load the Stripe JS elsewhere), so you could track pageviews with that or something. That's unfortunate — I'll probably try to move the stripe stuff to a subdomain to avoid it — but I don't see it as a big problem.

The HTTP security model is pretty awful, so there may be something I'm missing, but I did think quite carefully about this, and allowing people to use arbitrary HTML and JS was an intentional choice.

Is there a particular threat model you see here?

>allowing people to use arbitrary HTML and JS was an intentional choice

Oh, you'll be reversing this choice VERY quickly if your product gets any traction, I assure you...

I don't actually see a problem. It goes against my gut reaction but given the pages that are published are entirely isolated there is no more of a threat than someone publishing whatever they want on another web host. There is no user information to hijack, no cookies, no login buttons, no local storage, no auth etc.

Yes, the pages can publish illegal information, be set up as phishing hubs, but none of that is as a result of JS being executable. Web hosts all have exactly the same risks to deal with, their users can also host anything they wish.

The owner's challenge is with the content they are opening up to hosting, and it will become an overhead to police that. If they decide to add buttons like "report content" then those will be able to be hijacked by the publisher and become useless.

Google will flag the entire domain in Safe Browsing. Unless you are a big company with a legal team, getting off the Safe Browsing flag list is a days or weeks long nightmare.

How are they isolated if you can inject JS that downloads resources from anywhere else? I mean, just to start:

- You have no CSP header that I can see.

- You do expose the server version in the headers, though.

- The site is available at a non-SSL-secured domain.

- There's no X-Frame-Options, X-Permitted-Cross-Domain-Policies, etc.

My point is, the service simply hosts HTML, ostensibly this is the same as any consumer web host. So whatever attack vector you can think of exists on Dreamhost or Godaddy pages, for instance.

I understand, but you can't have it both ways: You can either build a minimal Twitter clone that limits user-submitted content and not worry too much about security/abuse, or you can build a web host. The latter entails a comparatively enormous amount of responsibility you don't seem keen to take on.

I have worked for companies that offered commercial web host services and it is a massive security undertaking. I'm still not 100% convinced it's possible to offer a profitable, truly secure web host without compromising on feature set.

You become a pastebin of malicious JS.

https://nsfw-attack-demo.thoughts.page/

(not actually NSFW, just there to serve a point)

Just a heads up, a sister comment already pointed out the biggest "danger", but not what that means for your webapp:

Google will penalize your domain strongly as soon as anyone used your service for malicious content. You might even get blocked entirely if you are particularly unlucky.

That's also the reason why GitHub pages is hosted under github.io instead of GitHub.com for example.

Safe Browsing is a must-consider for anyone hosting user-submitted content.

This is not called XSS.

This is just user generated html on subdomains.

Github does the same on github.io. Everybody can make a theirname.github.io page and alert whatever they like too.

So does Gitlab on yourname.gitlab.io, Wordpress on yourname.wordpress.com etc. It is a common practice.

Agreed.

That's only an issue if this is possible for comments. The current behavior is working as intended I'd say.

Tools such as Zap and Burp Suite are great for web devs who want to learn how to build secure websites. I highly recommend them:

https://owasp.org/www-project-zap/

https://portswigger.net/burp

The creators of Burp suite have some courses as well: https://portswigger.net/web-security

Plus there's no "nofollow" on links, doors opened for spammers!

What's the output for alert(document.domain)?

https://liveoverflow.com/do-not-use-alert-1-in-xss/

The output is hacker.thoughts.page

Have you reported this to the creator? Their email is in a couple of places.

Yes I have. And as they have noted in one of the comments above, they are currently looking for ways in which this could cause a threat

Oh boy. Didn't think I'd see something like this in $CURRENT_YEAR.

I didn't either until I started my current job back in April and found them in a frenzy trying to firstly figure out what XSS is and secondly trying to patch all their systems before the end of the month. Fun times.

oh boy! well done for spotting that

Thanks

Reply on news.ycombinator.com