Hacker News Reader

Comment by jve | Hacker News Reader

I wonder what _showHtmlPage_ does? Did he just write something, something that allows 3rd party (corporate firewalls) inject HTML under his domain within TLS protected connection?

Cannot judge by not knowing how he displays errors. But a question to HN public: Is opening unknown HTML under my domain within another window safe? Or is there any possibility to strip down any "permissions" to cookies, requests, resources etc for that dedicated page?

View on HN

Came here to point this out. For non-trivial implementations of showHtmlPage, this is a vulnerability. A malicious user could set up a 403 response with a fake “please re-enter your card to verify” form that sends to the attacker, or possibly even script to scrape the card number. Probably low risk of this actually happening in this scenario, but I’m pretty sure this fix is a bad idea. Better to show a generic error and log.

I think loading HTML within DOM Node and getting .innerText would be pretty innocent way of communicating user about some unknown error condition. Or logging that text so developer can better understand unexpected failures.

I get where you’re coming from, but keep in mind that the filtering proxy returning 403 instead of relaying the POST is already able to inject arbitrary HTML into all of his TLS protected pages. If the proxy wants to scrape card information, it already can; if it’s malicious, the user is toast no matter what the website operator does.

I dunno. The frontend just made a TLS connection to his server and downloaded an HTML page. I don't think displaying that page adds any extra vulnerability.

If he put it in a sandboxed iframe, it will have the same kinds of access as the main page, because it comes from the same domain. Everything is already as messed up as it can be, and there isn't anything the frontend can do to improve it.

That seems pretty unsafe without running it through some sanitizer. Trying not to judge too hard, but I would be concerned about the implementation of showHtmlPage by the same author that didn't handle non-json responses.

Hey, OP here - I'm open to advice about how best to handle this! I'm currently just opening a new window and writing the HTML to it.

What's the safest way to handle this? Open it in an iframe?

OP here - I'm open to advice about how best to handle this! I'm currently just opening a new window and writing the HTML to it.

What's the safest way to handle this? Open it in an iframe?

Just look under this thread, I wrote one possible solution of using .innerText from constructed DOM. (Or maybe open window in another domain). However @repiret may be right - corporate proxy is already invasive enough, that means the users are already in mercy of those.

But still, I'd go with safer practices. Even in the slightly unlikely case someone manages to hack 3rd party (Stripe) and send your users arbitrary HTML for some periods of time... :)

Thanks, appreciate the advice!

Reply on news.ycombinator.com