Fixed in snarfed/granary@62e574c and snarfed/granary@2172378, more followup in snarfed/granary#586.
Summary
Probably not super severe, but I think there may be a potential XSS vulnerability. It might just be a bug, in fact, because I didn't really look at Bridgy's source code, but I thought I'd report it here first.
Details
Here's an example: https://brid.gy/comment/mastodon/@janboddez@indieweb.social/110961328502802311/110961820713137731
On line 45 of that page's source code (you want to avoid being redirected), there's this here markup: <a class="tag" href="[https://github.com/pfefferle/wordpress-webmention/issues/399](view-source:https://github.com/pfefferle/wordpress-webmention/issues/399)"><br /> not converted to \n from Bridgy · Issue #399 · pfefferle/wordpress-webmention</a>
The <br /> is unescaped, but it is not part of the original source's markup. Instead, it is (correctly) escape there (i.e., on Mastodon). While it doesn't really matter, it is part of the link preview card (below the Mastodon post in question).
But then somehow it is decoded on the "intermediate" Bridgy page. So that makes me think one could possibly insert some other, somehow less "innocent" markup in a page title (on GitHub or elsewhere), link to it on Mastodon, and see it appear unescaped on a Bridgy page.
Maybe you do some filtering an "bad" tags are removed; I didn't check. Still, in this case, the <br /> probably should remain encoded?
PoC
One would have to create a page with some (escaped) HTML in its title. Mastodon might then generate a preview card with that HTML in, still encoded. Bridgy, it seems, will decode this markup and not escape it when it is displayed.
Impact
Bridgy has no user logins and nothing sensitive or confidential in cookies or anything else scoped to the brid.gy origin,. Due to this, XSS impact is somewhere between low and nothing. Regardless, still worth fixing!
Not a huge issue as no one will (?) normally visit these pages, and if they do, they should get redirected. Plus, Bridgy may already be stripping actually "dangerous" HTML, like script tags. But again, better safe than sorry?
janboddez Reporter
Fixed in snarfed/granary@62e574c and snarfed/granary@2172378, more followup in snarfed/granary#586.
Summary
Probably not super severe, but I think there may be a potential XSS vulnerability. It might just be a bug, in fact, because I didn't really look at Bridgy's source code, but I thought I'd report it here first.
Details
Here's an example: https://brid.gy/comment/mastodon/@janboddez@indieweb.social/110961328502802311/110961820713137731
On line 45 of that page's source code (you want to avoid being redirected), there's this here markup:
<a class="tag" href="[https://github.com/pfefferle/wordpress-webmention/issues/399](view-source:https://github.com/pfefferle/wordpress-webmention/issues/399)"><br /> not converted to \n from Bridgy · Issue #399 · pfefferle/wordpress-webmention</a>The
<br />is unescaped, but it is not part of the original source's markup. Instead, it is (correctly) escape there (i.e., on Mastodon). While it doesn't really matter, it is part of the link preview card (below the Mastodon post in question).But then somehow it is decoded on the "intermediate" Bridgy page. So that makes me think one could possibly insert some other, somehow less "innocent" markup in a page title (on GitHub or elsewhere), link to it on Mastodon, and see it appear unescaped on a Bridgy page.
Maybe you do some filtering an "bad" tags are removed; I didn't check. Still, in this case, the
<br />probably should remain encoded?PoC
One would have to create a page with some (escaped) HTML in its title. Mastodon might then generate a preview card with that HTML in, still encoded. Bridgy, it seems, will decode this markup and not escape it when it is displayed.
Impact
Bridgy has no user logins and nothing sensitive or confidential in cookies or anything else scoped to the brid.gy origin,. Due to this, XSS impact is somewhere between low and nothing. Regardless, still worth fixing!
Not a huge issue as no one will (?) normally visit these pages, and if they do, they should get redirected. Plus, Bridgy may already be stripping actually "dangerous" HTML, like
scripttags. But again, better safe than sorry?