6 ms·
I wonder what _showHtmlPage_ does? Did he just write something, something that allows 3rd party (corporate firewalls) inject HTML under his domain within TLS pr
by jve 4y ago
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?
- shireboy 4y agoCame 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.
- jve 4y agoI 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.
- marcosdumay 4y agoI 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.
- pigbearpig 4y agoThat 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.
- ValCanBuild 4y agoHey, 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?
- repiret 4y agoI 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.
- ValCanBuild 4y agoOP 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?
- jve 4y agoJust 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... :)
- ValCanBuild 4y agoThanks, appreciate the advice!