Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Reflective XSS Vulnerability in Svelte Site
See original GitHub issueThe site sub-project is vulnerable to reflective XSS via the defined error handler response data including unescaped javascript error messages from middleware, which may contain unsanitized user input.
One route that enables an attacker to cause such an uncaught error is /repl/[id].json. Due to insufficient error handling a malformed id passed to the gist database query throws and propagates with a message that includes the invalid and unsanitized gist id as specified by the path. The error generated has a message of the form:
invalid input syntax for type uuid: "{id}"`
When this message is emitted as response data the browser happily understands {id} as any html, executing whatever scripts.
This issue can be observed by browsing https://svelte.dev/repl/<body onload=alert(1)>.json, which produces the resulting page, which when loaded simply prompts an alert:
invalid input syntax for type uuid: "<body onload=alert(1)>"
Issue Analytics
- State:
- Created 3 years ago
- Reactions:15
- Comments:14 (11 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@Rich-Harris I just tried again I don’t seem to be able to reproduce this anymore - it’s possible that it was fixed in the past week or so. When I throw an error from an endpoint, the error’s message is no longer returned as part of a
text/htmlresponse, whether during dev or preview or with the Node adapter. There’s now noContent-Typeheader at all, and so it’s interpreted as plain text, and so that’s not a possible XSS attack vector. Before we close this, I’d like to confirm that I’m indeed doing the same thing that I was doing before when I was reproducing this with an older version - and then it may also be a good idea to add a test for this.It can’t auto-escape, isn’t its level of responsibility. It will respect any existing header value though, so can set
res.setHeader('Content-Type', 'text/plain')before calling send