8 ms·

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.

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 https://hacker.thoughts.page for a demo

icy 5y ago
Oh boy. Didn't think I'd see something like this in $CURRENT_YEAR.
- nisegami 5y ago
  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.
  - deleted 5y ago
    [deleted]
xenocratus 5y ago
Have you reported this to the creator? Their email is in a couple of places.
- An0n1m1ty 5y ago
  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
shantnutiwari 5y ago
oh boy! well done for spotting that
- An0n1m1ty 5y ago
  Thanks
napolux 5y ago
Plus there's no "nofollow" on links, doors opened for spammers!
_wldu 5y ago
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://owasp.org/www-project-zap/ https://portswigger.net/burp https://portswigger.net/burp
- xenocratus 5y ago
  The creators of Burp suite have some courses as well: https://portswigger.net/web-security https://portswigger.net/web-security
trinovantes 5y ago
What's the output for alert(document.domain)? https://liveoverflow.com/do-not-use-alert-1-in-xss/ https://liveoverflow.com/do-not-use-alert-1-in-xss/
- An0n1m1ty 5y ago
  The output is hacker.thoughts.page
TicklishTiger 5y ago
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.
- y4mi 5y ago
  Agreed. That's only an issue if this is possible for comments. The current behavior is working as intended I'd say.
wesleyac 5y ago
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?
- psychometry 5y ago
  >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...
  - monkeynotes 5y ago
    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.
    - dharmab 5y ago
      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.

icy 5y ago

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

nisegami 5y ago
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.
- deleted 5y ago
  [deleted]

xenocratus 5y ago

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

An0n1m1ty 5y ago
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

shantnutiwari 5y ago

oh boy! well done for spotting that

An0n1m1ty 5y ago
Thanks

napolux 5y ago

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

_wldu 5y ago

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://owasp.org/www-project-zap/ https://portswigger.net/burp https://portswigger.net/burp

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

trinovantes 5y ago

What's the output for alert(document.domain)? https://liveoverflow.com/do-not-use-alert-1-in-xss/ https://liveoverflow.com/do-not-use-alert-1-in-xss/

An0n1m1ty 5y ago
The output is hacker.thoughts.page

TicklishTiger 5y ago

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.

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

wesleyac 5y ago

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?

psychometry 5y ago
>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...
- monkeynotes 5y ago
  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.
  - dharmab 5y ago
    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.