4 ms·

The article states a couple times in the opening paragraphs that the API is about sanitizing dynamically generated HTML, "Many websites rely on dynamically gene

by mftb 5y ago

The article states a couple times in the opening paragraphs that the API is about sanitizing dynamically generated HTML, "Many websites rely on dynamically generated content in the browser. Often, the generated markup includes content provided by outside sources, such as user-provided input, which can include malicious JavaScript code.". So the server would never see this HTML.

codedokode 5y ago
This is absolutely unclear. If the user enters HTML and that HTML never gets to the server then why sanitize it? To protect user from hacking themselves?
- oh_sigh 5y ago
  Sure, why not? Most users expect that if they paste something into a textbox on a site, that their browser won't send their cookies and browsing history to some random 3rd party
- alanfranz 5y ago
  Google for "reflected XSS". Sometimes a parameter in the URL can be rendered in the user's browser.
- playpause 5y ago
  Users may 'hack themselves' when an attacker persuades them to paste something into a website, for example. These are very basic XSS questions by the way, you don't seem to know enough about the subject to be this incredulous.
- dzaima 5y ago
  In addition to the other replies, there could be server-provided HTML that the user has the option to change, and initiating a change, activating the vulnerability, could be one click. (this happened to Google's own search bar!) Then there are cases of different browsers parsing things differently and/or bad sanitization/serializing giving different results on repeated invocation or just being broken on the server-side. A simple client-side option is gonna be a lot simpler.
tdeck 5y ago
After reading some of these comments I still wonder what the concrete use cases are. What are these websites that allow users to paste in HTML, and why? Is that even a good idea? I can understand when it's developer tools like jsFiddle and the like, but when should a normal consumer website be hosting untrusted code in the frontend?

by mftb 5y ago

codedokode 5y ago

This is absolutely unclear. If the user enters HTML and that HTML never gets to the server then why sanitize it? To protect user from hacking themselves?

oh_sigh 5y ago
Sure, why not? Most users expect that if they paste something into a textbox on a site, that their browser won't send their cookies and browsing history to some random 3rd party
alanfranz 5y ago
Google for "reflected XSS". Sometimes a parameter in the URL can be rendered in the user's browser.
playpause 5y ago
Users may 'hack themselves' when an attacker persuades them to paste something into a website, for example. These are very basic XSS questions by the way, you don't seem to know enough about the subject to be this incredulous.
dzaima 5y ago
In addition to the other replies, there could be server-provided HTML that the user has the option to change, and initiating a change, activating the vulnerability, could be one click. (this happened to Google's own search bar!) Then there are cases of different browsers parsing things differently and/or bad sanitization/serializing giving different results on repeated invocation or just being broken on the server-side. A simple client-side option is gonna be a lot simpler.

tdeck 5y ago

After reading some of these comments I still wonder what the concrete use cases are. What are these websites that allow users to paste in HTML, and why? Is that even a good idea? I can understand when it's developer tools like jsFiddle and the like, but when should a normal consumer website be hosting untrusted code in the frontend?