> If a server sends my browser text, however, and my idiot browser executes it as code, that's also a server flaw.
XSS is not the server sending your browser text, that your idiot browser executes as code. XSS is the idiot server sending the browser code that the server thinks is text. The browser's job is to execute code the server sends it: the browser trusts the server, and it's the server's job to ensure what it's sending as code is code and what it's sending as text is text.
> If a server sends my browser text, however, and my idiot browser executes it as code
That's entirely normal.
There's no hard distinction between "text" and "code", and there always end up being leaks in the systems designed to keep them apart.
In the case of XSS, the difference is between "text" of the webpage that you're supposed to execute and "text" that was inserted into the web page from somewhere else.
> The Genericons icon font package, which is used in a number of popular themes and plugins, contained an HTML file vulnerable to a cross-site scripting attack.
> Whenever anything is sent to the server from the browser, we need proper validation. Input should be properly sanitized before being sent to the server.
That doesn't sound right. If the attack vector is reflected XSS, i.e. that code (HTML/JS/etc.) is taken from the attacker's input, stored in the database by the server and later injected straight into another user's page, sanitizing it "before being sent to the server" would mean relying on the attacker helpfully sanitizing their own data.
> Something like a Markdown converter seems less likely, though not impossible.
Really? I've found serious XSS bugs in frameworks that are semi-popular for writing real-time applications with a web component. What's outputted from your Markdown converter is generally assumed to be trusted HTML. Additionally, if it's not written in a language with good string support... it has string processing, which could lead to a crash or buffer overflow easily. It seems that a Markdown converter is exactly the sort of place you'd be likely to find an attack vector.
> Lastly, “DOM-based XSS” attacks occur purely in the browser when client-side JavaScript echoes back a portion of the URL onto the page.
This Google Doc has tracked almost all "sinks" and "sources" for DOM-based XSS[1]. They aren't by any means limited to the URL (usually accessed by the `document.location` object).
XSS?
what's the vector attack here?
where the `text` comes from?
reply