This extension is trivially vulnerable to XSS - anyone can write javascript in their HN bio and it will execute in your logged-in context if you mouse over their profile. Here's the relevant code:
But first disclaimer - I’m not saying this is why the extension was developed, or, that this is the reason OP points the vulnerability. I’m 99.999% certain this is a random case, but it is a good learning case nonetheless.
Rabbits.
Sometime in life people say things they regret. Or, they don’t regret, but their self interest is better served if no one knew they said said thing, or it is that they just worry Harvey might be offended and their career path will be ruined, so it better be taken back.
But... yak... what’s done is done.
What can you do?
Cry?
No. Rabbits!
Wouldn’t it be nice if some browser extension published on HN would have some fault that would allow someone else to post using my logged-in account?
It depends on the origin of the iframe - if the iframe origin is the tuple (https, news.ycombinator.com, 443) then even if it's in an iframe it still has access to everything. If you put the content into its own origin (say, with <iframe src="data:text/html;base64,..."></iframe>), then it would no longer† have access to your data, but someone who put javascript on their bio could still pop up an alert with arbitrary content in your browser, for instance.
† Well, it's also debatable whether or not an iframe with a unique origin would be sufficient protection in the age of Spectre/Meltdown style vulnerabilities, where code execution in a process means you have access to the entire memory contents of that process. Chrome has strong protections against this in the form of Site Isolation [1], but Firefox does not (though they are actively working on it with Project Fission [2]), and Safari/etc do not to my knowledge. We don't _really_ need to be worried about Spectre/Meltdown vulnerabilities being used against a Hackernews profile viewer extension, but at the same time it's easy enough to write safe code that doesn't allow javascript execution in the first place, so why not do that instead?
The right way would be to either use a templating language that takes care of it for you (react/angular/vue/etc), or to write some plain javascript instead of injecting DOM with jQuery.html(). Something like:
const div = document.createElement('div');
div.textContent = 'This is the bio. <script>alert("This will not execute");</script>';
Let’s pull some rabbits out of thin air again.
But first disclaimer - I’m not saying this is why the extension was developed, or, that this is the reason OP points the vulnerability. I’m 99.999% certain this is a random case, but it is a good learning case nonetheless.
Rabbits.
Sometime in life people say things they regret. Or, they don’t regret, but their self interest is better served if no one knew they said said thing, or it is that they just worry Harvey might be offended and their career path will be ruined, so it better be taken back.
But... yak... what’s done is done.
What can you do?
Cry?
No. Rabbits!
Wouldn’t it be nice if some browser extension published on HN would have some fault that would allow someone else to post using my logged-in account?
So see, I didn’t post that comment.
It was the XSS!!!1
(Or the rabbit)