Hacker News new | ask | show | jobs
by hopscotch 2604 days ago
Have you had a proper security review? I don't think you would have made that mistake with user-websites being able to log out the user if you had designed with security as an important objective.

Like, it's OK that you didn't, but maybe you should check that your entire public API (all microservices, UI, etc) will really be secure.

You will probably struggle to get a secure interface while user content is served from the same domain as your UI.

2 comments

For reference @hopscotch appears to be referring to this post: https://forum.1mb.site/?t=1556326142930

I think the interaction in this forum thread says a lot about my focus on security. An issue was reported and I jumped on it immediately. I’m not going to sit here and claim to be perfect, but I am going to tell you that I work really hard to make sure I do stuff right and fix my mistakes ASAP. I have had white hat hackers review my API by the way and have patched reported security vulnerabilities.

Kudos for quickly adding an anti-csrf token to logout, but I agree with the grandparent that hosting arbitrary user content on the same TLD as the management interface is still problematic security-wise.

See github.com vs github.io[1], amazon.com vs. elasticbeanstalk.com, azure.com vs azurewebsites.net, etc... Every major company I know of that hosts arbitrary user content dedicates a TLD to it that's not shared by the management APIs.

[1] https://github.blog/2013-04-05-new-github-pages-domain-githu...

You likely want a separate domain indeed. See https://security.googleblog.com/2012/08/content-hosting-for-...
Sites like Tumblr do it and are fine, and they allow custom HTML and JS also. Cookies are HTTP only and inaccessible with JavaScript. And framing is blocked.
>I don't think you would have made that mistake with user-websites being able to log out the user if you had designed with security as an important objective.

Really? In my experience not many people care about logout CSRF, it's the lowest of low risk vulns that infosec consultants write in a report when they don't have any real vulnerabilities. I'm not sure its presence really says much about the site overall.

Effort is much better spent elsewhere - strict Content-Security-Policy, for example. Or, if there are 'real' CSRF vulns that actually do damage