Doesn't stealing the cookies/token require a non-HTTP-only session cookie or a token in localstorage? Do you know that Discord puts their secrets in one of those insecure places, or was it just a guess?
I believe if you always keep session cookies in secure, HTTP-only cookies, then you are more resilient to this attack.
I interviewed frontend devs last year and was shocked how few knew about this stuff.
In general if a script can run, users sessions and more importantly passwords are at risk.
It's true that an HTTP-only session cookie couldn't be directly taken, but it's trivial to present the user with a login screen and collect their password (and OTP), at which point you can easily get a session remotely. It can look entirely like the regular login page right down to the url path (because the script can modify that without causing a page load).
Yep, httpOnly cookies just give the hacker a bit of extra work in some situations. TBH I don't even think httpOnly is worth the hassle it creates for platform developers given how little security it adds.
Even scarier to me than the vulnerability is that Fidelity (whom I personally think is a good bank and investment company) was using a third party that allowed injection that could potentially steal a whole lot of money, affect markets, ruin or terminate billions of lives, and affect the course of humanity. What the fuck.
By they looks of it their docs are under a subdomain, and no part of the domain can be changed when setting the url this way. So it would still look a little out of place at least.
I mean, you're not wrong, but this is going to trick a non-zero number of people and that's not okay. We should expect more out of companies like Coinbase and hold them to a high standard.
This is unacceptable and the amount offered in general is low. It feels like we can agree on this.
No because Discord auth tokens dont expire soon enough. The only thing that kills them is changing your password. Idk why Discord doesnt invalidate them after some time, it is seriously amateur hour over there and has been for a while.
No, these are tokens that you get a new one per request, if you open up dev tools, and open the user settings panel, you will see that you get a new one every single time you open the user settings panel. They never expire, at least for years they were insanely long lasting.
if you set the cookier header right (definitely not always the case), this is true, but the javascript can still send requests that will have that cookie included, effectively still letting the hacker use the session as the logged in user
Not a problem in itself. Also, there's not much point of encrypting tokens. The attacker could use the encrypted token to authenticate themselves without having to decrypt. They could just make a request from the victim's own browser. They could do this with cookies too even with httpOnly cookies.
XSS is a big problem. If a hacker can inject a script into your front end and make it execute, it's game over. Once they get to that point, there's an infinite number of things they can do. They basically own the user's account.
Does anyone actually encrypt the contents of JWTs? I'd have thought that anyone who has concerns about the contents of the token being easily visible would be likely to avoid JWTs anyway and just use completely opaque tokens?
Encrypted tokens are opaque but they are also offline-verifiable. A simple opaque token has to be verified online (typically, against a database) whenever it's used.
JWT supports some encryption algorithms as an alternative to signatures but my experience is that most people like to keep it simple.
JWT is intended for authentication. Most of the time you're basically just signing a token containing an account ID and nothing else... Sometimes a list of groups but that only scales to a small number of groups.
Depends on the token; JWTs usually have payloads that are only base64 encoded. As well, if there's a refresh token in there it can be used to generate more tokens until invalidated (assuming invalidation is built in).
As a FE dev, I wouldn't be able to articulate what you just did in the way you did, but it is something I know in practice, just from experience. I don't think any of the FE courses I took tackled anything like that.
Token stealing hasn't been a real danger for a decade now. If you don't mark your token's as non-HTTP you're doing something explicitely wrong, because 99% of backends nowadays do this for you.
Surely, if a script is in a position to sniff the cookie from local storage, they can also indirectly use the http-only cookie by making a request from the browser. So really not much of a difference as they will be taking over the account
The cookie storage and the local storage by all means is not the same! Cookies are not stored in the local storage and could be httpOnly, so they are not directly accessible by JavaScript. Nevertheless, as described above, with this XSS attack it is easy to bypass the token and just steal the user credentials by pretending a fresh login mask keeping the origin domain intact. That's why XSS attacks are dangerous since existence. Nothing new actually.
The fact that it is just so trivial and obvious that its scary. It didn't even require any real hacking chops, just patience: literally anyone with a cursory knowledge of site design could have stumbled on this if they were looking at it.
I was once only given $1,000 for an exploit where I could put in npm usernames and get their email addresses. Big corps don't always pay what they should.
This specific XSS vulnerability may not have been, but the linked RCE vulnerability found by their friend https://kibty.town/blog/mintlify/ certainly would've been worth more than the $5,000 they were awarded.
A vulnerability like that (or even a slightly worse XSS that allowed serving js instead of only svg) could've let them register service workers to all visiting users giving future XSS ability at any time, even after the original RCE and XSS were patched.
>i quickly realised that this was the server-side serverless (lol) environment of their main documentation app, while this calls to a external api to do everything, we have the token it calls it with in the env.
>alongside, we can poison the nextjs cache for everyone for any site, allowing mass xss, defacing, etc on any docs site.
So it's a serverside bug that basically creates a more-severe stored DOM corruption vulnerability? Yeah, that's not worth anything to any buyer of vulnerabilities that I know exists. Maybe you know ones that I don't know.
I can’t speak to the value of the vulnerability as I lack the universal Rolodex of Every Exploit Buyer that is apparently available (nor am I interested in debating this with somebody that admitted they didn’t know anything about the vulnerability, declared it worthless anyway, and then moved the goalposts after a core assumption about it was trivially shown to be wrong. I’m fairly certain at this point these kids could recreate the end of the movie Antitrust and there’d be a thread somewhere with tptacek posting “This isn’t that big of a deal because”).
I just saw that you asked if the article about the server-side exploit was about a server-side exploit. It is. It’s right there in the post.
What 'arcwhite said (sorry, I got dragged into a call).
1. The exploits (not vulnerabilities; that's mostly not a thing) that command grey/black market value all have half-lives.
2. Those exploits all fit into existing business processes; if you're imagining a new business, one that isn't actively running right now as we speak (such as you'd have to do to fit any XSS in a specific service), you're not selling an exploit; you're planning a heist.
3. The high-dollar grey market services traffic exclusively in RCE (specifically: reliable RCE exploits, overwhelmingly in mainstream clientside platforms, with sharp dropoffs in valuation as you go from e.g. Chrome to the next most popular browser).
4. Most of the money made in high-ticket exploit sales apparently (according to people who actually do this work) comes on the backend, from tranched maintenance fees.
There's generally no grey market for XSS vulns. The people buying operationalized exploits generally want things that they can aim very specifically to achieve an outcome against a particular target, without that target knowing about it, and operationalized XSS vulns seldom have that nature.
Your other potential buyers are malware distributors and scammers, who usually want a vuln that has some staying power (e.g. years of exploitability). This one is pretty clearly time-limited once it becomes apparent.
For a reflected XSS? Tell me who is paying that much for such a relatively common bug...
To elaborate, to exploit this you have to convince your target to open a specially crafted link which would look very suspect. The most realistic way to exploit would be to send a shortened link and hope they click on it, that they are logged into discord.com when they do (most people use the app), that there are no other security measures (httponly cookies) etc
No real way to use this to compromise a large amount of users without more complex means
It isn't about the commonality of the bug, but the level of access it gets you on the type or massive scale of the target. This bug you your blog? Who cares. This bug on Discord or AWS? Much more attractive and lucrative.
Yes, but this is not a particularly high access level bug.
Depending on the target, it's possible that the most damage you could do with this bug is a phishing attack where the user is presented a fake sign-in form (on a sketchy url)
I think $4k is a fair amount, I've done hackerone bounties too and we got less than that years ago for a twitter reflected xss
Why would that be the maximum damage ? This XSS is particularly dangerous because you are running your script on the same domain where the user is logged-in so you can pretty much do anything you want under his session.
In addition this is widespread. It's golden for any attacker.
Because modern cookie directives and browser configs neuter a lot of the worst XSS outcomes/easiest exploit paths. I would expect all the big sites to be setting them, though I guess you never know.
I would not be that confident as you can see: on their first example, they show Discord and the XSS code is directly executed on Discord.com under the logged-in account (some people actually use web version of Discord to chat, or sign-in on the website for whatever reason).
If you have a high-value target, it is a great opportunity to use such exploits, even for single shots (it would likely not be detected anyway since it's a drop in the ocean of requests).
Spreading it on the whole internet is not a good strategy, but for 4000 USD, being able to target few users is a great value.
Besides XSS, phishing has its own opportunity.
Example: Coinbase is affected too though on the docs subdomain and there are 2-step, so you cannot do transactions directly but if you just replace the content with a "Sign-in to Coinbase / Follow this documentation procedure / Download update", this can get very very profitable.
Someone would pay 4000 USD to receive 500'000 USD back in stolen bitcoins).
Still, purely with executing things under the user sessions there are interesting things to do.
> some people actually use web version of Discord to chat, or sign-in on the website for whatever reason
Beside this security blunder on Discord’s part, I can see only upsides to using a browser version rather than an Electron desktop app. Especially given how prone Discord are to data mining their users, it seems foolish to let them out of the web sandbox and into your system
Again, here you have not so much sold a vulnerability as you have planned a heist. I agree, preemptively: you can get a lot of money from a well-executed heist!
There is a market outside Zerodium, it's Telegram. Finding a buyer takes time and trust, but it has definitively higher value than 4k USD because of its real-world impact, no matter if it is technically lower on the CVSS scores.
What happens in all these discussions is that we stealthily transition from "selling a vulnerability" to "planning a heist", and you can tell yourself any kind of story about planning a heist.
Also the XSS exploit would have been dead in the water for any sites using CSP headers. Coinbase certainly uses CSP. With this in place an XSS vuln can't inject arbitrary JS.
Well, it used to be much more accessible before, now you have to do some hack to retrieve it, and by hack, I mean some "window.webpackChunkdiscord_app.push" kinda hack, no longer your usual retrieval. Basically you have to get the token from webpack. The localStorage one does not seem to work anymore. That is what I used, but now it does not work (or rather, not always). The webpack one seems to be reliably good.
So your code goes like:
// Try localStorage first
const token = getLocalStorageItem('token')
if (token) return token
// Try webpack if localStorage fails
const webpackToken = await getTokenFromWebpack()
if (webpackToken) return webpackToken
and localStorage does fail often now. I knew the reason for that (something about them removing it at some point when you load the website?) so you need the webpack way, which is consistently reliable.
I believe if you search for the snippet above, you can find the code for the webpack way.
Discord removes the token from localStorage when the web app is open and it's in app memory, and places it back when you close the tab using the "onbeforeunload" event.
This feels so emblematic of our current era. VC funded vibe coded AI documentation startup somehow gets big name customers who don't properly vet the security of the platform, ship a massive vulnerability that could pwn millions of users and the person who reports the vulnerability gets...$5k.
If I recall last week Mintlify wrote a blog post showcasing their impressive(ly complicated) caching architecture. Pretending like they were doing real engineering, when it turns out nobody there seems to know what they're doing, but they've managed to convince some big names to use them.
Man, it's like everything I hate about modern tech. Good job Eva for finding this one. Starting to think that every AI startup or company that is heavily using gen-ai for coding is probably extremely vulnerable to the simplest of attacks. Might be a way to make some extra spending money lol.
I don't think anybody in SFBA-style software development, both pre- and post-LLM, is really resilient against these kinds of attacks. The problem isn't vibe coding so much as it is multiparty DLL-hell dependency stacks, which is something I attribute more to Javascript culture than to any recent advance in technology.
I wonder what's worse, the SFBA-style software development, but also with SFBA-style 2 hour response window to serious bugs like Discord showed, or the old fashioned enterprise report your bug and within 2 months you'll receive an e-mail confirming your report if you're lucky and a letter from a lawyer if you're not.
It's got nothing to do with DLLs or libraries or anything like that. This is a bug in their domain code. This is a simple, and bloody stupid, multi-tenant bug in a SaaS where they're not checking the tenant id before serving tenant content. Coupled with exploiting same domain cookies. Both of these have been problems that we have dealt with, and been vigilant against in SaaS apps. We had a lot of these type of attacks in the 00s when people first started deploying SaaSes and for a while we were all vigilant. The common vector for cookies back then was you'd have your main app "acmeforce.com" and you'd host customers under sub-domains like "arasaka.acmeforce.com" and cookie shenanigans would allow all sorts of attack vectors against the root site (I think github had one at one point, might be wrong!).
It's more that browser changes have allowed us to forget cookie problems, in a good way. And software developers seem to have a memory of a goldfish. The browsers have tried to build in all sort of protections against these attacks, but they only work against different domains, so we hit all the same problems as soon as some inexperienced developers starts making a multi-tenant app without proper testing.
You're right that it's a specific programming culture that is especially vulnerable to it. And for the same reasons they were vulnerable to the same thing to a lesser degree before the rise of LLMs.
But like, this case isn't really a dependency or supply chain attack. It's just allowing remote code execution because, idk, the dev who implemented it didn't read the manual and see that MDX can execute arbitrary code or something. Or maybe they vibe coded it and saw it worked and didn't bother to check. Perhaps it's a supply-chain attack on Discord et al to use Mintlify, if thats what you meant then I apologize.
I think you're right that I have an extreme aversion to SFBA-style software development, and partly because of how gen-ai is used there.
You're preaching to the choir about the fragility of the the "dig the dependency stack all the way down to hell" paradigm. But I don't think it applies in this particular case (neither does attributing it to vibe coding, IMHO).
The component which ultimately executed the payload in the SVG was the browser, and the backend dependency stack just served it verbatim as specified by the user. This is a 1990's style XSS fuckup, not anything subtle.
The crazy thing is that today the JavaScript standard library is very robust, and yet the culture of pulling in a ton of dependencies persists. It's so much easier to develop code against a stable and secure platform, yet it seems the choice is often to pull in hundreds of bits of code maintained by many different parties (instead of doing a little more in-house).
I also wonder about it recently. Also in regards to Rust which is hailed as the great savior but has the same, minimal, approach to standard library and needs loads of dependencies.
Rust doesn't have a very broad stdlib, but it has an extremely deep stdlib. Rust's stdlib is huge for the things it provides. Classical JS's stdlib was neither deep nor broad.
Furthermore, tons of those "loads of dependencies" that people point to are crates provided by the Rust project itself. Crates like serde, regex, etc aren't third-party dependencies, they're first-party dependencies just like the stdlib.
The issue is everyone loves to have everything fronted by a single domain. Most of xss is because of this basic flaw. All of this could have been avoided if discord didn't run their API docs through discord.com
It's a bit surprising they did that, to be honest. I work at a similarly-sized, HN-popular tech company and our security team is very strict about less-trusted (third party!!) code running on another domain, or a subdomain at the very least, with strict CSP and similar.
But in the age of AI, it seems like chasing the popular thing takes precedence to good practices.
After reading this, I did some research and learned a lot. I never really considered that, by including many things under the same domain, that you're increasing your blast radius w.r.t security vulernabilites. Thanks for that
This is what it really comes down to. Browsers are built around origins as the major security boundary. When you use a separate origin, safety comes for free.
And you open another can of worms which is phishing. If you run your marketing campaigns from yourcompany-deals-2025.com don't be surprised when people click yourcompany-login.com links
edit: That is, your phishing approach would work regardless, in my opinion. If your main site is `mycompany.com` then don't be surprised to see phishers sending `my-company.com` etc.
Also, you can host our content on a separate domain while still having users visit the same domain.
The fact that SVG files can contain scripts was a bit of a mistake. On one hand, the animations and entire interactive demos and even games in a single SVG are cool. But on the other hand, it opens up a serious can of worms of security vulnerabilities. As a result, SVG files are often banned from various image upload tools, they do not unfurl previews, and so on. If you upload an SVG to discord, it just shows the raw code; and don't even think about sharing an SVG image via Facebook Messenger, Wechat, Google Hangouts, or whatever. In 2025, raster formats remain way more accessible and easily shared than SVGs.
This is very sad because SVGs often have way smaller file size, and obviously look much better at various scales. If only there was a widely used vector format that does not have any script support and can be easily shared.
All SVGs should be properly sanitized going into a backend and out of it and when rendered on a page.
Do you allow SVGs to be uploaded anywhere on your site? This is a PSA that you're probably at risk unless you can find the few hundred lines of code doing the sanitization.
Note to Ruby on Rails developers, your active storage uploaded SVGs are not sanitized by default.
It would be better if they were sanitized by design and could not contain scripts and CSS. For interactive pictures, one could simply use HTML with inline SVG and scripts.
Notably, the sanitization option is risky because one sanitizer's definition of "safe" might not actually be "safe" for all clients and usages.
Plus as soon as you start sanitizing data entered by users, you risk accidentally sanitizing out legitimate customer data (Say you are making a DropBox-like fileshare and a customer's workflow relies on embedding scripts in an SVG file to e.g. make interactive self-contained graphics. Maybe not a great idea, but that is for the customer to decide, and a sanitization script would lose user data. Consider for example that GitHub does not sanitize JavaScript out of HTML files in git repositories.)
At least with external entities you could deny the parser an internet connection and force it to only load external documents from a cache you prepopulated and vetted. Turing completeness is a bullshit idea in document formats.
Postscript is pretty neat IMHO and it’s Turing complete. I really appreciated my raytraced page finally coming out of that poor HP laser after an hour or so.
With SVGs you can serve them from a different domain. IIUC the issue from TFA was that the SVGs were served from the primary domain; had they been on a different domain, they would have not been allowed to do as much.
IIUC, an untrusted inline SVG is bad. An image tag pointing to an SVG is not.
<img src="untrusted.svg"> <!-- this is ok -->
<svg from untrusted src> <!-- this is not ok -->
I feel like this is common knowledge. Just like you don't inject untrusted HTML into your page. Untrusted HTML also has scripts. You either sanitize it. OR you just don't allow it in the first place. SVG is, at this point, effectively more HTML tags.
Also remember that if the untrusted SVG file is served from the same origin and is missing a `Content-Disposition: attachment` header (or a CSP that disables scripts), an attacker could upload a malicious SVG and send the SVG URL to an unsuspecting user with pretty bad consequences.
That SVG can then do things like history.replaceState() and include <foreignObject> with HTML to change the URL shown to the user away from the SVG source and show any web UI it would like.
Because displaying user-submitted images is pretty common and doesn't feel like a security footgun, but displaying user-submitted HTML is less common (and will raise more careful security scrutiny).
Would it be possible for messenger apps to simply ignore <script> tags (and accept that this will break a small fraction of SVGs)? Or is that not a sufficient defense?
I looked into it for work at some point as we wanted to support SVG uploads. Stripping <script> is not enough to have an inert file. Scripts can also be attached as attributes. If you want to prevent external resources it gets more complex.
The only reliable solution would be an allowlist of safe elements and attributes, but it would quickly cause compat issues unless you spend time curating the rules. I did not find an existing lib doing it at the time, and it was too much effort to maintain it ourselves.
The solution I ended up implementing was having a sandboxed Chromium instance and communicating with it through the dev tools to load the SVG and rasterize it. This allowed uploading SVG files, but it was then served as rasterized PNGs to other users.
It's definitely a possible solution if you control how the file are displayed. In my case I preferred the files to be safe regardless of the mechanism used to view them (less risk of misconfiguration).
No, svgs can do `onload` and `onerror` and also reference other svgs that can themselves contain those things (base64'd or behind a URI).
But you can use an `img` tag (`<img src="evil.svg">`) and that'll basically Just Work, or use a CSP. I wouldn't rely on sanitizing, but I'd still sanitize.
> But you can use an `img` tag (`<img src="evil.svg">`) and that'll basically Just Work
That doesn't help too much if evil.svg is hosted on the same domain (with default "Content-Type: image/svg+xml" header), because attacker can send a direct link to the file.
IMO, the bigger problem with SVGs as an image format is that different software often renders them (very) differently! It's a class of problem that raster image formats basically don't have.
I would have expected SVGs to be like PDFs and render the same across devices. Is the issue that some renderers don’t implement the full spec, or that some implement parts incorrectly?
They are reasonably consistent because there is a de-facto reference implementation (Adobe Acrobat) which, if your implementation does not match exactly, users will think your implementation is broken.
You definitely don't understand PDFs, let alone SVGs.
PDFs can also contain scripts. Many applications have had issues rendering PDFs.
Don't get me wrong, the folks creating the SVG standard should've used their heads. This is like the 5th time (that I am aware of) this type of issue has happened, (and at least 3 of them were Adobe). Allowing executable code in an image/page format shouldn't be a thing.
SVG can for example contain text elements rendered with a font. If the font is not available it will render in a different one. The issue can be avoided by turning text elements into paths, but not all SVGs do that.
More like HTML and getting different browsers to render pixel perfectly identical result (which they don't) including text layout and shaping. Where different browser don't mean just Chrome, Firefox, Safari but also also IE6 and CLI based browsers like Lynx.
PDFs at least usually embed the used subset of fonts and contain explicit placement of each glyph. Which is also why editing or parsing text in PDFs is problematic. Although it also has many variations of Standard and countless Adobe exclusive extensions.
Even when you have exactly the same font text shaping is tricky. And with SVGs lack of ability to embed fonts, files which unintentionally reference system font or a generic font aren't uncommon. And when you don't have the same font, it's very likely that any carefully placed text on top of diagram will be more or less misplaced, badly wrap or even copletely disappear due to lack of space. Because there is 0 consistency between the metrics across different fonts.
The situation with specification is also not great. Just SVG 1.1 defines certain official subsets, but in practice many software pick whatever is more convenient for them.
SVG 2.0 specification has been in limbo for years although seems like recently the relevant working group has resumed discussions. Browser vendors are pushing towards synchronizing certain aspects of it with HTML adjacent standards which would make fully supporting it outside browsers even more problematic. It's not just polishing little details many major parts that were in earlier drafts are getting removed, reworked or put on backlog.
There are features which are impractical to implement or you don't want to implement outside major web browsers that have proper sandboxing system (and even that's not enough once uploads get involved) like CSS, Javascript, external resource access across different security contexts.
There are multiple different parties involved with different priorities and different threshold for what features are sane to include:
- SVG as scalable image format for icons and other UI elements in (non browser based) GUI frameworks -> anything more complicated than colored shapes/strokes can problematic
- SVG as document format for Desktop vector graphic editors (mostly Inkscape) -> the users expect feature parity with other software like Adobe Illustrator or Affinity designer
- SVG in Browsers -> get certain parts of SVG features for free by treating it like weird variation of HTML because they already have CSS and Javascript functionality
- SVG as 2d vector format for CAD and CNC use cases (including vinyl cutters, laser cutters, engravers ...) -> rarely support anything beyond shapes of basic paths
Beside the obviously problematic features like CSS, Javascript and animations, stuff like raster filter effects, clipping, text rendering, and certain resource references are also inconsistently supported.
From Inkscape unless you explicitly export as plain 1.1 compatible SVG you will likely get an SVG with some cherry picked SVG2 features and a bunch of Inkscape specific annotations. It tries to implement any extra features in standard compatible way so that in theory if you ignore all the inkscape namespaced properties you would loose some of editing functionality but you would still get the same result. In practice same of SVG renderers can't even do that and the specification for SVG2 not being finalized doesn't help. And if you export as 1.1 plain SVG some features either lack good backwards compatibility converters or they are implemented as JavaScript making files incompatible with anything except browsers including Inkscape itself.
Just recently Gnome announced working on new SVG render. But everything points that they are planning to implement only the things they need for the icons they draw themselves and official Adwaita theme and nothing more.
And that's not even considering the madness of full XML specification/feature set itself. Certain parts of it just asking for security problems. At least in recent years some XML parsers have started to have safer defaults disabling or not supporting that nonsense. But when you encounter an SVG with such XML whose fault is it? SVG renderer for intentionally not enabling insane XML features or the person who hand crafted the SVG using them.
Yeah, I spent a bit of time trying to figure out some masking issues with a file I created in Inkscape but which chrome would butcher. Turned out to be opacity on a mask layer or something.
It's wild how often we rediscover that executing untrusted code leads to decades of whack-a-mole security. Excel/Word plus macros, HTML plus JavaScript, SVG plus JavaScript, ...
Does it need to be as complicated as a new format? Or would it be enough to not allow any scripting in the provided SVGs (or stripping it out). I can't imagine there are that many SVGs out there which take advantage of the feature.
If only there was a widely used vector format that had script support and also decades of work on maintaining a battle-tested security layer around it with regular updates on a faster release cycle than your browser. That'd be crazy. Sure would suck if we killed it because we didn't want to bother maintaining it anymore.
Uh... Flash was a genuine firehose of security flaws. I mean, yeah, they patched them. So "battle tested security layer" isn't wrong in a technical sense. But, yikes, no.
There is artistically no equivalent to Flash ever since it died. Nothing else has allowed someone with artistic skills but no programming skills to create animations and games to the same degree and with the same ease.
I'd say Roblox is absolutely filling that market need. And as mentioned elsewhere, the "animations and games" demographic has moved on in the intervening decades to social media, and tools like CapCut make creating online content easier than it ever has been.
Honestly I think a lot of the Flash mania is just middle aged nerds fondly remembering their youth. The actual tool was a flash in the pan, and part of a much more complicated history of online content production. And the world is doing just fine without it.
Sure, but that's because the media and forums change, not so much a point about tool capability. The equivalent of teenaged geeks hacking on flash games today is influencer wannabes editting trends in CapCut. If anything content production is far more accessible now than in the 90's.
Yeah, it's still insane to me that the SVG can contain scripts. Wholly unnecessary; the DOM subtree it defines could be manipulated by external scripts just fine.
Anyway, I just set `svg.disabled` in Firefox. Scary world out there.
Update: this breaks quite a few things. It seems legitimate SVGs are used more often for UI icons than random diagrams and such. I suppose I shouldn't be surprised. I'll have to rethink this.
I gather from the HN discussion that it's not simple to disable scripting in an SVG, in retrospect a tragically missing feature.
I guess the next step is to propose a simple "noscripting" attribute, which if present in the root of the SVG doc inhibits all scripting by conforming renderers. Then the renderer layer at runtime could also take a noscripting option, so the rendering context could force it if appropriate. Surely someone at HN is on this committee, so see what you can do!
Edit: thinking about it a little more - maybe it's best to just require noscripting as a parameter to the rendering function. Then the browsers can have a corresponding checkbox to control SVG scripting and that's it.
Disabling script execution in svgs is very easy, it's just also easy to not realize you're about to embed an svg. `<img src="evil.svg">` will not execute scripts, a bit like your "noscripting" attribute except it's already around and works. Content Security Policy will prevent execution as well, you should be setting one for image endpoints that blocks scripts.
Sanitizing is hard to get right by comparison (svgs can reference other svgs) but it's still a good idea.
I had the impression from elsewhere in this thread that loading the svg in some other way, then you are not protected. This makes a no-brainer "don't run these ever" option in the browser seem appealing.
> This makes a no-brainer "don't run these ever" option in the browser seem appealing.
Firefox has this: svg.disabled in about:config. It doesn't seem to be properly documented, and might cause other problems for the developer (I found it accidentally, and a more deliberate search turns up mainly bug tracker entries.)
That's apparently how 4chan got hacked a while back. They were letting users upload PDFs and were using ghostscript to generate thumbnails. From what I understand, the hackers uploaded a PDF which contained PostScript which exploited a ghostscript bug.
Yes but the primary issue was that 4chan was using over a decade old version of the library that contained a vulnerability first disclosed in 2012: https://nvd.nist.gov/vuln/detail/CVE-2012-4405
In one of my penetration testing training classes, in one of the lessons, we generated a malicious PDF file that would give us a shell when the victim opened it in Adobe.
Granted, it relied on a specific bug in the JavaScript engine of Adobe Reader, so unless they're using a version that's 15 years old, it wouldn't work today, but you can't be too cautious. 0-days can always exist.
True, I just considered that once you handle a PDF with so much care like if it was poisoned, it's perhaps better to send this poison to someone else to handle.
This comes up on every story about bug bounties. There is in general no market at all for XSS vulnerabilities. That might be different for Twitter, Facebook, Instagram, and TikTok, because of the possibility of monetizing a single strike across a whole huge social network, and there's maybe a bank-shot argument for Discord, but you really have to do a lot of work to generate the monetization story for any of those.
The vulnerabilities that command real dollars all have half-lives, and can't be fixed with a single cluster of prod deploys by the victims.
If a $500 drone is coming for your $100M factory, the price limit for defense considerations isn't $500.
In the end, you are trying to encourage people not to fuck with your shit, instead of playing economic games. Especially with a bunch of teenagers who wouldn't even be fully criminally liable for doing something funny. $4K isn't much today, even for a teenager. Thanks to stupid AI shit like Mintlify, that's like worth 2GB of RAM or something.
It's not just compensation, it's a gesture. And really bad PR.
That's not how any of this works. A price for a vulnerability tracking the worst-case outcome of that vulnerability isn't a bounty or a market-clearing price; it's a shakedown fee. Meanwhile: the actual market-clearing price of an XSS vulnerability is very low (in most cases, it doesn't exist at all) because there aren't existing business processes those vulnerabilities drop seamlessly into; they're all situational and time-sensitive.
> the actual market-clearing price of an XSS vulnerability is very low (in most cases, it doesn't exist at all) because there aren't existing business processes those vulnerabilities drop seamlessly into; they're all situational and time-sensitive.
Could you elaborate on this? I don't fully understand the shorthand here.
I'm happy to answer questions but the only thing I could think to respond with here is just a restatement of what I said. I was terse; which part do you want me to expand on? Sorry about that!
> because there aren't existing business processes those vulnerabilities drop seamlessly into; they're all situational and time-sensitive.
what's an example of an existing business process that would make them valuable, just in theory? why do they not exist for xss vulns? why, and in what sense, are they only situational and time-sensitive?
i know you're an expert in this field. i'm not doubting the assertions just trying to understand them better. if i understand you're argument correctly, you're not doubting that the vuln found here could be damaging, only doubting that it could make money for an adversary willing to exploit it?
I can't think of a business process that accepts and monetizes pin-compatible XSS vulnerabilities.
But for RCE, there's lots of them! RCE vulnerabilities slot into CNE implants, botnets, ransomware rigs, and organized identity theft.
The key thing here is that these businesses already exist. There are already people in the market for the vulnerabilities. If you just imagine a new business driven by XSS vulnerabilities, that doesn't create customers, any more than imagining a new kind of cloud service instantly gets you funded for one.
I wonder what you think of this, re: the disparity between the economics you just laid out and the "companies are such fkn misers!" comments that always arise in these threads on bounty payouts...
I've seen first hand how companies devalue investment in security -- after all, it's an insurance policy whose main beneficiaries are their customers. Sure it's also reputational insurance in theory, but what is that compared with showing more profit this quarter, or using the money for growth if you're a startup, etc. Basically, the economic incentives are to foist the risks onto your customers and gamble that a huge incident won't sink you.
I wonder if that background calculus -- which is broadly accurate, imo -- is what rankles people about the low bounty rewards, especially from companies that could afford more?
The premise that "fucking companies are misers" operate on that I don't share is that vulnerabilities are finite and that, in the general case, there's an existential cost to not identifying and fixing them. From decades of vulnerability research work, including (over the past 5 years) as a buyer rather than a seller of that work: put 2 different teams on a project, get 2 different sets of vulnerabilities, with maybe 30-50% overlap. Keep doing that; you'll keep finding stuff.
Seen through that light, bug bounty programs are engineering services, not a security control. A thing generalist developers definitely don't get about high-end bug bounty programs is that they are more about focusing internal resources than they are about generating any particular set of bugs. They're a way of prioritizing triage and hardening work, driven by external incentives.
The idea that Discord is, like, eliminating their XSS risk by bidding for XSS vulnerabilities from bounty hunters; I mean, just, obviously no, right?
How does stealing someone social media accounts not slot into "organized identity theft"?
... actually: how is XSS not a form of RCE? The script is code; it's executed on the victim's machine; it arrives remotely from the untrusted, attacker-controlled source.
And with the legitimate first-party's permissions and access, at that. It has access to things within the browser's sandbox that it probably really shouldn't. Imagine if a bank had used Mintlify or something similar to implement a customer service portal, for example.
You're misreading me. It's organized identity theft driven by pin-compatible RCE exploits. Is there already an identity theft ring powered by Mintlify exploits? No? Then it doesn't matter.
The subtlety here is the difference between people using an exploit (certainly they can) and people who buy exploits for serious money.
A remote code execution bug in ios is valuable - it may take a long time to detect exploitation (potentially years if used carefully), and even after being discovered there is a long tail of devices that take time to update (although less so than on android, or linux run on embedded devices that can’t be updated)
That’s why it’s worth millions on the black market and apple will pay you $2 million dollars for it
An XSS is much harder to exploit quietly (the server can log everything), and can be closed immediately 100% with no long tail. At the push of an update the vulnerability is now worth zero. Someone paying to purchase an XSS is probably intending to use it once (with a large blast radius) and get as much as they can from it in the time until it is closed (hours? maybe days?)
Just because on average the intelligence agencies or ransom ware distributors wouldn't pay big bucks for XSS on Zerodium etc. doesn't mean that's setting the fair, or wise price for disclosure. Every bug bounty program is mostly PR mitigation. It's bad PR if you underpay for a disclosed vulnerability, which may have ended your business, considering the price of security audits/practices you cheaped out on. I mean, most bug bounty programs are actually paid by scope, not market price for technically comparable exploits. If you found an XSS vulnerability in an Apple service with this scope, I bet you would have been paid more than 4k.
I do not in fact think you would make a lot more than $4000, or even $4000 in the first place, for an Apple XSS bug, unless it was extraordinarily situationally powerful (for instance, a first-stage for a clean, direct RCE). Bounty prices have nothing at all to do with the worst-case damage a motivated actor could cause with a vulnerability.
Nice, I hadn't seen that. Well, there you go: the absolute most you're going to make for the absolute worst-case XSS bug at the largest software firm in the world.
XSS is not dead, and the web platforms mitigations (setHTML, Trusted Types) are not a panacea. CSP helps but is often configured poorly.
So, this kind of widespread XSS in a vulnerable third party component is indeed concerning.
For another example, there have been two reflected XSS vulns found in Anubis this year, putting any website that deploys it and doesn't patch at risk of JS execution on their origin.
Is it really fair to compare an open source project that desperately wants only $60k a year to hire a dev with companies that have collectively raised over billions of dollars in funding?
I think it’s very fair. Anubis generated a lot of buzz in tech communities like this one, and developers pushed it to production without taking a serious look at what it’s doing on their server. It’s a very flawed piece of software that doesn’t even do a good job at the task it’s meant for (don’t forget that it doesn’t touch any request without “Mozilla” in the UA). If some security criticism gets people to uninstall it, good.
I'd say it's probably worse in terms of scope. The audience for some AI-powered documentation platform will ultimately be fairly small (mostly corporations).
Anubis is promoting itself as a sort of Cloudflare-esque service to mitigate AI scraping. They also aren't just an open source project relying on gracious donations, there's a paid whitelabel version of the project.
If anything, Anubis probably should be held to a higher standard, given many more vulnerable people (as in, vulnerable against having XSS on their site cause significant issues with having to fish their site out of spam filters and/or bandwidth exhaustion hitting their wallet) are reliant on it compared to big corporations. Same reason that a bug in some random GitHub project somewhere probably has an impact of near zero, but a critical security bug in nginx means that there's shit on the fan. When you write software that has a massive audience, you're going to have to be held to higher standards (if not legally, at least socially).
Not that Anubis' handling of this seems to be bad or anything; both XSS attacks were mitigated, but "won't somebody think of the poor FOSS project" isn't really the right answer here.
I don't think it's fair to hold them to the same, or higher standard. at all this is literally a project being maintained by one individual. I'm sure if they were given $5 million in seed money they could probably provide 1000x value for the industry writ large if they could hire a dedicated team for the product like all those other companies with 100,000x the budget.
Seems fair. XSS is a confused deputy attack, a type of vulnerability known since the 1980s. That we keep reinventing it in every new medium is frankly embarassing.
How these companies don't hire kids like Daniel for pennies on the dollar and have him attack their stacks on a loop baffles me. Pay the kid $50k/yr (part time, he still needs to go to school) to constantly probe your crappy stacks. Within a year or two you'll have the most goddamn secure company on the internet - and no public vulns to embarrass you.
If you sign a contract with a "hacker", then you are expecting results. Otherwise how do you decide to renew the contract next year? How do you decide to raise it next year?
What if, during this contract, a vulnerability that this individual didn't found is exploited? You get rid of them?
So you're putting pressure on a person who is a researcher, not a producer. Which is wrong.
And also there's the scale. Sure, here you have one guy who exploited a vulnerability. But how long it took them to get there?
There's probably dozens of vulnerabilities yet to be exploited, requiring skills that differ so much from the ones used by this person that they won't find them. Even if you pay them for a full-time position.
Whereas, if you set up a bug bounty program, you are basically crowdsourcing your vulnerabilities: not only you probably have thousands of people actively trying to exploit vulnerabilities in your system, but also, you only give money to the ones that do manage to exploit one.
You're only paying on result.
Obviously, if the reward is not big enough, they could be tempted to sell them to someone else or use them themselves. But the risk is here no matter how you decide to handle this topic.
Just going to say here that people routinely engage pentest firms, several times annually, for roughly that sum of money, hoping but not expecting game-over vulnerabilities (and, from bitter experience as a buyer rather than a seller of those services over the last 5 years --- "no game-over vulnerabilities" is a very common outcome!)
But hiring a pentest firm is completely different than giving $50k a year to a guy, no questions asked.
The pentest firm is generally providing the whole package, from doing the actual pentest, with tools and workers of various experience and skill sets, giving you extended reports on what they did and the outcome, to providing guidance on how to fix their findings, how to make the necessary cultural changes to harden your apps, and also how to communicate that you have passed their audit.
You won't have all of that if you give free roam to a guy to _do what they do_.
This idea is more similar to patronage, which, imho, is a great idea, no matter the domain (arts or tech), but I doubt that there any company here that is willing to go this way.
Even the company that supposedly do actual patronage today are going to look at their ROI and stop as soon as they don't see the figures they're expecting.
> from bitter experience as a buyer rather than a seller of those services over the last 5 years --- "no game-over vulnerabilities" is a very common outcome!
Why bitter? Did they miss some?
Otherwise, isn't that the goal to begin with? Shouldn't you be proud instead?
Every pentest misses stuff. That's kind of the point I'm making. But yeah: as someone with a software security background, when you contract a test, you want them to find stuff!
They've already proved themselves as competent. $50k a year to a billion dollar company is nothing. Even if they find 0 vulnerabilities a year it's still worth it to them
I directionally agree with you but we could go another 20 comments deep on exactly what the purpose of an external pentest or red-team exercise is and how it might not match up perfectly with what an amateur web hacker is currently doing. But like: yeah, they could get into that business, at least until AI eats it.
There are a lot of ways to monetize a security researcher. Publishing research, even "we failed to perform a full exploit", is a huge recruitment tool and brand awareness tool.
It's not quite that simple. I don't think most bug bounty participants want a full-time job. But even more-so in my experience they are not security generalists. You can hire one person who is good at finding obscure XSS vulns, another that's good at exploiting cloud privilege escalation in IAM role definitions, another that's good at shell or archive exploits. If you look at profiles on H1 you'll see most good hackers specialize in specific types of findings.
Just because he found one vulnerability at one vendor used by Discord doesn't mean he'll find all the vulnerabilities that exist at Discord or indeed any of them.
>Discord is one of my favorite places to hunt for vulnerabilities since I'm very familiar with their API and platform. I'm at the top of their bug bounty leaderboard having reported nearly 100 vulnerabilities over the last few years. After you've gone through every feature at least 10 times, it gets boring.
That doesn't specify how many bugs there existed in the Discord codebase throughout the time where this person was active. Only once you know that, can you say whether they found a significant proportion relative to the effort they've spent and would spend as a part-time employee. That other people still find things also suggests that the statement above ("just hire him and you're secure") might have been a bit simplistic
Having been adjacent to this for years, it's because it's a cost center and not attached to the bonus of any product or program manager. Every now and then we'll get an advocate for security/integrity at a company but the effort lives and leaves with them.
Microsoft, after getting beat up over this for decades, is still horrible at it. In my area they're have been enforced regulations for years but they're written by the industry itself and infected with compliance managers and thus result in wastes of effort that makes compliance managers that came over from HR and legal happy with their eternal job security and minimal hard work.
Until some heavy handed top down regulation, written by people who understand the nature of ongoing security and software and embedded lifecycles, it's going to stay like this. Most existing supply chain regulation I've seen ends up saying "vet your vendors" and gives minimal practical guidance of how to actually do that. Likelihood of some really good law coming out of the current US administration and business climate is left as a comedy for the reader.
I wonder if this analogy could work: if some random visitor pointed out your storage room's key is nearly broken and anybody could come in now and steal your store's stock. You'd be thankful, but would you hire them to come from time to time to check if they have any other insight ? Probably not ?
If you really saw a recurring security risk you'd have many other better use of your money.
Nice discovery and writeup. Let alone for a 16 yo!.
I've never heard an XSS vulnerability described as a supply-chain attack before though, usually that one is reserved for package managers malicious scripts or companies putting backdoors in hardware.
I think you can view it as supply chain as the supply chain is about attacking resources used to infiltrate downstream (or is it upstream? I get which direction I should think this flows).
As an end user you can't really mitigate this as the attack happens in the supply chain (Mintlify) and by the time it gets to you it is basically opaque. It's like getting a signed malicious binary. It looks good to you and the trust model (the browser's origin model) seems to indicate all is fine (like the signing on the binary). But because earlier in the supply chain they made a mistake, you are now at risk. Its basically moving an XSS up a level into the "supply chain".
This makes use of a vulnerability in a dependency. If they had recommended, suggested, or pushed this purposefully vulnerable code to the dependency, then waited for a downstream (such as Discord) to pull the update and run the vulnerable code, then they would have completed a supply chain attack
The whole title is bait. Nobody would have heard of the dependency, so they don't even mention it, just call it "a supply chain" and drop four big other names that you have heard of to make it sexy. One of them was actually involved that I can tell from the post, that one is somewhat defensible. They might as well have written in the title that they've hacked the pentagon, if someone in there uses X and X had this vulnerable dependency, without X or the pentagon ever being contacted or involved or attacked
It does attack the supply chain. It attacks the provider of documentation. It's an attack on the documentation supply chain.
It would be like if you could provide a Windows Update link that went to Windows Update, but you could specify Windows Update to retrieve files from some other share that the malicious actor had control of. It's the same thing, except rather than it being a binary rather it is documentation.
Given this (including the linked writeup on the mintlify RCE), after the React RCE, if think it should be pretty obvious that
1. content security policies should always be used to prevent such scripts (here they would prevent execution of scripts from the SVG)
2. The JavaScript ecosystem should be making ` --disallow-code-generation-from-strings` a default recommendation when running NodeJS on the server.
Vercel (and other nodejs as a service providers) should warn customers that don't use CSP and `--disallow-code-generation-from-strings` that their settings should be improved.
Proxying from the "hot" domain (with user credentials) to a third party service is always going to be an awful idea. Why not just CNAME Mintlify to dev-docs.discord.com or something?
This is also why an `app.` or even better `tenant.` subdomain is always a good idea; it limits the blast radius of mistakes like this.
We've made different product decisions than them. We don't support this, nor do we request access to codebases for Git sync. Both are security issues waiting to happen, no matter how much customers want them.
The reason people want it, though, is for SEO: whether it's true or outdated voodoo, almost everyone believes having their documentation on a subdomain hurts the parent domain. Google says it's not true, SEO experts say it is.
I wish Mintlify the best here – it's stressful to let customers down like this.
What makes you say that Google claims it's not true? Google claims subdomains are completely two different domains and you'll lose all the linking/page rank stuff according to their own docs regarding SEO. Some SEO gurus claim it's not so black and white but no one knows for sure. The data does show having docs on subdomain is more harmful to your SEO if you get linked to then a lot.
To my knowledge it's not as much hurting the parent domain as having two separate "worlds". Your docs which are likely to receive higher traffic will stop contributing any SEO juice to your main website.
Yep - this is the core issue that made the vulnerability so bad. And if you use a subdomain for a third-party service, make sure your main app auth cookies are scoped to host-only. Better yet, use a completely different domain like you would for user-generated content (e.g. discorddocs.com).
I think the reason companies do this for doc sites is so they can substitute your real credentials into code snippets with "YOUR_API_KEY". Seems like a poor tradeoff given the security downside.
Mintlify security is the worse I have even encountered in a modern SaaS company.
They will leak your data, code, assets, etc. They will know they did this. You will tell them, they will acknowledge that they knew it happened, and didn't tell you.
Your docs site will go down, and you will need to page their engineers to tell them its down. This will be a surprise to them.
Interesting timing — we captured downstream exploitation of this exact attack surface.
38 days after @hackermondev's disclosure, our automated OSINT harvester pulled 121 IOCs from OpenPhish/OTX:
- 101 URLs for discord.flawing.top/blog/* (mimicking Discord's documentation structure)
- 20 URLs for openopenbox301.vercel.app (phishing hosted ON Vercel)
The attackers read the same disclosures we do. They just build infrastructure instead of writing reports.
Evidence (queryable):
curl "https://analytics.dugganusa.com/api/v1/search?q=discord.flawing.top"
Full writeup with IOCs: https://www.dugganusa.com/post/mintlify-xss-downstream-exploitation-captured
STIX feed (free): https://analytics.dugganusa.com/api/v1/stix-feed
Slightly related, as someone who doesn’t engage in this type of work, I’m curious about the potential risks associated with discovering, testing, and searching for security bugs. While it’s undoubtedly positive that this individual ultimately became a responsible person and disclosed the information, what if they hadn’t? Furthermore, on Discord’s side, what if they were unaware of this person and encountered someone attempting to snoop on this information, mistakenly believing them to be up to no good? Has there been cases where the risk involved wasn’t justified by the relatively low $4k reward? Or any specific companies you wouldn’t want to do this with because of a past incident with them?
If you engage in “white hat security research” on organisations who haven’t agreed to it (such as by offering roles of engagement on a site like hacker one) there is indeed a risk.
For example they might send the police to your door, who’ll tell you you’ve violated some 1980s computer security law.
I know 99.99% of cybercrime goes unpunished, but that’s because the attackers are hard to identify, and in distant foreign lands. As a white hat you’re identifiable and maybe in the same country, meaning it’s much easier to prosecute you.
> Furthermore, on Discord’s side, what if they were unaware of this person and encountered someone attempting to snoop on this information, mistakenly believing them to be up to no good?
Companies will create bug bounty programs where they set ground rules (like no social engineering), and have guides on how to identify yourself as an ethical hacker, for example:
The linked site https://heartbreak.ing/ explains that Mintlify disabled CORS, so that 3rd party sites can run code in your Mintlify-using environment (X, Vercel, etc).
The OP site says that .svg files can only run scripts if they are directly opened, not via <img> tags.
My understanding, the SVGs were imported directly and embedded as code, not as a `src` for an img tag. This is very common, it's a subjectively better (albeit with good security practices) way to render SVGs as it provides the ability to adjust and style them via CSS as they are now just another element in the HTML DOM. It should only be done with "trusted" SVGs however!
As for CORS, they were uploading the SVGs to an account of their own, but then using the vulnerabilities to pivot to other accounts.
A lesson from this is that you shouldn't host third-party stuff in your own domain. Instead of placing it on docs.discord.com, place it on discord-docs.com.
Stupid, especially because he is a kid and young in his career.
His lifetime earnings and ability to score a better paying job is worth way more than an extra couple thousand dollars selling this kind of exploit to criminals. It's why NDA's for security vulnerabilities are harmful because it doesn't allow a kind of social credit accumulation
Back in the day the US government would give you $20k-60k cash in a nice briefcase for this type of exploit. Just another thing big tech has ruined I suppose.
Apple gave me $47k back when I was 16 and it definitely changed my life. Was subsequently able to get out of my 3rd world country and pay for university in the UK. While the quality of education is disappointing, having a graduate visa makes it so much easier to get a job or start a business there.
The book "This Is How They Tell Me the World Ends" by Nicole Perlroth, while it's about the history of cyberweapons it does a very good job detailing the late 90s to early 2010s exploit market.
I don't have it in front of me, but I'm talking about the "nobody but us" era of exploit markets:
Where the NSA seemingly was buying anything, even if not worthwhile, as a form of "munitions collection" to be used for the future attacks.
edit: this mostly ended in the US because other nations started paying more, add in more regulations (only a handful companies are allowed to sell these exploits internationally) and software companies starting to do basic security practices (along with ruling out their own bug bounties), it just mostly whimpered away.
Also relevant to the discussion, the book discusses how the public exploit markets are exploitive to the workers themselves (low payouts when state actors would pay more) and there are periods of times where there would be open revolts too (see 2009 "No More Free Bugs" movement, also discussed in the book).
Definitely worth it if you aren't aware of this history, I wasn't.
I haven't read her book, am myself somewhat read in to the background here, and if she's claiming NSA was stockpiling serverside web bugs, I do not believe her.
In reality, intelligence agencies today don't even really stockpile mobile platform RCE. The economics and logistics are counterintuitive. Most of the money is made on the "backend", in support/update costs, paid in tranches; CNE vendors have to work hard to keep up with the platforms even when their bugs aren't getting burned. We interviewed Mark Dowd about this last year for the SCW podcast.
Maybe there is a misunderstanding, I'm not saying that the NSA would be buying XSS scripts. I'm saying that if this was 35 years ago the NSA would be buying exploits with common user software. Back then the exploits were "lesser" but there still was a market and not every exploit that was bought was a wonder of software engineering. Nowadays the targeted market is the web and getting exploits on some of the most used sites would be worthy of buying.
Kid was simply born in the wrong era to cash out easy money.
I think you're wrong about this. 35 years ago was 1990. Nobody was selling vulnerabilities in 1990 at all. By 1995, I was belting out memory corruption RCEs (it was a lot easier then), and there was no market for them at all. And there has never been a market for web vulnerabilities like XSS.
Building reliable exploits is very difficult today, but the sums a reliable exploit on a mainstream mobile platform garner are also very high. Arguably, today is the best time to be doing that kind of work, if you have the talent.
I can't imagine intelligence agencies/DoD not doing this with their gargantuan black budgets, if it's relevant to a specific target. They already contract with private research centers to develop exploits, and it's not like they're gonna run short on cash
If that were the case, we'd routinely see mysterious XSS exploits on social networks. The underlying bugs are almost always difficult to target! And yet we do not.
The biggest problem, again, is that the vulnerabilities disappear instantaneously when the vendors learn about them; in fact, they disappear in epsilon time once the vulnerabilities are used, which is not how e.g. a mobile browser drive-by works.
They have a class of attacks which are used for targeted intrusion into foreign entities. Typically espionage or cyberwarfare, so they're not often used (they're aware they might be a one-use attack), but some persist for a long time. Foreign entities also tend not to admit to the attacks when found, so if the vendor is a US entity, often the vendor doesn't find out. We do the same; when our intelligence agencies find out about a US compromise, they often keep mum about it.
I'm not talking about XSS specifically, I mean in general. An XSS isn't usually high-value, but if it affects the right target, it can be very valuable. Imagine an XSS or CSRF vuln in a web interface for firmware for industrial controls used by an enemy state, or a corporation in that state. It might only take 2 or 3 vectors to get to that point and then you have remote control of critical infrastructure.
Oh - and the idea that a vendor will always patch a hole when they find it? Not completely true. I have seen very suspicious things going on at high value vendors (w/their products), and asked questions, and nobody did anything. In my experience, management/devs are often quite willing to ignore potential compromise just to keep focusing on the quarterly goals.
Are these things you think it stands to reason the IC must be doing, or things you know for a fact that they are doing? It stands to reason for a lot of people that the IC must stockpile vulnerabilities, but they don't (they keep just a couple working ones) --- just as an example of counterintuitive things about how CNE works.
It's partly fact, partly reasoning. One fact comes from STUXnet and Snowden Leaks, where they developed and deployed vulns that persisted for years without notice. The other fact is I've interviewed at the research centers and my eyes got pretty wide at the stuff they told me without an NDA, so they're definitely paying a lot to develop and acquire more vulns/new attacks. That was all 20 years ago, but the contracts are still there so there's no reason to suppose it stopped. There's also past NSA directors that've spoken at DEFCON for years about how they want more hackers, and the new cold war with China and Russia has been ongoing for nearly as long.
I'm not saying they stockpile vulns; I'm saying if somebody on the dark web said they had a vuln for sale for $50k, and it could help an agency penetrate China/Iran strategically, it would make no sense to turn it down, when they already pay many times more money to try to develop similar vulns.
You are here implicitly comparing Stuxnet and BULLRUN, two of the most sophisticated and expensive CNE operations ever conducted, with an XSS in Discord.
Why would YOU see a mystery XSS exploit on a social network? The idea of the DoD scoring these little exploits in a box is usually to deploy in a highly controlled and specific manner. You as a layperson is of no interest to them unless you are some kind of intelligence asset or foreign adversary
detected: WAF caught or detected the attack and raised an alert, post-exploitation
discovered: they audited or pentested themself and found out, preemptively
I just mean that Coinbase didn’t see anything happening and didn’t take action though the boy successfully exploited the vulnerability on their live system.
No not to individuals. There are absolutely contracts you can score for certain attack surfaces but that usually involves going through a company. If this person is from the united states, they will absolutely land themselves a good scholarship and a very well-paid job with a security clearance.
I've been following the rise of SVG based attacks recently... It's not just hypothetical anymore... People are using SVG files to deliver full phishing pages and drive by downloads by hiding JavaScript in the markup
ALSO as someone who maintains a file upload pipeline I run every SVG through a sanitizer... Tools like DOMPurify remove scripts and enforce a safe subset of the spec... I even go as far as rasterizing user uploaded vectors to PNG when possible
HOWEVER the bigger issue is mental... Most folks treat SVG like a dumb image when browsers treat it like executable content... Until the platform changes that expectation there will always be an attack surface
This is a great example of why a Content-Security-Policy (CSP Header) should be considered mandatory for high risk sites. With it you can effectively tell the browser what JS is allowed to run, meaning that any JS injected via XSS won't work.
Cool. Makes me want to get into that — checking out sites for vulnerabilities. Very impressive for a 16 year old. Should definitely have been paid more.
I run an infosec firm and we have done attacks like this on my clients over and over and over in audits. I always say any bored teen could do most of what we do because most companies are moving too fast feature farming to have any time for responsible security hardening, and now I have yet another great citation.
Unfortunately a competitive rate agreed to in advance with a company before we do any pentesting is the only way we have ever been able to get paid fairly for this sort of work. Finding bugs in the wild as this researcher did often gets wildly underpaid relative to the potential impact of the bug, if they pay or take it seriously at all.
These companies should be ashamed paying out so little for this, and it is only a matter of time before they insult the wrong researcher who decides to pursue paths to maximum profit, or maximum damage, with a vuln like this.
> Unfortunately a competitive rate agreed to in advance with a company before we do any pentesting is the only way we have ever been able to get paid fairly for this sort of work.
So, rough estimate, how much would you have made for this?
We normally find things like this in our usual 60 hour audit blocks. Rates change over time with demand, but today an audit of that length would be $27k.
Even that is quite cheap compared to letting a blackhat find this.
If I can ask on business model, as I have a friend with a similar predicament — what percent of the time do you find vulnerabilities in those audits? Do companies push back if you don't find vulnerabilities?
We have never issued a clean report in our ~5 years of operation.
Some firms have a reputation for issuing clean reports that look good to bosses and customers, but we prefer working with clients that want an honest assessment of attack surface and how motivated blackhats will end their business.
We also stick around on retainer for firms that want security engineering consulting after audits to close the gaps we find and re-architect as needed. Unused retainer hours go into producing a lot of open source software to accelerate fixing the problems we see most often. This really incentivizes us to produce comprehensive reports that take into account how the software is developed and used in the real world.
Under our published threat model few companies pass level one, and we have helped a couple get close to level 2 with post audit consulting.
Our industry has a very long way to go as current industry standard practices are wildly dangerous and make life easy for blackhats.
As someone in a related line of work: we find vulnerabilities so close to 100% of the time that it might as well be 100% of the time. Whether they're practically exploitable or surpass your risk appetite is the real question.
These companies almost always produce "vulnerabilities", but they're also almost always trash.
"Finding: This dependency is vulnerable to CVE-X, update it, severity S". And then of course that dependency is only used during development, the vulnerable code isn't called, and they didn't bother to dig into that.
"Finding: Server allows TLS version 1.1, while it's recommended to only support version 1.2+", yeah, sure, I'm sure that if someone has broken TLS 1.1, they're coming for me, not for the banks, google, governments, apple, etc, everyone else still using TLS 1.1
... So yeah, all the audits will have "findings", they'll mostly be total garbage, and they'll charge you for it. If you're competent, you aren't going to get an RCE or XSS out of a security audit since it simply will not be there.
At Distrust we do not comment on specific dependency CVEs unless they are likely exploitable, or there are a lot of them pointing at bigger problems in the overall approach to dependency management.
That said, a policy of blindly updating dependencies to patch irrelevant CVEs is itself, a very real security vulnerability, because pulling in millions of lines of code no one reviews from the internet regularly makes you an easy target for supply chain attacks.
We have pulled off supply chain attacks on our clients a few times who were not otherwise convinced they were a real threat.
It’s clear to me now that I need to set up my home machine the way I set up BYOD when I was contracting last. I need a separate account for all of my development.
I have a friend who at one point had five monitors and 2 computers (actually it might be 3) on his desk and maybe he’s the one doing it right. He keeps his personal stuff and his programming/work stuff completely separate.
I have three OS installs. Windows install for games. Another Windows for development (I have to for windows dev). And a Ubuntu install for anything not games/work. The windows drives use bitlocker and they can't access each other's files. It's not perfect.
Although with the amount of crap I have to install for windows development I'm starting to wonder if a base VM image that is used as a start point for each project would be cleaner.
I really don't get the appeal to have everything om one top-level domain, especially completely separate or even external services. The scope of this would've been basically zero if they just put it on docs.discord.com.
Especially something like this, where they were reverse proxying a SaaS, seems extra stupid. It's more work to set up, adds an unnecessary dependency between services and you end up paying for all the internet traffic three times (even if not directly).
I critiqued the title elsewhere already so let me say here that the screenshot does show code running in Discord's browser context. They didn't send it to an employee and actually pwn the company, as one might understand from the title, but it doesn't strictly say that and I would count finding XSS as close enough. Saying they've pwned Discord, I think is fair enough
The other three companies mentioned though... yeah, they totally pwned the dependency first and foremost
You're pretty much on the money. Reflected XSS requires social engineering to really target anyone without other primitives. Unfortunately this report is not very clear about the tangible impacts or limitations of what they could do with this particular XSS either. Saying that every Mintlify customer was "vulnerable to account takeover with a single malicious link" strikes me as specious to say the least. Still, can't fault kids for getting excited about recognition and a payout.
imo, the impact is pretty clear here. an unsuspecting user clicks (or is redirected) to one of these malicious links on the platform (ex. vercel); the script grabs their cookie and credentials and sends it to the attacker. they now have full access to the victim's account.
Nice! So the Cookie is accessible by JavaScript on all of those sites? That would be pretty surprising given the prevalence of HttpOnly, so that doesn't seem clear to me at all. And they're all using Cookie-based auth, you think? You're a bug bounty hunter so I'll defer to your wisdom, but doesn't it seem more likely that an account takeover would be possible via a state-changing request from the user's existing session? Let's say they can abuse it to reset the user's password. Nice, that's an account takeover... for every user not using MFA. But then there are anti-CSRF mitigations. Okay, not insurmountable with an XSS, but implemented differently everywhere. And what if the auth domains are separate to the domain on which the XSS is triggered? Man this seems to get less clear by the minute. Please clear this up for me.
XSS is categorically not an RCE and my point is that mitigations exist which make "It allows you to run any action as if you were the owner of the account" an unwarranted assumption. The writeup shows that it's possible to pop an alert box. That doesn't tell you anything about what's actually possible. Obviously Discord got enough information to take it seriously, but extrapolating that to suggest every third-party using Mintlify is vulnerable to account takeover is highly dubious based on what's presented.
How is XSS not remote code execution? You can do anything, from send fetch requests to the server with full credentials to loggging keystrokes or even open a tunnel and eval payloads...
Anything the user can do, you can do via an XSS attack.
Show me where you can "open a tunnel" using the XSS in this post.
> Anything the user can do, you can do via an XSS attack.
I just explained why this isn't a reasonable assumption. You seem to have multiple fundamental misunderstandings about web application security so I don't think it's constructive for either of us to continue this conversation.
Go to Discord and paste that into your console. None of us will hold it against you if you come back and delete these comments once you learn about Content Security Policy.
The same Discord that configures things so that any time you open the console it greets you with a giant message warning you not to paste anything into the console?
Hmm, I've always thought of "RCE" in a more general way, regarding the ability to execute arbitrary code on a computer you don't own. For example some multiplayer games have had exploits that let hosts run arbitrary code on clients that connect to them, and I've seen that called an RCE vulnerability. shrugs
If it’s running code outside of a normal browser sandbox then, yes it’s a RCE. Because it can now access to nearly everything on the user’s computer, including their browser, email, etc.
XSS is limited to accessing just that one website.
Well, llmslave2 is right. If discord.com executes javascript to conduct user actions, and you can execute javascript on discord.com, you are acting on the account as if you were discord.com
Except discord.com doesn't execute JavaScript, the user's browser does. These are meaningful distinctions that delineate the impact. You aren't "discord.com" if you target someone with an XSS exploit, you've only run a script in a user's session. Whether you can actually do anything with that script or not decides whether you can take over the account or not.
Everybody knows that XSS is a client side exploit, you're acting naive by pretending like we're claiming it gives access to a server and ignoring the fact that having control of the client gives you de facto control of whatever account is logged into the client.
It is not as cool as the RPC exploit of React/Next.js where you could call any function on the server-side including “vm.sysexec” or whatever it was, but still not to be fully ignored
Yes, it's generally a "full account takeover" for a given discord user.
But RCE usually means ability to run any code on the web server, and would generally get you access to _everything_ including full direct access to the database. All accounts and all data, not just a few accounts.
the impact varied by customer. in Discord's case, the auth token is stored in local storage and their docs is hosted on the primary domain; they were susceptible to a full account takeover. X's docs are on a different subdomain but we found a CSRF attack that could facilitate a full account takeover. most companies were significantly affected in one way or another.
Interesting. I agree with the other commenter about the post should've included how an account takeover was possible.
You mention one method being a cookie sent to an attacker-controlled domain, but that in itself is a vulnerability given it being incorrectly scoped (missing HTTPOnly & SameSite atleast).
> the auth token is stored in local storage
Has anyone reported this (rhetorical question)? What in the world could be the justification for this?
In my opinion, any full account takeovers due to XSS is a vulnerability, even ignoring XSS. Changing email/password/phone should require verification back to one of those methods. Or at least input of the previous password.
And to my earlier point, none of that is in the writeup here to support the enormous claims made in framing the finding. This is good work, and congratulations on the bounty. I hope you have a long career in security ahead. Obviously you communicated your findings to Discord clearly enough for them to understand the impact. I look forward to reading more research from you all in the future and I hope the technical details will accompany it.
You could send that link to an unsuspecting user and steal their cookies, make API requests to send messages on their behalf, etc
Apparently one of the other linked posts shows how you can also gain RCE, since the docs are statically pre-rendered and there’s no sandboxing to prevent you from evalling arbitrary JavaScript.
Also linked in his guide (which I missed) and [here in a separate HN post](https://news.ycombinator.com/item?id=46317546). I think this other author's post is a lot more detailed and arguably more useful to folks reading on HN.
It's hosted on the official domain. That means you have at least 2 options: a) chain in with another issue which allows to load that as a trusted resource, or b) scam people by directing them to an "official" post. Also you get discord cookies access.
You have control over what displays on a page with a discord.com domain, you could manipulate the dom to have a login or something else and have it pass the data to your servers. A user would just see a link from discord.com
if you click on the link because it has discord.com in the domain the script in the SVG can (maybe) get your session data. Not actually sure if that’s true though, I suppose it depends on how the cookies are scoped
That's how language shifts. Supply chain attacks are broadly seen as a scary new thing, so like with any such term, people try to shoehorn things they find into its meaning. Those who fall for and repeat it shift the language. The same happened to the word 0day: it used to mean "a vulnerability that you specifically haven't had a chance to patch because it has been known to the world for 0 days". A scary thing. Now it's commonly used as synonym for the word vulnerability
I wonder if every vulnerability is soon called a supply chain attack:
- Microsoft releases a Windows security update -> Discord uses Windows -> supply chain attack on Discord
- User didn't install security updates for a while -> brought their phone to work -> phone with microphone sits in pocket in meeting room -> supply chain attack
Everything has dependencies that can be vulnerable, that doesn't mean "the supply chain" was attacked in a targeted effort by some attacker
Stop using Discord as well - their software is packed full of data mining, ads, and cosmetic upsells. For public community groups use a forum site (then it’s indexable as well!), and for private groups use something actually private like Signal
Okay, seriously, can we just get one, just ONE document/image spec that doesn't let you embed scripts or remote content? What is with this constant need to put the same exactly vulnerability into EVERYTHING?! Just let me have a spec for completely static documents, jfc!
It is clear that SVG should not support scripts and CSS in SVG files. Those who need them can simply create HTML with inline SVG tags and scripts. And SVG should contain only shapes, effects and transformations.
Or maybe we need a new image format, "SVG without scripts and CSS".
The problem with CSS is that if you want to write an SVG viewer, you have to implement a whole CSS engine, which might be more complex than SVG renderer itself. And if you create an image in an editor, like Inkscape, you don't use CSS anyway. CSS is meant to be used when you write the code manually (instead of using an editor), for example, in a web app, and in this case you could use HTML as well.
One of these days I'm gonna have to learn why cross-site scripting even matters, especially with modern browsers restricting a script's access to anything local
The "Hello world" examples always show using it to steal your cookies, which obviously doesn't work now when nearly every site uses the "httpOnly" flag which makes the cookie inaccessible to JavaScript, but really, stealing your session isn't necessary. They just have to make the XSS payload run the necessary JavaScript.
Once the JavaScript is running on the page, all bets are off. They can do ANYTHING that the page can do, because now they can make HTTP requests on your behalf. SOP no longer applies. CSRF no longer protects you. The attacker has full control of your account, and all the requests will appear to come from YOUR browser.
If I can run my own code but in your context, I can pull in malicious scripts.
With those (all these are "possible" but not always, as usual, it depends, and random off the top of my head):
- I can redirect you to sites I control where I may be able to capture your login credentials.
- May be able to prompt and get you to download malware or virus payloads and run them locally.
- Can deface the site you are on, either leading to reputational harm for that brand, or leading you to think you're doing one thing when you're actually doing another.
- I may be able to exfiltrate your cookies and auth tokens for that site and potentially act as you.
- I might be able to pivot to other connected sites that use that site's authentication.
- I can prompt, as the site, for escalated access, and you may grant it because you trust that site, thereby potentially gaining access to your machine (it's not that the browsers fully restrict local access, they just require permission).
- Other social engineering attacks, trying to trick you into doing something that grants me more access, information, etc.
It's a good question and one mature orgs ask themselves all the time. As you can see from most of the replies here, XSS captures the fancy of the bug bounty crowd because there are tonnes of hypothetical impacts so everyone is free to let their imagination run wild when arguing with triagers. It's also the exploit nonpareil for nerdsnipers because sanitisation is always changing and people get to spend their days coming up with increasingly ridiculous payloads to bypass them. In reality, find me one active threat actor who has compromised a business lately with an XSS. It's not an irrelevant risk, but the attention it gets is wildly disproportionate to its real-world impact.
Damn, this is a good era to be in high school (or university) with a lot of free time. $4000 is a pretty good haul for a few hours of work poking at stuff.
Really nice finding for such a young folk - really liked reading into it.Also what i love most about it is what an actually simple vuln it is.
Tho what i find mostly funny bout it is how many people are complaining about the 4k$.
I mean sure the potential "damage" could have been alot higher, tho at the same time there was no contract in place or , at least as far as i understood, a clear bug bounty targeted. This was a, even if well done, random checking of XHR/Requests to see if anything vulnerable can be found - searching for kinda file exposure / xss / RFI/LFI. So everything paid (and especially since this is a mintlify bug not an actual discord bug) is just a nice net gain.
Also ill just drop here : ask yourself, are you searching for such vulns just for money or to make the net a safer place for everyone. Sure getting some bucks for the work is nice, but i personally just hope stuff gets fixed on report.
every commit in every open source project should now go through an AI to see if it can detect anything nefarious. I'm sure there are ways to fool it but it makes it a lot easier for bad actors to get caught.
Link here is to gist , but on lobste.rs some one posted link to Eva's blog. And it with links to friends blogs, feel so much like old internet. I dont even know what I enjoyed more, reading technical side or discovering this dark forest.
I was going to ask. Isn't 4k from Discord pretty low for the work conducted here? I'm not familiar with bounty payouts. I'm hoping these companies aren't taking advantage of them.
4k is sadly discords highest bounty they give out (screenshot from their bugcrowd program: https://imgur.com/a/KNIdeXh) even more critical issues then this one get paid the same amount out
Supply and demand. Selling via grey markets is an option, but many white hats don't go that route due to risk. There's plenty of people that will also find vulnerabilities without any money attached.
That's a limited view. The damage this could cause should be accounted for. People don't have to sell shit, they could fuck things up just for the fun of it. That's something to consider, especially with a bunch of teenagers. Now, these big corpos didn't take the chance to sponsor and encourage these kids early careers and make this fuck-up good PR, at least.
That's not how economics works. I can't do my job without a computer or glasses but that doesn't mean I can pay the suppliers of these things most of my salary each. Preventing a 100k€ problem says almost nothing about what the payout should be. As for them just causing chaos for fun, that nets them just about nothing (what's an evening of fun worth, like what are you willing to pay for a cinema ticket?). This is certainly more (hundreds of times more) and so covers that risk as well
In an ideal world, these bugs, especially low-hanging fruits, shouldn't be discoverable by some random kids. These billion dollar companies should have their own security researchers constantly monitoring their stack. But those costs are cut, because the law de facto doesn't hold them liable for getting hacked. It's a very good deal for companies to pay bug bounties, but they mostly cheap out on that, too.
It's like a finders reward elsewhere in life. If you lost your wallet, your immaterial and material loss is quite high, but apart from cash the contents are of way less value for a finder/thief. These type of rewards are meant to manipulate emotions and motivation. Twitter paid these kids each between $1 and $20. That's insulting. As I said elsewhere, bug bounties are PR. And it's bad PR in this case. Black market pricing is the absolute low end for valuation (it's basically the cash value in the wallet example).
> these bugs, especially low-hanging fruits, shouldn't be discoverable by some random kids. These billion dollar companies should have their own security researchers [...]
I'm twice this kid's age and have been doing this hobby-turned-work as long as they have. I can tell you the work we do is no different. It doesn't matter if you're 16 or 64 or what your credentials are or salary is. We're all just hackers. Hacker ethos is judging by skill, not appearance. Welcome to hacker news :P
> Twitter paid these kids each between $1 and $20.
The submission doesn't say they've even contacted Xitter. I thought it was in the title just to drop names that we've heard of that used this dependency. Did you legit find somewhere that they got ≤20$ for an exploitable XSS on the x.com or twitter.com domains? That is definitely a strangely low amount but then I'm not surprised by anything where Elon is involved. It could also have been a silent fix without even replying to the reporter; I've had that often enough. But yeah from X I would expect a few hundred dollars at least and from old twitter (or another legit business) more than that (as Discord demonstrated)
Get off your high horse. In this instance it's been a kid, and it does not concern some highly arcane flaw in a crypto library or chained kernel exploit, which may have passed even a pro. I already implied this bug should have been found by in-house security, so obviously it's within the domain of professionals and teenagers alike.
> The submission doesn't say they've even contacted Xitter.
This one doesn't. This one does: https://heartbreak.ing/. Or at least, I presume they meant Twitter when they wrote "one company valued 44 billion".
I've rarely gotten bug bounty money and not even always a written thank-you but it doesn't cross my mind to somehow seek out a malicious actor that wants to make use of what I found. Leave the place better than you found it and all that
You are right, but that could (probably not) make them go for the bad route because they would get way more money that way. 4k for a bug that could take control of your customer account sounds disrespectful to me.
Yeah, my read is that the teenage hacker confronted with this ridiculous payslip sees two ways forward: accept the pay cut for the CV benefit of working with bug bounties, or get a bit better at hiding your ass and make them really pay.
If I were 16, I’d be thinking I just made an obscene amount of money ($4,000!) messing with computers for fun, and got to meet people at a famous company.
That’s a free car. Free computer. Uber eats for months.
And my status with my peers as a hacker would be cemented.
I get that bounty amounts are low vs SE salary, but that’s not at all how my 16yo self would see it.
I hope I'm not assuming too much but I'm really hope the up and coming hacker is smart enough to know that his work was worth more than $4,000. That's 1-2% of an annual SE salary for someone with similar skillset.
I mean, as a hiring manager, a fresh grad with multiple bug bounties tells me a lot about their drive and skill, so I'd agree. It's a great differentiator.
This is a pretty scary exploit, considering how easily it could be abused.
Imagine just one link in a tweet, support ticket, or email: https://discord.com/_mintlify/static/evil/exploit.svg. If you click it, JavaScript runs on the discord.com origin.
Here's what could happen:
- Your Discord session cookies and token could be stolen, leading to a complete account takeover.
- read/write your developer applications & webhooks, allowing them to add or modify bots, reset secrets, and push malicious updates to millions.
- access any Discord API endpoint as you, meaning they could join or delete servers, DM friends, or even buy Nitro with your saved payment info.
- maybe even harvest OAuth tokens from sites that use "Login with Disord."
Given the potential damage, the $4,000 bounty feels like a slap in the face.
edit: just noticed how HN just turned this into a clickable link - this makes it even scarier!
Doesn't stealing the cookies/token require a non-HTTP-only session cookie or a token in localstorage? Do you know that Discord puts their secrets in one of those insecure places, or was it just a guess?
I believe if you always keep session cookies in secure, HTTP-only cookies, then you are more resilient to this attack.
I interviewed frontend devs last year and was shocked how few knew about this stuff.
In general if a script can run, users sessions and more importantly passwords are at risk.
It's true that an HTTP-only session cookie couldn't be directly taken, but it's trivial to present the user with a login screen and collect their password (and OTP), at which point you can easily get a session remotely. It can look entirely like the regular login page right down to the url path (because the script can modify that without causing a page load).
Yep, httpOnly cookies just give the hacker a bit of extra work in some situations. TBH I don't even think httpOnly is worth the hassle it creates for platform developers given how little security it adds.
Wow did not realize a url could be set like that without promoting a page reload...
To be clear only the path and query parameters part of the url can change, the domain (or sub domain) stays intact.
Even scarier to me than the vulnerability is that Fidelity (whom I personally think is a good bank and investment company) was using a third party that allowed injection that could potentially steal a whole lot of money, affect markets, ruin or terminate billions of lives, and affect the course of humanity. What the fuck.
Their knowledge of finance is certainly better than their knowledge of web tech.
Historically and today.
That’s why I’m a Schwab junkie… but finance is a hotspot for this kind of stuff.
[dead]
If it weren't already in the same domain you wouldn't be able to read a non-HttpOnly cookie anyway, so that's moot.
Well that's how SPAs work (single page applications)
How do you modify the url exactly?
https://developer.mozilla.org/en-US/docs/Web/API/History/pus...
`history.replaceState(null, "", "/login")`
For Coinbase docs, this is a disaster particularly
By they looks of it their docs are under a subdomain, and no part of the domain can be changed when setting the url this way. So it would still look a little out of place at least.
I mean, you're not wrong, but this is going to trick a non-zero number of people and that's not okay. We should expect more out of companies like Coinbase and hold them to a high standard.
This is unacceptable and the amount offered in general is low. It feels like we can agree on this.
auth URLs are almost always a shitshow in every larger corp. Having the url be https://docs.bigcorp.com/sso/authlayerv1/us-east-24/aws/secu... would not stand out at all to anyone.
No because Discord auth tokens dont expire soon enough. The only thing that kills them is changing your password. Idk why Discord doesnt invalidate them after some time, it is seriously amateur hour over there and has been for a while.
Probably because the end user hates login in, my friends always complain about the “remember me” button being useless for some services.
No, these are tokens that you get a new one per request, if you open up dev tools, and open the user settings panel, you will see that you get a new one every single time you open the user settings panel. They never expire, at least for years they were insanely long lasting.
if you set the cookier header right (definitely not always the case), this is true, but the javascript can still send requests that will have that cookie included, effectively still letting the hacker use the session as the logged in user
with http-only they can't _steal_ the cookie, but they can still _use_ the cookie. It reduces the impact but doesn't fully solve it.
Discord puts the authentication token in local storage
Is that a problem on its own? It's like, encrypted right? Maybe a time sensitive token?
Not a problem in itself. Also, there's not much point of encrypting tokens. The attacker could use the encrypted token to authenticate themselves without having to decrypt. They could just make a request from the victim's own browser. They could do this with cookies too even with httpOnly cookies.
XSS is a big problem. If a hacker can inject a script into your front end and make it execute, it's game over. Once they get to that point, there's an infinite number of things they can do. They basically own the user's account.
Does anyone actually encrypt the contents of JWTs? I'd have thought that anyone who has concerns about the contents of the token being easily visible would be likely to avoid JWTs anyway and just use completely opaque tokens?
Encrypted tokens are opaque but they are also offline-verifiable. A simple opaque token has to be verified online (typically, against a database) whenever it's used.
Auth0, for example, supports JWE for its access tokens: https://auth0.com/docs/secure/tokens/access-tokens/json-web-...
JWT supports some encryption algorithms as an alternative to signatures but my experience is that most people like to keep it simple.
JWT is intended for authentication. Most of the time you're basically just signing a token containing an account ID and nothing else... Sometimes a list of groups but that only scales to a small number of groups.
Depends on the token; JWTs usually have payloads that are only base64 encoded. As well, if there's a refresh token in there it can be used to generate more tokens until invalidated (assuming invalidation is built in).
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
You may be thinking of CSRF mitigations. XSS exploits are more dangerous and can do more than steal sessions.
As a FE dev, I wouldn't be able to articulate what you just did in the way you did, but it is something I know in practice, just from experience. I don't think any of the FE courses I took tackled anything like that.
Token stealing hasn't been a real danger for a decade now. If you don't mark your token's as non-HTTP you're doing something explicitely wrong, because 99% of backends nowadays do this for you.
with http-only they can't _steal_ the cookie, but they can still _use_ the cookie. It reduces the impact but doesn't fully solve it.
Surely, if a script is in a position to sniff the cookie from local storage, they can also indirectly use the http-only cookie by making a request from the browser. So really not much of a difference as they will be taking over the account
The cookie storage and the local storage by all means is not the same! Cookies are not stored in the local storage and could be httpOnly, so they are not directly accessible by JavaScript. Nevertheless, as described above, with this XSS attack it is easy to bypass the token and just steal the user credentials by pretending a fresh login mask keeping the origin domain intact. That's why XSS attacks are dangerous since existence. Nothing new actually.
The fact that it is just so trivial and obvious that its scary. It didn't even require any real hacking chops, just patience: literally anyone with a cursory knowledge of site design could have stumbled on this if they were looking at it.
Terrifying.
>the $4,000 bounty feels like a slap in the face.
And serves a reminder crime does pay.
In the black market, it would have been worth a bit more.
I was once only given $1,000 for an exploit where I could put in npm usernames and get their email addresses. Big corps don't always pay what they should.
yeah, but nothing pays as much as doing free work for (checks notes) mintlify feels
No it would not have been.
This specific XSS vulnerability may not have been, but the linked RCE vulnerability found by their friend https://kibty.town/blog/mintlify/ certainly would've been worth more than the $5,000 they were awarded.
A vulnerability like that (or even a slightly worse XSS that allowed serving js instead of only svg) could've let them register service workers to all visiting users giving future XSS ability at any time, even after the original RCE and XSS were patched.
Maybe? I don't know enough about the vulnerability. Is it serverside? Then it isn't worth very much.
>i quickly realised that this was the server-side serverless (lol) environment of their main documentation app, while this calls to a external api to do everything, we have the token it calls it with in the env.
>alongside, we can poison the nextjs cache for everyone for any site, allowing mass xss, defacing, etc on any docs site.
So it's a serverside bug that basically creates a more-severe stored DOM corruption vulnerability? Yeah, that's not worth anything to any buyer of vulnerabilities that I know exists. Maybe you know ones that I don't know.
I can’t speak to the value of the vulnerability as I lack the universal Rolodex of Every Exploit Buyer that is apparently available (nor am I interested in debating this with somebody that admitted they didn’t know anything about the vulnerability, declared it worthless anyway, and then moved the goalposts after a core assumption about it was trivially shown to be wrong. I’m fairly certain at this point these kids could recreate the end of the movie Antitrust and there’d be a thread somewhere with tptacek posting “This isn’t that big of a deal because”).
I just saw that you asked if the article about the server-side exploit was about a server-side exploit. It is. It’s right there in the post.
Can I ask which exploit buyers you are aware of? None of us know all of them! It'll be easier to discuss this with a specific buyer in mind.
Could you elaborate on why not?
What 'arcwhite said (sorry, I got dragged into a call).
1. The exploits (not vulnerabilities; that's mostly not a thing) that command grey/black market value all have half-lives.
2. Those exploits all fit into existing business processes; if you're imagining a new business, one that isn't actively running right now as we speak (such as you'd have to do to fit any XSS in a specific service), you're not selling an exploit; you're planning a heist.
3. The high-dollar grey market services traffic exclusively in RCE (specifically: reliable RCE exploits, overwhelmingly in mainstream clientside platforms, with sharp dropoffs in valuation as you go from e.g. Chrome to the next most popular browser).
4. Most of the money made in high-ticket exploit sales apparently (according to people who actually do this work) comes on the backend, from tranched maintenance fees.
There's generally no grey market for XSS vulns. The people buying operationalized exploits generally want things that they can aim very specifically to achieve an outcome against a particular target, without that target knowing about it, and operationalized XSS vulns seldom have that nature.
Your other potential buyers are malware distributors and scammers, who usually want a vuln that has some staying power (e.g. years of exploitability). This one is pretty clearly time-limited once it becomes apparent.
It would have been. Ten times the amount at least.
For a reflected XSS? Tell me who is paying that much for such a relatively common bug...
To elaborate, to exploit this you have to convince your target to open a specially crafted link which would look very suspect. The most realistic way to exploit would be to send a shortened link and hope they click on it, that they are logged into discord.com when they do (most people use the app), that there are no other security measures (httponly cookies) etc
No real way to use this to compromise a large amount of users without more complex means
It isn't about the commonality of the bug, but the level of access it gets you on the type or massive scale of the target. This bug you your blog? Who cares. This bug on Discord or AWS? Much more attractive and lucrative.
Yes, but this is not a particularly high access level bug.
Depending on the target, it's possible that the most damage you could do with this bug is a phishing attack where the user is presented a fake sign-in form (on a sketchy url)
I think $4k is a fair amount, I've done hackerone bounties too and we got less than that years ago for a twitter reflected xss
Why would that be the maximum damage ? This XSS is particularly dangerous because you are running your script on the same domain where the user is logged-in so you can pretty much do anything you want under his session.
In addition this is widespread. It's golden for any attacker.
Because modern cookie directives and browser configs neuter a lot of the worst XSS outcomes/easiest exploit paths. I would expect all the big sites to be setting them, though I guess you never know.
I would not be that confident as you can see: on their first example, they show Discord and the XSS code is directly executed on Discord.com under the logged-in account (some people actually use web version of Discord to chat, or sign-in on the website for whatever reason).
If you have a high-value target, it is a great opportunity to use such exploits, even for single shots (it would likely not be detected anyway since it's a drop in the ocean of requests).
Spreading it on the whole internet is not a good strategy, but for 4000 USD, being able to target few users is a great value.
Besides XSS, phishing has its own opportunity.
Example: Coinbase is affected too though on the docs subdomain and there are 2-step, so you cannot do transactions directly but if you just replace the content with a "Sign-in to Coinbase / Follow this documentation procedure / Download update", this can get very very profitable.
Someone would pay 4000 USD to receive 500'000 USD back in stolen bitcoins).
Still, purely with executing things under the user sessions there are interesting things to do.
> some people actually use web version of Discord to chat, or sign-in on the website for whatever reason
Beside this security blunder on Discord’s part, I can see only upsides to using a browser version rather than an Electron desktop app. Especially given how prone Discord are to data mining their users, it seems foolish to let them out of the web sandbox and into your system
Again, here you have not so much sold a vulnerability as you have planned a heist. I agree, preemptively: you can get a lot of money from a well-executed heist!
Do you want to execute actions as logged-in user on high-value website XXX ?
If yes -> very useful
Nobody is disputing that a wide variety of vulnerabilities are "useful", only that there's no market for most of them. I'd still urgently fix an XSS.
There is a market outside Zerodium, it's Telegram. Finding a buyer takes time and trust, but it has definitively higher value than 4k USD because of its real-world impact, no matter if it is technically lower on the CVSS scores.
Really? Tell me a story about someone selling an XSS vulnerability on Telegram.
("The CVSS chart"?)
Moments later
Why do people keep bringing up "Zerodium" as if it's a thing?
I understand your perspective about the technical value of an exploit, but I disagree with the concept that technical value = market value.
There are unorganized buyers who may be interested if they see potential to weaponize it.
In reality, if you want to maximize revenue, yes, you need to organize your own heist (if that's what you meant)
Do you know this or do you just think it should be true?
> understand your perspective about the technical value of an exploit
Going out on the world’s sturdiest limb and saying u/tptacek knows the technical and trading sides of exploits. (Read his bio.)
AIU this feature is SSS, not XSS, so XSS protections don't apply.
How would you make money from this? Most likely via phishing. Not exactly a zero-click RCE.
What happens in all these discussions is that we stealthily transition from "selling a vulnerability" to "planning a heist", and you can tell yourself any kind of story about planning a heist.
Also the XSS exploit would have been dead in the water for any sites using CSP headers. Coinbase certainly uses CSP. With this in place an XSS vuln can't inject arbitrary JS.
I don't like tptacek, but it's insane to not back up this comment with any amount of evidence or at least explanation. The guy knows his shit.
Hey I was wrong about Apple downthread.
> - Your Discord session cookies and token could be stolen, leading to a complete account takeover.
Discord uses HttpOnly cookies (except for the cookie consent banner).
tokens are stored in localStorage, which is accessible by JS
Well, it used to be much more accessible before, now you have to do some hack to retrieve it, and by hack, I mean some "window.webpackChunkdiscord_app.push" kinda hack, no longer your usual retrieval. Basically you have to get the token from webpack. The localStorage one does not seem to work anymore. That is what I used, but now it does not work (or rather, not always). The webpack one seems to be reliably good.
So your code goes like:
and localStorage does fail often now. I knew the reason for that (something about them removing it at some point when you load the website?) so you need the webpack way, which is consistently reliable.I believe if you search for the snippet above, you can find the code for the webpack way.
Discord removes the token from localStorage when the web app is open and it's in app memory, and places it back when you close the tab using the "onbeforeunload" event.
Yeah, that is what I have observed, too.
You can retrieve it the webpack way though.
This feels so emblematic of our current era. VC funded vibe coded AI documentation startup somehow gets big name customers who don't properly vet the security of the platform, ship a massive vulnerability that could pwn millions of users and the person who reports the vulnerability gets...$5k.
If I recall last week Mintlify wrote a blog post showcasing their impressive(ly complicated) caching architecture. Pretending like they were doing real engineering, when it turns out nobody there seems to know what they're doing, but they've managed to convince some big names to use them.
Man, it's like everything I hate about modern tech. Good job Eva for finding this one. Starting to think that every AI startup or company that is heavily using gen-ai for coding is probably extremely vulnerable to the simplest of attacks. Might be a way to make some extra spending money lol.
I don't think anybody in SFBA-style software development, both pre- and post-LLM, is really resilient against these kinds of attacks. The problem isn't vibe coding so much as it is multiparty DLL-hell dependency stacks, which is something I attribute more to Javascript culture than to any recent advance in technology.
I wonder what's worse, the SFBA-style software development, but also with SFBA-style 2 hour response window to serious bugs like Discord showed, or the old fashioned enterprise report your bug and within 2 months you'll receive an e-mail confirming your report if you're lucky and a letter from a lawyer if you're not.
It's got nothing to do with DLLs or libraries or anything like that. This is a bug in their domain code. This is a simple, and bloody stupid, multi-tenant bug in a SaaS where they're not checking the tenant id before serving tenant content. Coupled with exploiting same domain cookies. Both of these have been problems that we have dealt with, and been vigilant against in SaaS apps. We had a lot of these type of attacks in the 00s when people first started deploying SaaSes and for a while we were all vigilant. The common vector for cookies back then was you'd have your main app "acmeforce.com" and you'd host customers under sub-domains like "arasaka.acmeforce.com" and cookie shenanigans would allow all sorts of attack vectors against the root site (I think github had one at one point, might be wrong!).
It's more that browser changes have allowed us to forget cookie problems, in a good way. And software developers seem to have a memory of a goldfish. The browsers have tried to build in all sort of protections against these attacks, but they only work against different domains, so we hit all the same problems as soon as some inexperienced developers starts making a multi-tenant app without proper testing.
That's "San Francisco Bay Area" for anyone else wondering
Is this synonymous with AI-assisted coding now??
The person above implies as much. Doesn't mean anyone else thinks it
You're right that it's a specific programming culture that is especially vulnerable to it. And for the same reasons they were vulnerable to the same thing to a lesser degree before the rise of LLMs.
But like, this case isn't really a dependency or supply chain attack. It's just allowing remote code execution because, idk, the dev who implemented it didn't read the manual and see that MDX can execute arbitrary code or something. Or maybe they vibe coded it and saw it worked and didn't bother to check. Perhaps it's a supply-chain attack on Discord et al to use Mintlify, if thats what you meant then I apologize.
I think you're right that I have an extreme aversion to SFBA-style software development, and partly because of how gen-ai is used there.
One might consider this a supply chain attack because the title of the post is “We pwned X, Vercel, Cursor, and Discord through a supply-chain attack”
Sometimes titles are inaccurate
You're preaching to the choir about the fragility of the the "dig the dependency stack all the way down to hell" paradigm. But I don't think it applies in this particular case (neither does attributing it to vibe coding, IMHO).
The component which ultimately executed the payload in the SVG was the browser, and the backend dependency stack just served it verbatim as specified by the user. This is a 1990's style XSS fuckup, not anything subtle.
I do occasionally wonder how different things would be if JavaScript had come with a very robust standard library from early on.
The crazy thing is that today the JavaScript standard library is very robust, and yet the culture of pulling in a ton of dependencies persists. It's so much easier to develop code against a stable and secure platform, yet it seems the choice is often to pull in hundreds of bits of code maintained by many different parties (instead of doing a little more in-house).
I also wonder about it recently. Also in regards to Rust which is hailed as the great savior but has the same, minimal, approach to standard library and needs loads of dependencies.
No, I wish people would let this meme die.
Rust doesn't have a very broad stdlib, but it has an extremely deep stdlib. Rust's stdlib is huge for the things it provides. Classical JS's stdlib was neither deep nor broad.
Furthermore, tons of those "loads of dependencies" that people point to are crates provided by the Rust project itself. Crates like serde, regex, etc aren't third-party dependencies, they're first-party dependencies just like the stdlib.
The issue is everyone loves to have everything fronted by a single domain. Most of xss is because of this basic flaw. All of this could have been avoided if discord didn't run their API docs through discord.com
It's a bit surprising they did that, to be honest. I work at a similarly-sized, HN-popular tech company and our security team is very strict about less-trusted (third party!!) code running on another domain, or a subdomain at the very least, with strict CSP and similar.
But in the age of AI, it seems like chasing the popular thing takes precedence to good practices.
Thanks for this comment tick_tock :)
After reading this, I did some research and learned a lot. I never really considered that, by including many things under the same domain, that you're increasing your blast radius w.r.t security vulernabilites. Thanks for that
This is what it really comes down to. Browsers are built around origins as the major security boundary. When you use a separate origin, safety comes for free.
And you open another can of worms which is phishing. If you run your marketing campaigns from yourcompany-deals-2025.com don't be surprised when people click yourcompany-login.com links
I'm not sure I understand.
edit: That is, your phishing approach would work regardless, in my opinion. If your main site is `mycompany.com` then don't be surprised to see phishers sending `my-company.com` etc.
Also, you can host our content on a separate domain while still having users visit the same domain.
Trust doesn’t though - discord.com/docs looks legit, as does docs.discord.com - discord-docs.com immediately sets off red flags
Is there no way to tell the browser “hey this URL is using the same domain but please isolate it from the rest”?
You can use a sandboxed iframe without an origin.
You can still have discord.com/docs with content hosted on discord-docs.com
But then you have to be able to trust that the other domain is actually operated by Discord and isn't some social engineering front.
I'm curious what caching architecture a docs site needs, it can't be more complicated than a standard fare CDN?
Here's the other post:
https://news.ycombinator.com/item?id=46276313
Search indexing, etc.
The fact that SVG files can contain scripts was a bit of a mistake. On one hand, the animations and entire interactive demos and even games in a single SVG are cool. But on the other hand, it opens up a serious can of worms of security vulnerabilities. As a result, SVG files are often banned from various image upload tools, they do not unfurl previews, and so on. If you upload an SVG to discord, it just shows the raw code; and don't even think about sharing an SVG image via Facebook Messenger, Wechat, Google Hangouts, or whatever. In 2025, raster formats remain way more accessible and easily shared than SVGs.
This is very sad because SVGs often have way smaller file size, and obviously look much better at various scales. If only there was a widely used vector format that does not have any script support and can be easily shared.
All SVGs should be properly sanitized going into a backend and out of it and when rendered on a page.
Do you allow SVGs to be uploaded anywhere on your site? This is a PSA that you're probably at risk unless you can find the few hundred lines of code doing the sanitization.
Note to Ruby on Rails developers, your active storage uploaded SVGs are not sanitized by default.
Is there SVG sanitization code which has been formally proven correct and itself free of security vulnerabilities?
It would be better if they were sanitized by design and could not contain scripts and CSS. For interactive pictures, one could simply use HTML with inline SVG and scripts.
GitLab has some code in their repo if you want to see how to do it.
This is what they actually use: https://github.com/flavorjones/loofah
Sanitisation is a tricky process, it can be real easy for something to slip through the cracks.
Yes. Much better to handle all untrusted data safely rather than try to transform untrusted data into trusted data.
I found this page a helpful summary of ways to prevent SVG XSS: https://digi.ninja/blog/svg_xss.php
Notably, the sanitization option is risky because one sanitizer's definition of "safe" might not actually be "safe" for all clients and usages.
Plus as soon as you start sanitizing data entered by users, you risk accidentally sanitizing out legitimate customer data (Say you are making a DropBox-like fileshare and a customer's workflow relies on embedding scripts in an SVG file to e.g. make interactive self-contained graphics. Maybe not a great idea, but that is for the customer to decide, and a sanitization script would lose user data. Consider for example that GitHub does not sanitize JavaScript out of HTML files in git repositories.)
Yeah I’ve worked on a few pieces of software now that tried SVG sanitizing on uploads, got hacked, and banned the uploads.
I guess it is a matter of parsing svg. Trying to hack around with regex is asking for trouble indeed.
just run them through `svgo` and get the benefits of smaller filesizes as well
svgo is a minifier, not a sanitizer.
I should have clarified `svgo + removeScripts`
https://svgo.dev/docs/plugins/removeScripts/
External entities in XML[1] were a similar issue back when everyone was using XML for everything, and parsers processed external-entities by default.
1: https://owasp.org/www-community/vulnerabilities/XML_External...
XXE should have never existed.
Whoever decided it should be enabled by default should be put into some sort of cybersecurity jail.
It's no different from links to googlesyndication in offline html docs.
At least with external entities you could deny the parser an internet connection and force it to only load external documents from a cache you prepopulated and vetted. Turing completeness is a bullshit idea in document formats.
Postscript is pretty neat IMHO and it’s Turing complete. I really appreciated my raytraced page finally coming out of that poor HP laser after an hour or so.
I once sent a Sierpinski's Triangle postscript program to a shared printer. It took 90 minutes, and pissed off everybody else trying to print.
PostScript can emulate the ZMachine (Zork text adventures and all of infocom) with "zmachine.ps". Look it up at DDG/GG.
How does it do I/O?
A monad. It’s just a class of abstract Endor Moon or something. Probably you have to send all commands up to the current state to it. :)
One of the very first SVG documents I encountered was a port of the PS Tiger to SVG. It loaded a lot faster than the PostScript Tiger.
Sounds almost like a fun crypto mining opportunity.
With SVGs you can serve them from a different domain. IIUC the issue from TFA was that the SVGs were served from the primary domain; had they been on a different domain, they would have not been allowed to do as much.
calling Leonard Rosenthol ...
IIUC, an untrusted inline SVG is bad. An image tag pointing to an SVG is not.
I feel like this is common knowledge. Just like you don't inject untrusted HTML into your page. Untrusted HTML also has scripts. You either sanitize it. OR you just don't allow it in the first place. SVG is, at this point, effectively more HTML tags.Also remember that if the untrusted SVG file is served from the same origin and is missing a `Content-Disposition: attachment` header (or a CSP that disables scripts), an attacker could upload a malicious SVG and send the SVG URL to an unsuspecting user with pretty bad consequences.
That SVG can then do things like history.replaceState() and include <foreignObject> with HTML to change the URL shown to the user away from the SVG source and show any web UI it would like.
how is that special/different from an HTML URL?
Because displaying user-submitted images is pretty common and doesn't feel like a security footgun, but displaying user-submitted HTML is less common (and will raise more careful security scrutiny).
Would it be possible for messenger apps to simply ignore <script> tags (and accept that this will break a small fraction of SVGs)? Or is that not a sufficient defense?
I looked into it for work at some point as we wanted to support SVG uploads. Stripping <script> is not enough to have an inert file. Scripts can also be attached as attributes. If you want to prevent external resources it gets more complex.
The only reliable solution would be an allowlist of safe elements and attributes, but it would quickly cause compat issues unless you spend time curating the rules. I did not find an existing lib doing it at the time, and it was too much effort to maintain it ourselves.
The solution I ended up implementing was having a sandboxed Chromium instance and communicating with it through the dev tools to load the SVG and rasterize it. This allowed uploading SVG files, but it was then served as rasterized PNGs to other users.
Shouldn't the ignoring of scripting be done at the user agent level? Maybe some kind of HTTP header to allow sites to disable scripts in SVG ala CORS?
It's definitely a possible solution if you control how the file are displayed. In my case I preferred the files to be safe regardless of the mechanism used to view them (less risk of misconfiguration).
Content-Security-Policy: default-src 'none'
No, svgs can do `onload` and `onerror` and also reference other svgs that can themselves contain those things (base64'd or behind a URI).
But you can use an `img` tag (`<img src="evil.svg">`) and that'll basically Just Work, or use a CSP. I wouldn't rely on sanitizing, but I'd still sanitize.
> But you can use an `img` tag (`<img src="evil.svg">`) and that'll basically Just Work
That doesn't help too much if evil.svg is hosted on the same domain (with default "Content-Type: image/svg+xml" header), because attacker can send a direct link to the file.
Reddit horribly breaks direct links to images and serves html instead.
IMO, the bigger problem with SVGs as an image format is that different software often renders them (very) differently! It's a class of problem that raster image formats basically don't have.
> It's a class of problem that raster image formats basically don't have.
That took way too long to be this way. Some old browsers couldn't even get the colors of PNGs correct, let alone the transparency.
I would have expected SVGs to be like PDFs and render the same across devices. Is the issue that some renderers don’t implement the full spec, or that some implement parts incorrectly?
They are like PDFs in that they do not render the same with different software or on different devices.
I would say PDFs are actually reasonably consistent though. Weird things happen on occasion, but I've certainly had more success than with SVGs.
They are reasonably consistent because there is a de-facto reference implementation (Adobe Acrobat) which, if your implementation does not match exactly, users will think your implementation is broken.
There isn't such an implementation for SVG.
We live in a world where Adobe set the standard, and anything that didn't render like Adobe was considered "incorrect".
You definitely don't understand PDFs, let alone SVGs.
PDFs can also contain scripts. Many applications have had issues rendering PDFs.
Don't get me wrong, the folks creating the SVG standard should've used their heads. This is like the 5th time (that I am aware of) this type of issue has happened, (and at least 3 of them were Adobe). Allowing executable code in an image/page format shouldn't be a thing.
SVG can for example contain text elements rendered with a font. If the font is not available it will render in a different one. The issue can be avoided by turning text elements into paths, but not all SVGs do that.
Also text zoom.
More like HTML and getting different browsers to render pixel perfectly identical result (which they don't) including text layout and shaping. Where different browser don't mean just Chrome, Firefox, Safari but also also IE6 and CLI based browsers like Lynx.
PDFs at least usually embed the used subset of fonts and contain explicit placement of each glyph. Which is also why editing or parsing text in PDFs is problematic. Although it also has many variations of Standard and countless Adobe exclusive extensions.
Even when you have exactly the same font text shaping is tricky. And with SVGs lack of ability to embed fonts, files which unintentionally reference system font or a generic font aren't uncommon. And when you don't have the same font, it's very likely that any carefully placed text on top of diagram will be more or less misplaced, badly wrap or even copletely disappear due to lack of space. Because there is 0 consistency between the metrics across different fonts.
The situation with specification is also not great. Just SVG 1.1 defines certain official subsets, but in practice many software pick whatever is more convenient for them.
SVG 2.0 specification has been in limbo for years although seems like recently the relevant working group has resumed discussions. Browser vendors are pushing towards synchronizing certain aspects of it with HTML adjacent standards which would make fully supporting it outside browsers even more problematic. It's not just polishing little details many major parts that were in earlier drafts are getting removed, reworked or put on backlog.
There are features which are impractical to implement or you don't want to implement outside major web browsers that have proper sandboxing system (and even that's not enough once uploads get involved) like CSS, Javascript, external resource access across different security contexts.
There are multiple different parties involved with different priorities and different threshold for what features are sane to include:
- SVG as scalable image format for icons and other UI elements in (non browser based) GUI frameworks -> anything more complicated than colored shapes/strokes can problematic
- SVG as document format for Desktop vector graphic editors (mostly Inkscape) -> the users expect feature parity with other software like Adobe Illustrator or Affinity designer
- SVG in Browsers -> get certain parts of SVG features for free by treating it like weird variation of HTML because they already have CSS and Javascript functionality
- SVG as 2d vector format for CAD and CNC use cases (including vinyl cutters, laser cutters, engravers ...) -> rarely support anything beyond shapes of basic paths
Beside the obviously problematic features like CSS, Javascript and animations, stuff like raster filter effects, clipping, text rendering, and certain resource references are also inconsistently supported.
From Inkscape unless you explicitly export as plain 1.1 compatible SVG you will likely get an SVG with some cherry picked SVG2 features and a bunch of Inkscape specific annotations. It tries to implement any extra features in standard compatible way so that in theory if you ignore all the inkscape namespaced properties you would loose some of editing functionality but you would still get the same result. In practice same of SVG renderers can't even do that and the specification for SVG2 not being finalized doesn't help. And if you export as 1.1 plain SVG some features either lack good backwards compatibility converters or they are implemented as JavaScript making files incompatible with anything except browsers including Inkscape itself.
Just recently Gnome announced working on new SVG render. But everything points that they are planning to implement only the things they need for the icons they draw themselves and official Adwaita theme and nothing more.
And that's not even considering the madness of full XML specification/feature set itself. Certain parts of it just asking for security problems. At least in recent years some XML parsers have started to have safer defaults disabling or not supporting that nonsense. But when you encounter an SVG with such XML whose fault is it? SVG renderer for intentionally not enabling insane XML features or the person who hand crafted the SVG using them.
Even PDFs don't always render the same from one platform to another. I've mostly seen it due to missing fonts.
Most renderers don't implement the full spec.
Yeah, I spent a bit of time trying to figure out some masking issues with a file I created in Inkscape but which chrome would butcher. Turned out to be opacity on a mask layer or something.
Could there be a limited format that disables scripting? Like in Excel: xlsx files have no macros, but xlsm (and the old xls) can contain macros.
But how else would we revisit all the security bugs of Flash/Macromedia?
It's wild how often we rediscover that executing untrusted code leads to decades of whack-a-mole security. Excel/Word plus macros, HTML plus JavaScript, SVG plus JavaScript, ...
It’s wild how often specs are ok for 9 versions, and then at version 10, standard bodies decide to transform them into a trojan firehose.
It’s so regular like clockwork that it has to be a nation state doing this to us.
Any notable examples you can share?
PDF was purposely a non-Turing adaptation of PostScript. Then they added JavaScript support.
Does it need to be as complicated as a new format? Or would it be enough to not allow any scripting in the provided SVGs (or stripping it out). I can't imagine there are that many SVGs out there which take advantage of the feature.
If only there was a widely used vector format that had script support and also decades of work on maintaining a battle-tested security layer around it with regular updates on a faster release cycle than your browser. That'd be crazy. Sure would suck if we killed it because we didn't want to bother maintaining it anymore.
(Yes I'm still salty about Flash.)
> because we didn't want to bother maintaining it anymore
That wasn't the only reason. Flash was also proprietary, and opaque, and single-vendor, among many other problems with it.
Uh... Flash was a genuine firehose of security flaws. I mean, yeah, they patched them. So "battle tested security layer" isn't wrong in a technical sense. But, yikes, no.
The Flash revisionism I see around here occasionally is bizarre.
No, Flash was terrible and killing it was good.
There is artistically no equivalent to Flash ever since it died. Nothing else has allowed someone with artistic skills but no programming skills to create animations and games to the same degree and with the same ease.
what is missing was a replacement for the flash editor itself, not the format.
I'd say Roblox is absolutely filling that market need. And as mentioned elsewhere, the "animations and games" demographic has moved on in the intervening decades to social media, and tools like CapCut make creating online content easier than it ever has been.
Honestly I think a lot of the Flash mania is just middle aged nerds fondly remembering their youth. The actual tool was a flash in the pan, and part of a much more complicated history of online content production. And the world is doing just fine without it.
It was terrible from a security POV, but the tooling was superb.
I remember my teenage friends creating things with flash in a way that doesn't happen on the modern web.
Sure, but that's because the media and forums change, not so much a point about tool capability. The equivalent of teenaged geeks hacking on flash games today is influencer wannabes editting trends in CapCut. If anything content production is far more accessible now than in the 90's.
I think it depends on whether you see Flash as competing with webvideo or with downloadable executables.
SVG without <script> would do just fine.
SVG also supports event attributes, so you should probably strip those too.
Yeah, it's still insane to me that the SVG can contain scripts. Wholly unnecessary; the DOM subtree it defines could be manipulated by external scripts just fine.
Anyway, I just set `svg.disabled` in Firefox. Scary world out there.
Update: this breaks quite a few things. It seems legitimate SVGs are used more often for UI icons than random diagrams and such. I suppose I shouldn't be surprised. I'll have to rethink this.
What we got was html for vector graphics and what we wanted was jpeg for vector graphics.
Wikipedia, which allows uploading media, deals with this by rendering svgs on the server side.
is santizing SVGs hard, or just everyone forgets they can contain js?
I gather from the HN discussion that it's not simple to disable scripting in an SVG, in retrospect a tragically missing feature.
I guess the next step is to propose a simple "noscripting" attribute, which if present in the root of the SVG doc inhibits all scripting by conforming renderers. Then the renderer layer at runtime could also take a noscripting option, so the rendering context could force it if appropriate. Surely someone at HN is on this committee, so see what you can do!
Edit: thinking about it a little more - maybe it's best to just require noscripting as a parameter to the rendering function. Then the browsers can have a corresponding checkbox to control SVG scripting and that's it.
Disabling script execution in svgs is very easy, it's just also easy to not realize you're about to embed an svg. `<img src="evil.svg">` will not execute scripts, a bit like your "noscripting" attribute except it's already around and works. Content Security Policy will prevent execution as well, you should be setting one for image endpoints that blocks scripts.
Sanitizing is hard to get right by comparison (svgs can reference other svgs) but it's still a good idea.
I had the impression from elsewhere in this thread that loading the svg in some other way, then you are not protected. This makes a no-brainer "don't run these ever" option in the browser seem appealing.
> This makes a no-brainer "don't run these ever" option in the browser seem appealing.
Firefox has this: svg.disabled in about:config. It doesn't seem to be properly documented, and might cause other problems for the developer (I found it accidentally, and a more deliberate search turns up mainly bug tracker entries.)
its common to santize html string to parse it and remove/error on script tags (and other possible vulnerabilities)
i wonder do people not do this with svgs?
User name checks out.
I believe the username is from the AI simulation of HN in 10 years.
> On one hand, the animations and entire interactive demos and even games in a single SVG are cool. But on the other hand
Didn’t we do this already with Flash? Why would this lesson not have stuck?
I agree, when animating SVGs I never put the js inside them so having the ability embed it is just dangerious I think
Wow, I learned one thing today!
Do other vector formats have the same vulnerabilities?
"The script doesn't run unless the file is directly opened (you can't run scripts from (<img src="/image.svg">)."
It will run if its in an <object> tag.
So if you're directly embedding the thing. This is a somewhat rare use case, should not be banned almost anywhere...
There is: PDF. You may not like it or adobe, but its there and widely supported.
PDF also has script support unfortunately.
That's apparently how 4chan got hacked a while back. They were letting users upload PDFs and were using ghostscript to generate thumbnails. From what I understand, the hackers uploaded a PDF which contained PostScript which exploited a ghostscript bug.
Yes but the primary issue was that 4chan was using over a decade old version of the library that contained a vulnerability first disclosed in 2012: https://nvd.nist.gov/vuln/detail/CVE-2012-4405
Does that mean that opening arbitrary pdfs on your laptop is unsafe?
Let me put it this way...
In one of my penetration testing training classes, in one of the lessons, we generated a malicious PDF file that would give us a shell when the victim opened it in Adobe.
Granted, it relied on a specific bug in the JavaScript engine of Adobe Reader, so unless they're using a version that's 15 years old, it wouldn't work today, but you can't be too cautious. 0-days can always exist.
Yes, opening random pdfs especially in random and old pdf viewers is not a good idea.
If you must open a possibly infected pdf, then do it in browser, pdf.js is considered mostly safe, and updated.
Use the PDF to JPG online services, convenient and you still get your result without having to deal with any sandbox
Except of course that you're sharing the contents of that PDF with a random online service.
True, I just considered that once you handle a PDF with so much care like if it was poisoned, it's perhaps better to send this poison to someone else to handle.
Better a DJVU file generated at a high DPI.
Seems like such a tiny amount of money for a bug that can be used to completely own your customers accounts. Also not much excuse for xss these days.
This comes up on every story about bug bounties. There is in general no market at all for XSS vulnerabilities. That might be different for Twitter, Facebook, Instagram, and TikTok, because of the possibility of monetizing a single strike across a whole huge social network, and there's maybe a bank-shot argument for Discord, but you really have to do a lot of work to generate the monetization story for any of those.
The vulnerabilities that command real dollars all have half-lives, and can't be fixed with a single cluster of prod deploys by the victims.
If a $500 drone is coming for your $100M factory, the price limit for defense considerations isn't $500.
In the end, you are trying to encourage people not to fuck with your shit, instead of playing economic games. Especially with a bunch of teenagers who wouldn't even be fully criminally liable for doing something funny. $4K isn't much today, even for a teenager. Thanks to stupid AI shit like Mintlify, that's like worth 2GB of RAM or something.
It's not just compensation, it's a gesture. And really bad PR.
That's not how any of this works. A price for a vulnerability tracking the worst-case outcome of that vulnerability isn't a bounty or a market-clearing price; it's a shakedown fee. Meanwhile: the actual market-clearing price of an XSS vulnerability is very low (in most cases, it doesn't exist at all) because there aren't existing business processes those vulnerabilities drop seamlessly into; they're all situational and time-sensitive.
> the actual market-clearing price of an XSS vulnerability is very low (in most cases, it doesn't exist at all) because there aren't existing business processes those vulnerabilities drop seamlessly into; they're all situational and time-sensitive.
Could you elaborate on this? I don't fully understand the shorthand here.
I'm happy to answer questions but the only thing I could think to respond with here is just a restatement of what I said. I was terse; which part do you want me to expand on? Sorry about that!
> because there aren't existing business processes those vulnerabilities drop seamlessly into; they're all situational and time-sensitive.
what's an example of an existing business process that would make them valuable, just in theory? why do they not exist for xss vulns? why, and in what sense, are they only situational and time-sensitive?
i know you're an expert in this field. i'm not doubting the assertions just trying to understand them better. if i understand you're argument correctly, you're not doubting that the vuln found here could be damaging, only doubting that it could make money for an adversary willing to exploit it?
I can't think of a business process that accepts and monetizes pin-compatible XSS vulnerabilities.
But for RCE, there's lots of them! RCE vulnerabilities slot into CNE implants, botnets, ransomware rigs, and organized identity theft.
The key thing here is that these businesses already exist. There are already people in the market for the vulnerabilities. If you just imagine a new business driven by XSS vulnerabilities, that doesn't create customers, any more than imagining a new kind of cloud service instantly gets you funded for one.
Thank you, makes a lot of sense.
I wonder what you think of this, re: the disparity between the economics you just laid out and the "companies are such fkn misers!" comments that always arise in these threads on bounty payouts...
I've seen first hand how companies devalue investment in security -- after all, it's an insurance policy whose main beneficiaries are their customers. Sure it's also reputational insurance in theory, but what is that compared with showing more profit this quarter, or using the money for growth if you're a startup, etc. Basically, the economic incentives are to foist the risks onto your customers and gamble that a huge incident won't sink you.
I wonder if that background calculus -- which is broadly accurate, imo -- is what rankles people about the low bounty rewards, especially from companies that could afford more?
The premise that "fucking companies are misers" operate on that I don't share is that vulnerabilities are finite and that, in the general case, there's an existential cost to not identifying and fixing them. From decades of vulnerability research work, including (over the past 5 years) as a buyer rather than a seller of that work: put 2 different teams on a project, get 2 different sets of vulnerabilities, with maybe 30-50% overlap. Keep doing that; you'll keep finding stuff.
Seen through that light, bug bounty programs are engineering services, not a security control. A thing generalist developers definitely don't get about high-end bug bounty programs is that they are more about focusing internal resources than they are about generating any particular set of bugs. They're a way of prioritizing triage and hardening work, driven by external incentives.
The idea that Discord is, like, eliminating their XSS risk by bidding for XSS vulnerabilities from bounty hunters; I mean, just, obviously no, right?
How does stealing someone social media accounts not slot into "organized identity theft"?
... actually: how is XSS not a form of RCE? The script is code; it's executed on the victim's machine; it arrives remotely from the untrusted, attacker-controlled source.
And with the legitimate first-party's permissions and access, at that. It has access to things within the browser's sandbox that it probably really shouldn't. Imagine if a bank had used Mintlify or something similar to implement a customer service portal, for example.
You're misreading me. It's organized identity theft driven by pin-compatible RCE exploits. Is there already an identity theft ring powered by Mintlify exploits? No? Then it doesn't matter.
The subtlety here is the difference between people using an exploit (certainly they can) and people who buy exploits for serious money.
A remote code execution bug in ios is valuable - it may take a long time to detect exploitation (potentially years if used carefully), and even after being discovered there is a long tail of devices that take time to update (although less so than on android, or linux run on embedded devices that can’t be updated) That’s why it’s worth millions on the black market and apple will pay you $2 million dollars for it
An XSS is much harder to exploit quietly (the server can log everything), and can be closed immediately 100% with no long tail. At the push of an update the vulnerability is now worth zero. Someone paying to purchase an XSS is probably intending to use it once (with a large blast radius) and get as much as they can from it in the time until it is closed (hours? maybe days?)
> That's not how any of this works.
Yes, evidently not.
Just because on average the intelligence agencies or ransom ware distributors wouldn't pay big bucks for XSS on Zerodium etc. doesn't mean that's setting the fair, or wise price for disclosure. Every bug bounty program is mostly PR mitigation. It's bad PR if you underpay for a disclosed vulnerability, which may have ended your business, considering the price of security audits/practices you cheaped out on. I mean, most bug bounty programs are actually paid by scope, not market price for technically comparable exploits. If you found an XSS vulnerability in an Apple service with this scope, I bet you would have been paid more than 4k.
Nobody is buying anything on "Zerodium".
I wasn't aware they are gone. It's not my game, replace with whatever shady exploit trader/market out there.
I do not in fact think you would make a lot more than $4000, or even $4000 in the first place, for an Apple XSS bug, unless it was extraordinarily situationally powerful (for instance, a first-stage for a clean, direct RCE). Bounty prices have nothing at all to do with the worst-case damage a motivated actor could cause with a vulnerability.
https://security.apple.com/bounty/categories/
The lowest tier is $5k. XSS up to $40k. I think we're talking exfiltration of dev credentials...
Nice, I hadn't seen that. Well, there you go: the absolute most you're going to make for the absolute worst-case XSS bug at the largest software firm in the world.
Right, but Eva found an RCE and only got $5,000.
An RCE in what? Nobody's buying your Discord RCE.
>Also not much excuse for xss these days.
XSS is not dead, and the web platforms mitigations (setHTML, Trusted Types) are not a panacea. CSP helps but is often configured poorly.
So, this kind of widespread XSS in a vulnerable third party component is indeed concerning.
For another example, there have been two reflected XSS vulns found in Anubis this year, putting any website that deploys it and doesn't patch at risk of JS execution on their origin.
Audit your third-party dependencies!
https://github.com/TecharoHQ/anubis/security/advisories/GHSA...
https://github.com/TecharoHQ/anubis/security/advisories/GHSA...
Is it really fair to compare an open source project that desperately wants only $60k a year to hire a dev with companies that have collectively raised over billions of dollars in funding?
I think it’s very fair. Anubis generated a lot of buzz in tech communities like this one, and developers pushed it to production without taking a serious look at what it’s doing on their server. It’s a very flawed piece of software that doesn’t even do a good job at the task it’s meant for (don’t forget that it doesn’t touch any request without “Mozilla” in the UA). If some security criticism gets people to uninstall it, good.
I'd say it's probably worse in terms of scope. The audience for some AI-powered documentation platform will ultimately be fairly small (mostly corporations).
Anubis is promoting itself as a sort of Cloudflare-esque service to mitigate AI scraping. They also aren't just an open source project relying on gracious donations, there's a paid whitelabel version of the project.
If anything, Anubis probably should be held to a higher standard, given many more vulnerable people (as in, vulnerable against having XSS on their site cause significant issues with having to fish their site out of spam filters and/or bandwidth exhaustion hitting their wallet) are reliant on it compared to big corporations. Same reason that a bug in some random GitHub project somewhere probably has an impact of near zero, but a critical security bug in nginx means that there's shit on the fan. When you write software that has a massive audience, you're going to have to be held to higher standards (if not legally, at least socially).
Not that Anubis' handling of this seems to be bad or anything; both XSS attacks were mitigated, but "won't somebody think of the poor FOSS project" isn't really the right answer here.
I don't think it's fair to hold them to the same, or higher standard. at all this is literally a project being maintained by one individual. I'm sure if they were given $5 million in seed money they could probably provide 1000x value for the industry writ large if they could hire a dedicated team for the product like all those other companies with 100,000x the budget.
Seems fair. XSS is a confused deputy attack, a type of vulnerability known since the 1980s. That we keep reinventing it in every new medium is frankly embarassing.
How these companies don't hire kids like Daniel for pennies on the dollar and have him attack their stacks on a loop baffles me. Pay the kid $50k/yr (part time, he still needs to go to school) to constantly probe your crappy stacks. Within a year or two you'll have the most goddamn secure company on the internet - and no public vulns to embarrass you.
That's a bit simplistic.
If you sign a contract with a "hacker", then you are expecting results. Otherwise how do you decide to renew the contract next year? How do you decide to raise it next year? What if, during this contract, a vulnerability that this individual didn't found is exploited? You get rid of them?
So you're putting pressure on a person who is a researcher, not a producer. Which is wrong.
And also there's the scale. Sure, here you have one guy who exploited a vulnerability. But how long it took them to get there? There's probably dozens of vulnerabilities yet to be exploited, requiring skills that differ so much from the ones used by this person that they won't find them. Even if you pay them for a full-time position.
Whereas, if you set up a bug bounty program, you are basically crowdsourcing your vulnerabilities: not only you probably have thousands of people actively trying to exploit vulnerabilities in your system, but also, you only give money to the ones that do manage to exploit one. You're only paying on result.
Obviously, if the reward is not big enough, they could be tempted to sell them to someone else or use them themselves. But the risk is here no matter how you decide to handle this topic.
Just going to say here that people routinely engage pentest firms, several times annually, for roughly that sum of money, hoping but not expecting game-over vulnerabilities (and, from bitter experience as a buyer rather than a seller of those services over the last 5 years --- "no game-over vulnerabilities" is a very common outcome!)
I completely agree!
But hiring a pentest firm is completely different than giving $50k a year to a guy, no questions asked.
The pentest firm is generally providing the whole package, from doing the actual pentest, with tools and workers of various experience and skill sets, giving you extended reports on what they did and the outcome, to providing guidance on how to fix their findings, how to make the necessary cultural changes to harden your apps, and also how to communicate that you have passed their audit.
You won't have all of that if you give free roam to a guy to _do what they do_.
This idea is more similar to patronage, which, imho, is a great idea, no matter the domain (arts or tech), but I doubt that there any company here that is willing to go this way.
Even the company that supposedly do actual patronage today are going to look at their ROI and stop as soon as they don't see the figures they're expecting.
Don't get me wrong, I'm not saying it's dumb to think about retaining a talented teenager on a contract.
> from bitter experience as a buyer rather than a seller of those services over the last 5 years --- "no game-over vulnerabilities" is a very common outcome!
Why bitter? Did they miss some?
Otherwise, isn't that the goal to begin with? Shouldn't you be proud instead?
Every pentest misses stuff. That's kind of the point I'm making. But yeah: as someone with a software security background, when you contract a test, you want them to find stuff!
They've already proved themselves as competent. $50k a year to a billion dollar company is nothing. Even if they find 0 vulnerabilities a year it's still worth it to them
I directionally agree with you but we could go another 20 comments deep on exactly what the purpose of an external pentest or red-team exercise is and how it might not match up perfectly with what an amateur web hacker is currently doing. But like: yeah, they could get into that business, at least until AI eats it.
So now they found a vulnerability, the company should pay them $50k a year until they retire because they proved themselves competent?
Yes?
There are a lot of ways to monetize a security researcher. Publishing research, even "we failed to perform a full exploit", is a huge recruitment tool and brand awareness tool.
It's not quite that simple. I don't think most bug bounty participants want a full-time job. But even more-so in my experience they are not security generalists. You can hire one person who is good at finding obscure XSS vulns, another that's good at exploiting cloud privilege escalation in IAM role definitions, another that's good at shell or archive exploits. If you look at profiles on H1 you'll see most good hackers specialize in specific types of findings.
I doubt it.
Just because he found one vulnerability at one vendor used by Discord doesn't mean he'll find all the vulnerabilities that exist at Discord or indeed any of them.
TFA:
>Discord is one of my favorite places to hunt for vulnerabilities since I'm very familiar with their API and platform. I'm at the top of their bug bounty leaderboard having reported nearly 100 vulnerabilities over the last few years. After you've gone through every feature at least 10 times, it gets boring.
That doesn't specify how many bugs there existed in the Discord codebase throughout the time where this person was active. Only once you know that, can you say whether they found a significant proportion relative to the effort they've spent and would spend as a part-time employee. That other people still find things also suggests that the statement above ("just hire him and you're secure") might have been a bit simplistic
Having been adjacent to this for years, it's because it's a cost center and not attached to the bonus of any product or program manager. Every now and then we'll get an advocate for security/integrity at a company but the effort lives and leaves with them.
Microsoft, after getting beat up over this for decades, is still horrible at it. In my area they're have been enforced regulations for years but they're written by the industry itself and infected with compliance managers and thus result in wastes of effort that makes compliance managers that came over from HR and legal happy with their eternal job security and minimal hard work.
Until some heavy handed top down regulation, written by people who understand the nature of ongoing security and software and embedded lifecycles, it's going to stay like this. Most existing supply chain regulation I've seen ends up saying "vet your vendors" and gives minimal practical guidance of how to actually do that. Likelihood of some really good law coming out of the current US administration and business climate is left as a comedy for the reader.
I feel like the "I'm a 16 year old high school senior" thing is some kind of social engineering- his knowledge seems a bit too broad.
But who knows.
There are plenty of competent 16 year olds.
I just read a story about a 13-year-old awarded a Ph. D at a prestigious university.
Human intelligence/aptitude has such extreme distributions it's almost unthinkable.
Who knows indeed.
It's easier than ever to pretend you know more than you do on the internet these days..
Not saying that's the case here, but that's the world we live in now.
I wonder if this analogy could work: if some random visitor pointed out your storage room's key is nearly broken and anybody could come in now and steal your store's stock. You'd be thankful, but would you hire them to come from time to time to check if they have any other insight ? Probably not ?
If you really saw a recurring security risk you'd have many other better use of your money.
Apple hired George Hotz (geohot) after he wrote the old 2010s iOS jailbreaks.
It wouldn't surprise me if he's in this thread - curious what his thoughts would be.
While I would love that for the kid I dont think these companies care about security at all.
I think that's unfair to say about a company that pays bug bounties at all.
A lot of other companies would have ignored the email for weeks or threatened legal action.
Its cheaper to pay bug bounties than to hire a security expert or legal costs
just wanted to disagree with anyone who thinks someone like this needs to go to school
no, he needs to make his own agency
[dead]
Their collaborator's report includes a more significant issue, an RCE on a mintlify server: https://kibty.town/blog/mintlify/
Nice discovery and writeup. Let alone for a 16 yo!.
I've never heard an XSS vulnerability described as a supply-chain attack before though, usually that one is reserved for package managers malicious scripts or companies putting backdoors in hardware.
I think you can view it as supply chain as the supply chain is about attacking resources used to infiltrate downstream (or is it upstream? I get which direction I should think this flows).
As an end user you can't really mitigate this as the attack happens in the supply chain (Mintlify) and by the time it gets to you it is basically opaque. It's like getting a signed malicious binary. It looks good to you and the trust model (the browser's origin model) seems to indicate all is fine (like the signing on the binary). But because earlier in the supply chain they made a mistake, you are now at risk. Its basically moving an XSS up a level into the "supply chain".
A supply chain attack attacks the supply chain
This makes use of a vulnerability in a dependency. If they had recommended, suggested, or pushed this purposefully vulnerable code to the dependency, then waited for a downstream (such as Discord) to pull the update and run the vulnerable code, then they would have completed a supply chain attack
The whole title is bait. Nobody would have heard of the dependency, so they don't even mention it, just call it "a supply chain" and drop four big other names that you have heard of to make it sexy. One of them was actually involved that I can tell from the post, that one is somewhat defensible. They might as well have written in the title that they've hacked the pentagon, if someone in there uses X and X had this vulnerable dependency, without X or the pentagon ever being contacted or involved or attacked
It does attack the supply chain. It attacks the provider of documentation. It's an attack on the documentation supply chain.
It would be like if you could provide a Windows Update link that went to Windows Update, but you could specify Windows Update to retrieve files from some other share that the malicious actor had control of. It's the same thing, except rather than it being a binary rather it is documentation.
I think that's misuse of the term as well, but like you said they are only 16.
Given this (including the linked writeup on the mintlify RCE), after the React RCE, if think it should be pretty obvious that
1. content security policies should always be used to prevent such scripts (here they would prevent execution of scripts from the SVG)
2. The JavaScript ecosystem should be making ` --disallow-code-generation-from-strings` a default recommendation when running NodeJS on the server.
Vercel (and other nodejs as a service providers) should warn customers that don't use CSP and `--disallow-code-generation-from-strings` that their settings should be improved.
There are a bunch of other NodeJS flags that maybe you should look into too: https://sgued.fr/blog/react-rce/#node-js-mitigations
Proxying from the "hot" domain (with user credentials) to a third party service is always going to be an awful idea. Why not just CNAME Mintlify to dev-docs.discord.com or something?
This is also why an `app.` or even better `tenant.` subdomain is always a good idea; it limits the blast radius of mistakes like this.
I run a product similar to Mintlify.
We've made different product decisions than them. We don't support this, nor do we request access to codebases for Git sync. Both are security issues waiting to happen, no matter how much customers want them.
The reason people want it, though, is for SEO: whether it's true or outdated voodoo, almost everyone believes having their documentation on a subdomain hurts the parent domain. Google says it's not true, SEO experts say it is.
I wish Mintlify the best here – it's stressful to let customers down like this.
What makes you say that Google claims it's not true? Google claims subdomains are completely two different domains and you'll lose all the linking/page rank stuff according to their own docs regarding SEO. Some SEO gurus claim it's not so black and white but no one knows for sure. The data does show having docs on subdomain is more harmful to your SEO if you get linked to then a lot.
Here's the argument for/against it: https://www.searchenginejournal.com/ranking-factors/subdomai...
I think the answer likely is quite nuanced, for what it's worth.
To my knowledge it's not as much hurting the parent domain as having two separate "worlds". Your docs which are likely to receive higher traffic will stop contributing any SEO juice to your main website.
Yep - this is the core issue that made the vulnerability so bad. And if you use a subdomain for a third-party service, make sure your main app auth cookies are scoped to host-only. Better yet, use a completely different domain like you would for user-generated content (e.g. discorddocs.com).
I think the reason companies do this for doc sites is so they can substitute your real credentials into code snippets with "YOUR_API_KEY". Seems like a poor tradeoff given the security downside.
decided to make a new account to post:
Mintlify security is the worse I have even encountered in a modern SaaS company.
They will leak your data, code, assets, etc. They will know they did this. You will tell them, they will acknowledge that they knew it happened, and didn't tell you.
Your docs site will go down, and you will need to page their engineers to tell them its down. This will be a surprise to them.
Yes, they were sloppy with GitHub credentials and their response was inadequate. Glad we migrated away from them.
where did you migrate away to?
Absolute self-promotion: https://github.com/hunvreus/reallysimpledocs
Astro’s starlight docs generator/template is quite nice as well: https://starlight.astro.build/
Interesting timing — we captured downstream exploitation of this exact attack surface.
Ok, I’m never opening an svg ever again.
Found by a 16 year old, what a legend.
Open it with a browser running inside a jail.
I tried that and they wouldn't let me bring my laptop in
https://man.freebsd.org/cgi/man.cgi?jail https://github.com/Zouuup/landrun
Alright, I chuckled.
Slightly related, as someone who doesn’t engage in this type of work, I’m curious about the potential risks associated with discovering, testing, and searching for security bugs. While it’s undoubtedly positive that this individual ultimately became a responsible person and disclosed the information, what if they hadn’t? Furthermore, on Discord’s side, what if they were unaware of this person and encountered someone attempting to snoop on this information, mistakenly believing them to be up to no good? Has there been cases where the risk involved wasn’t justified by the relatively low $4k reward? Or any specific companies you wouldn’t want to do this with because of a past incident with them?
If you engage in “white hat security research” on organisations who haven’t agreed to it (such as by offering roles of engagement on a site like hacker one) there is indeed a risk.
For example they might send the police to your door, who’ll tell you you’ve violated some 1980s computer security law.
I know 99.99% of cybercrime goes unpunished, but that’s because the attackers are hard to identify, and in distant foreign lands. As a white hat you’re identifiable and maybe in the same country, meaning it’s much easier to prosecute you.
> Furthermore, on Discord’s side, what if they were unaware of this person and encountered someone attempting to snoop on this information, mistakenly believing them to be up to no good?
Companies will create bug bounty programs where they set ground rules (like no social engineering), and have guides on how to identify yourself as an ethical hacker, for example:
https://discord.com/security
There are laws governing these scenarios. It's different everywhere. Portugal just updated theirs in favor of security researchers: https://www.bleepingcomputer.com/news/security/portugal-upda...
Not shocked given the following statement from Mintlify to a recruiter a few months ago:
"I'd rather hire a junior dev who knows the latest version of NextJS than a senior dev who is experienced with an earlier version."
This would be a forgivable remark, except the recruiter was aware of the shortsightedness, and likely attempted to coach the hiring manager...
You're much more charitable than I am. I would not call that forgivable.
It isn't, they have so much knowledge experience and foresight that has a significant gap in many ways.
Mintlify does look pretty, but between that and all the React exploits, I'll stick with good ol' static sites.
Kinda why I built ReallySimpleDocs [1]. Add Pages CMS [2] to it and you're set.
[1]: https://reallysimpledocs.com/
[2]: https://pagescms.org
The linked site https://heartbreak.ing/ explains that Mintlify disabled CORS, so that 3rd party sites can run code in your Mintlify-using environment (X, Vercel, etc).
The OP site says that .svg files can only run scripts if they are directly opened, not via <img> tags.
So how does the attack work?
My understanding, the SVGs were imported directly and embedded as code, not as a `src` for an img tag. This is very common, it's a subjectively better (albeit with good security practices) way to render SVGs as it provides the ability to adjust and style them via CSS as they are now just another element in the HTML DOM. It should only be done with "trusted" SVGs however!
As for CORS, they were uploading the SVGs to an account of their own, but then using the vulnerabilities to pivot to other accounts.
Thanks, that makes sense. Strange that the writeup skipped the most important step in the vulnerability!
A lesson from this is that you shouldn't host third-party stuff in your own domain. Instead of placing it on docs.discord.com, place it on discord-docs.com.
>AI-powered documentation platform. You write your documentation as markdown and Mintlify turns it into a beautiful documentation platform
Why do you need AI for this? Aren't there tons of packages which do very similar things without AI?
For that matter, why do you need SaaS for this? Aren't there tons of simple locally runnable solutions, including SSGs?
Well if they don't do SOMETHING with AI for their documentation how are they going to put it on their resumes?
$11k in bounties. Might have got more from the onion.
Stupid, especially because he is a kid and young in his career. His lifetime earnings and ability to score a better paying job is worth way more than an extra couple thousand dollars selling this kind of exploit to criminals. It's why NDA's for security vulnerabilities are harmful because it doesn't allow a kind of social credit accumulation
Back in the day the US government would give you $20k-60k cash in a nice briefcase for this type of exploit. Just another thing big tech has ruined I suppose.
Apple gave me $47k back when I was 16 and it definitely changed my life. Was subsequently able to get out of my 3rd world country and pay for university in the UK. While the quality of education is disappointing, having a graduate visa makes it so much easier to get a job or start a business there.
Can you cite a source for that claim? The USG paying mid-5-figures for an XSS vulnerability? That's news to me.
The book "This Is How They Tell Me the World Ends" by Nicole Perlroth, while it's about the history of cyberweapons it does a very good job detailing the late 90s to early 2010s exploit market.
I don't have it in front of me, but I'm talking about the "nobody but us" era of exploit markets:
https://en.wikipedia.org/wiki/NOBUS
Where the NSA seemingly was buying anything, even if not worthwhile, as a form of "munitions collection" to be used for the future attacks.
edit: this mostly ended in the US because other nations started paying more, add in more regulations (only a handful companies are allowed to sell these exploits internationally) and software companies starting to do basic security practices (along with ruling out their own bug bounties), it just mostly whimpered away.
Also relevant to the discussion, the book discusses how the public exploit markets are exploitive to the workers themselves (low payouts when state actors would pay more) and there are periods of times where there would be open revolts too (see 2009 "No More Free Bugs" movement, also discussed in the book).
Definitely worth it if you aren't aware of this history, I wasn't.
I haven't read her book, am myself somewhat read in to the background here, and if she's claiming NSA was stockpiling serverside web bugs, I do not believe her.
In reality, intelligence agencies today don't even really stockpile mobile platform RCE. The economics and logistics are counterintuitive. Most of the money is made on the "backend", in support/update costs, paid in tranches; CNE vendors have to work hard to keep up with the platforms even when their bugs aren't getting burned. We interviewed Mark Dowd about this last year for the SCW podcast.
Maybe there is a misunderstanding, I'm not saying that the NSA would be buying XSS scripts. I'm saying that if this was 35 years ago the NSA would be buying exploits with common user software. Back then the exploits were "lesser" but there still was a market and not every exploit that was bought was a wonder of software engineering. Nowadays the targeted market is the web and getting exploits on some of the most used sites would be worthy of buying.
Kid was simply born in the wrong era to cash out easy money.
I think you're wrong about this. 35 years ago was 1990. Nobody was selling vulnerabilities in 1990 at all. By 1995, I was belting out memory corruption RCEs (it was a lot easier then), and there was no market for them at all. And there has never been a market for web vulnerabilities like XSS.
Building reliable exploits is very difficult today, but the sums a reliable exploit on a mainstream mobile platform garner are also very high. Arguably, today is the best time to be doing that kind of work, if you have the talent.
I can't imagine intelligence agencies/DoD not doing this with their gargantuan black budgets, if it's relevant to a specific target. They already contract with private research centers to develop exploits, and it's not like they're gonna run short on cash
If that were the case, we'd routinely see mysterious XSS exploits on social networks. The underlying bugs are almost always difficult to target! And yet we do not.
The biggest problem, again, is that the vulnerabilities disappear instantaneously when the vendors learn about them; in fact, they disappear in epsilon time once the vulnerabilities are used, which is not how e.g. a mobile browser drive-by works.
They have a class of attacks which are used for targeted intrusion into foreign entities. Typically espionage or cyberwarfare, so they're not often used (they're aware they might be a one-use attack), but some persist for a long time. Foreign entities also tend not to admit to the attacks when found, so if the vendor is a US entity, often the vendor doesn't find out. We do the same; when our intelligence agencies find out about a US compromise, they often keep mum about it.
I'm not talking about XSS specifically, I mean in general. An XSS isn't usually high-value, but if it affects the right target, it can be very valuable. Imagine an XSS or CSRF vuln in a web interface for firmware for industrial controls used by an enemy state, or a corporation in that state. It might only take 2 or 3 vectors to get to that point and then you have remote control of critical infrastructure.
Oh - and the idea that a vendor will always patch a hole when they find it? Not completely true. I have seen very suspicious things going on at high value vendors (w/their products), and asked questions, and nobody did anything. In my experience, management/devs are often quite willing to ignore potential compromise just to keep focusing on the quarterly goals.
Are these things you think it stands to reason the IC must be doing, or things you know for a fact that they are doing? It stands to reason for a lot of people that the IC must stockpile vulnerabilities, but they don't (they keep just a couple working ones) --- just as an example of counterintuitive things about how CNE works.
It's partly fact, partly reasoning. One fact comes from STUXnet and Snowden Leaks, where they developed and deployed vulns that persisted for years without notice. The other fact is I've interviewed at the research centers and my eyes got pretty wide at the stuff they told me without an NDA, so they're definitely paying a lot to develop and acquire more vulns/new attacks. That was all 20 years ago, but the contracts are still there so there's no reason to suppose it stopped. There's also past NSA directors that've spoken at DEFCON for years about how they want more hackers, and the new cold war with China and Russia has been ongoing for nearly as long.
I'm not saying they stockpile vulns; I'm saying if somebody on the dark web said they had a vuln for sale for $50k, and it could help an agency penetrate China/Iran strategically, it would make no sense to turn it down, when they already pay many times more money to try to develop similar vulns.
You are here implicitly comparing Stuxnet and BULLRUN, two of the most sophisticated and expensive CNE operations ever conducted, with an XSS in Discord.
Why would YOU see a mystery XSS exploit on a social network? The idea of the DoD scoring these little exploits in a box is usually to deploy in a highly controlled and specific manner. You as a layperson is of no interest to them unless you are some kind of intelligence asset or foreign adversary
Wouldn't platforms see the supposed XSS payloads in their logs and publish analyses of them, or at the very least, announce that they happened?
Seems like none of these major websites detected anything, and they are supposed to be top-notch in the world.
It's only because the researcher contacted them.
Also because nobody actively exploited them! You're using the word "detected" to mean "discovered", which nobody working in the field would ever do.
detected: WAF caught or detected the attack and raised an alert, post-exploitation
discovered: they audited or pentested themself and found out, preemptively
I just mean that Coinbase didn’t see anything happening and didn’t take action though the boy successfully exploited the vulnerability on their live system.
No not to individuals. There are absolutely contracts you can score for certain attack surfaces but that usually involves going through a company. If this person is from the united states, they will absolutely land themselves a good scholarship and a very well-paid job with a security clearance.
$11k for the three of them in total! That's just bad PR.
at this point I feel like it'd be useful for web server default configurations to include something like
wouldn't that stop a browser from running scripts, even if the svg file is opened directly? having this be widespread would solve it wholesale.Not a bad idea!
I've been following the rise of SVG based attacks recently... It's not just hypothetical anymore... People are using SVG files to deliver full phishing pages and drive by downloads by hiding JavaScript in the markup
ALSO as someone who maintains a file upload pipeline I run every SVG through a sanitizer... Tools like DOMPurify remove scripts and enforce a safe subset of the spec... I even go as far as rasterizing user uploaded vectors to PNG when possible
HOWEVER the bigger issue is mental... Most folks treat SVG like a dumb image when browsers treat it like executable content... Until the platform changes that expectation there will always be an attack surface
This is a great example of why a Content-Security-Policy (CSP Header) should be considered mandatory for high risk sites. With it you can effectively tell the browser what JS is allowed to run, meaning that any JS injected via XSS won't work.
I suspect Coinbase and others already use CSP.
https://en.wikipedia.org/wiki/Content_Security_Policy
Cool. Makes me want to get into that — checking out sites for vulnerabilities. Very impressive for a 16 year old. Should definitely have been paid more.
I run an infosec firm and we have done attacks like this on my clients over and over and over in audits. I always say any bored teen could do most of what we do because most companies are moving too fast feature farming to have any time for responsible security hardening, and now I have yet another great citation.
Unfortunately a competitive rate agreed to in advance with a company before we do any pentesting is the only way we have ever been able to get paid fairly for this sort of work. Finding bugs in the wild as this researcher did often gets wildly underpaid relative to the potential impact of the bug, if they pay or take it seriously at all.
These companies should be ashamed paying out so little for this, and it is only a matter of time before they insult the wrong researcher who decides to pursue paths to maximum profit, or maximum damage, with a vuln like this.
> Unfortunately a competitive rate agreed to in advance with a company before we do any pentesting is the only way we have ever been able to get paid fairly for this sort of work.
So, rough estimate, how much would you have made for this?
We normally find things like this in our usual 60 hour audit blocks. Rates change over time with demand, but today an audit of that length would be $27k.
Even that is quite cheap compared to letting a blackhat find this.
If I can ask on business model, as I have a friend with a similar predicament — what percent of the time do you find vulnerabilities in those audits? Do companies push back if you don't find vulnerabilities?
We have never issued a clean report in our ~5 years of operation.
Some firms have a reputation for issuing clean reports that look good to bosses and customers, but we prefer working with clients that want an honest assessment of attack surface and how motivated blackhats will end their business.
We also stick around on retainer for firms that want security engineering consulting after audits to close the gaps we find and re-architect as needed. Unused retainer hours go into producing a lot of open source software to accelerate fixing the problems we see most often. This really incentivizes us to produce comprehensive reports that take into account how the software is developed and used in the real world.
Under our published threat model few companies pass level one, and we have helped a couple get close to level 2 with post audit consulting.
Our industry has a very long way to go as current industry standard practices are wildly dangerous and make life easy for blackhats.
https://distrust.co/threatmodel.html
As someone in a related line of work: we find vulnerabilities so close to 100% of the time that it might as well be 100% of the time. Whether they're practically exploitable or surpass your risk appetite is the real question.
These companies almost always produce "vulnerabilities", but they're also almost always trash.
"Finding: This dependency is vulnerable to CVE-X, update it, severity S". And then of course that dependency is only used during development, the vulnerable code isn't called, and they didn't bother to dig into that.
"Finding: Server allows TLS version 1.1, while it's recommended to only support version 1.2+", yeah, sure, I'm sure that if someone has broken TLS 1.1, they're coming for me, not for the banks, google, governments, apple, etc, everyone else still using TLS 1.1
... So yeah, all the audits will have "findings", they'll mostly be total garbage, and they'll charge you for it. If you're competent, you aren't going to get an RCE or XSS out of a security audit since it simply will not be there.
At Distrust we do not comment on specific dependency CVEs unless they are likely exploitable, or there are a lot of them pointing at bigger problems in the overall approach to dependency management.
That said, a policy of blindly updating dependencies to patch irrelevant CVEs is itself, a very real security vulnerability, because pulling in millions of lines of code no one reviews from the internet regularly makes you an easy target for supply chain attacks.
We have pulled off supply chain attacks on our clients a few times who were not otherwise convinced they were a real threat.
It’s clear to me now that I need to set up my home machine the way I set up BYOD when I was contracting last. I need a separate account for all of my development.
I have a friend who at one point had five monitors and 2 computers (actually it might be 3) on his desk and maybe he’s the one doing it right. He keeps his personal stuff and his programming/work stuff completely separate.
I have three OS installs. Windows install for games. Another Windows for development (I have to for windows dev). And a Ubuntu install for anything not games/work. The windows drives use bitlocker and they can't access each other's files. It's not perfect.
Although with the amount of crap I have to install for windows development I'm starting to wonder if a base VM image that is used as a start point for each project would be cleaner.
I set up a separate user that I ssh into for development. Not perfect but its something.
I really don't get the appeal to have everything om one top-level domain, especially completely separate or even external services. The scope of this would've been basically zero if they just put it on docs.discord.com.
Especially something like this, where they were reverse proxying a SaaS, seems extra stupid. It's more work to set up, adds an unnecessary dependency between services and you end up paying for all the internet traffic three times (even if not directly).
Sounds like you pwned Mintlify!
I critiqued the title elsewhere already so let me say here that the screenshot does show code running in Discord's browser context. They didn't send it to an employee and actually pwn the company, as one might understand from the title, but it doesn't strictly say that and I would count finding XSS as close enough. Saying they've pwned Discord, I think is fair enough
The other three companies mentioned though... yeah, they totally pwned the dependency first and foremost
I struggle to understand the issue .. could someone help me out ?
Ok, you got "https://discord.com/_mintlify/_static/hackerone-a00f3c6c/lma..." to send a controlled payload
But regular users will never hit "https://discord.com/_mintlify/_static/hackerone-a00f3c6c/lma...", so they will never execute your script
I fail to understand how this can be exploited, by whom and in what conditions
You're pretty much on the money. Reflected XSS requires social engineering to really target anyone without other primitives. Unfortunately this report is not very clear about the tangible impacts or limitations of what they could do with this particular XSS either. Saying that every Mintlify customer was "vulnerable to account takeover with a single malicious link" strikes me as specious to say the least. Still, can't fault kids for getting excited about recognition and a payout.
imo, the impact is pretty clear here. an unsuspecting user clicks (or is redirected) to one of these malicious links on the platform (ex. vercel); the script grabs their cookie and credentials and sends it to the attacker. they now have full access to the victim's account.
Nice! So the Cookie is accessible by JavaScript on all of those sites? That would be pretty surprising given the prevalence of HttpOnly, so that doesn't seem clear to me at all. And they're all using Cookie-based auth, you think? You're a bug bounty hunter so I'll defer to your wisdom, but doesn't it seem more likely that an account takeover would be possible via a state-changing request from the user's existing session? Let's say they can abuse it to reset the user's password. Nice, that's an account takeover... for every user not using MFA. But then there are anti-CSRF mitigations. Okay, not insurmountable with an XSS, but implemented differently everywhere. And what if the auth domains are separate to the domain on which the XSS is triggered? Man this seems to get less clear by the minute. Please clear this up for me.
XSS is a RCE exploit. It allows you to run any action as if you were the owner of the account. How is that not a full account takeover?
XSS is categorically not an RCE and my point is that mitigations exist which make "It allows you to run any action as if you were the owner of the account" an unwarranted assumption. The writeup shows that it's possible to pop an alert box. That doesn't tell you anything about what's actually possible. Obviously Discord got enough information to take it seriously, but extrapolating that to suggest every third-party using Mintlify is vulnerable to account takeover is highly dubious based on what's presented.
How is XSS not remote code execution? You can do anything, from send fetch requests to the server with full credentials to loggging keystrokes or even open a tunnel and eval payloads...
Anything the user can do, you can do via an XSS attack.
Show me where you can "open a tunnel" using the XSS in this post.
> Anything the user can do, you can do via an XSS attack.
I just explained why this isn't a reasonable assumption. You seem to have multiple fundamental misunderstandings about web application security so I don't think it's constructive for either of us to continue this conversation.
> Show me where you can "open a tunnel" using the XSS in this post.
> You seem to have multiple fundamental misunderstandings about web application securityLol yeah sure buddy
Go to Discord and paste that into your console. None of us will hold it against you if you come back and delete these comments once you learn about Content Security Policy.
> Go to Discord and paste that into your console.
The same Discord that configures things so that any time you open the console it greets you with a giant message warning you not to paste anything into the console?
Maybe you should read up on what CSP can and can't do. Once an attacker can execute arbitrary code, they can do anything the client can.
Generally code execution within browser/client-side javascript sandbox is just "XSS".
RCE usually implies server-side code execution (or breaking out of browser sandbox).
Hmm, I've always thought of "RCE" in a more general way, regarding the ability to execute arbitrary code on a computer you don't own. For example some multiplayer games have had exploits that let hosts run arbitrary code on clients that connect to them, and I've seen that called an RCE vulnerability. shrugs
If it’s running code outside of a normal browser sandbox then, yes it’s a RCE. Because it can now access to nearly everything on the user’s computer, including their browser, email, etc.
XSS is limited to accessing just that one website.
Well, llmslave2 is right. If discord.com executes javascript to conduct user actions, and you can execute javascript on discord.com, you are acting on the account as if you were discord.com
Except discord.com doesn't execute JavaScript, the user's browser does. These are meaningful distinctions that delineate the impact. You aren't "discord.com" if you target someone with an XSS exploit, you've only run a script in a user's session. Whether you can actually do anything with that script or not decides whether you can take over the account or not.
Everybody knows that XSS is a client side exploit, you're acting naive by pretending like we're claiming it gives access to a server and ignoring the fact that having control of the client gives you de facto control of whatever account is logged into the client.
It is not as cool as the RPC exploit of React/Next.js where you could call any function on the server-side including “vm.sysexec” or whatever it was, but still not to be fully ignored
Yes, I agree, it’s a cool discovery though
Yes, it's generally a "full account takeover" for a given discord user.
But RCE usually means ability to run any code on the web server, and would generally get you access to _everything_ including full direct access to the database. All accounts and all data, not just a few accounts.
the impact varied by customer. in Discord's case, the auth token is stored in local storage and their docs is hosted on the primary domain; they were susceptible to a full account takeover. X's docs are on a different subdomain but we found a CSRF attack that could facilitate a full account takeover. most companies were significantly affected in one way or another.
Interesting. I agree with the other commenter about the post should've included how an account takeover was possible.
You mention one method being a cookie sent to an attacker-controlled domain, but that in itself is a vulnerability given it being incorrectly scoped (missing HTTPOnly & SameSite atleast).
> the auth token is stored in local storage
Has anyone reported this (rhetorical question)? What in the world could be the justification for this?
In my opinion, any full account takeovers due to XSS is a vulnerability, even ignoring XSS. Changing email/password/phone should require verification back to one of those methods. Or at least input of the previous password.
And to my earlier point, none of that is in the writeup here to support the enormous claims made in framing the finding. This is good work, and congratulations on the bounty. I hope you have a long career in security ahead. Obviously you communicated your findings to Discord clearly enough for them to understand the impact. I look forward to reading more research from you all in the future and I hope the technical details will accompany it.
You could send that link to an unsuspecting user and steal their cookies, make API requests to send messages on their behalf, etc
Apparently one of the other linked posts shows how you can also gain RCE, since the docs are statically pre-rendered and there’s no sandboxing to prevent you from evalling arbitrary JavaScript.
> Apparently one of the other linked posts shows how you can also gain RCE
Yep, here it is: https://kibty.town/blog/mintlify/
Also linked in his guide (which I missed) and [here in a separate HN post](https://news.ycombinator.com/item?id=46317546). I think this other author's post is a lot more detailed and arguably more useful to folks reading on HN.
It's hosted on the official domain. That means you have at least 2 options: a) chain in with another issue which allows to load that as a trusted resource, or b) scam people by directing them to an "official" post. Also you get discord cookies access.
You have control over what displays on a page with a discord.com domain, you could manipulate the dom to have a login or something else and have it pass the data to your servers. A user would just see a link from discord.com
Yeah, this one must be socially engineered-- but a (fake) login page when accessing a docs site would fool most people.
Thankfully the browser prevents sending the cookies cross origin or else this is just a single click exploit.
Edit: I gave too much credit to Discord here. They aren't protecting their tokens correctly.
You can also just be logged-in on Discord web, so everything is accessible too
if you click on the link because it has discord.com in the domain the script in the SVG can (maybe) get your session data. Not actually sure if that’s true though, I suppose it depends on how the cookies are scoped
fascinating! but this is not a supply-chain attack unless i'm misunderstanding
It kinda is no? Discord uses mintlyfly. Minitlifly was vulnerable. And because they got access to mintlifly, discord was now also attackable
That's how language shifts. Supply chain attacks are broadly seen as a scary new thing, so like with any such term, people try to shoehorn things they find into its meaning. Those who fall for and repeat it shift the language. The same happened to the word 0day: it used to mean "a vulnerability that you specifically haven't had a chance to patch because it has been known to the world for 0 days". A scary thing. Now it's commonly used as synonym for the word vulnerability
I wonder if every vulnerability is soon called a supply chain attack:
- Microsoft releases a Windows security update -> Discord uses Windows -> supply chain attack on Discord
- User didn't install security updates for a while -> brought their phone to work -> phone with microphone sits in pocket in meeting room -> supply chain attack
Everything has dependencies that can be vulnerable, that doesn't mean "the supply chain" was attacked in a targeted effort by some attacker
that’s just a vulnerability in a dependency. a supply-chain attack is introducing malicious code in a dependency
Btw, apart from Discord, you really should stop using the other ones (X, Vercel, Cursor...). Do yourself and the planet a favour :)
Stop using Discord as well - their software is packed full of data mining, ads, and cosmetic upsells. For public community groups use a forum site (then it’s indexable as well!), and for private groups use something actually private like Signal
Okay, seriously, can we just get one, just ONE document/image spec that doesn't let you embed scripts or remote content? What is with this constant need to put the same exactly vulnerability into EVERYTHING?! Just let me have a spec for completely static documents, jfc!
It is clear that SVG should not support scripts and CSS in SVG files. Those who need them can simply create HTML with inline SVG tags and scripts. And SVG should contain only shapes, effects and transformations.
Or maybe we need a new image format, "SVG without scripts and CSS".
CSS and scripts are wildly different. It's like responding to the old MS Office attacks with "Word without macros or font selection"
The problem with CSS is that if you want to write an SVG viewer, you have to implement a whole CSS engine, which might be more complex than SVG renderer itself. And if you create an image in an editor, like Inkscape, you don't use CSS anyway. CSS is meant to be used when you write the code manually (instead of using an editor), for example, in a web app, and in this case you could use HTML as well.
So yes, CSS is not needed.
Move fast and break things?
I have this feeling with almost all web tools I am required to use nowadays.
No trust.
Move fast and break _other people's things._
One of these days I'm gonna have to learn why cross-site scripting even matters, especially with modern browsers restricting a script's access to anything local
The attacker can do anything using your session.
The "Hello world" examples always show using it to steal your cookies, which obviously doesn't work now when nearly every site uses the "httpOnly" flag which makes the cookie inaccessible to JavaScript, but really, stealing your session isn't necessary. They just have to make the XSS payload run the necessary JavaScript.
Once the JavaScript is running on the page, all bets are off. They can do ANYTHING that the page can do, because now they can make HTTP requests on your behalf. SOP no longer applies. CSRF no longer protects you. The attacker has full control of your account, and all the requests will appear to come from YOUR browser.
If I can run my own code but in your context, I can pull in malicious scripts.
With those (all these are "possible" but not always, as usual, it depends, and random off the top of my head):
- I can redirect you to sites I control where I may be able to capture your login credentials.
- May be able to prompt and get you to download malware or virus payloads and run them locally.
- Can deface the site you are on, either leading to reputational harm for that brand, or leading you to think you're doing one thing when you're actually doing another.
- I may be able to exfiltrate your cookies and auth tokens for that site and potentially act as you.
- I might be able to pivot to other connected sites that use that site's authentication.
- I can prompt, as the site, for escalated access, and you may grant it because you trust that site, thereby potentially gaining access to your machine (it's not that the browsers fully restrict local access, they just require permission).
- Other social engineering attacks, trying to trick you into doing something that grants me more access, information, etc.
It's a good question and one mature orgs ask themselves all the time. As you can see from most of the replies here, XSS captures the fancy of the bug bounty crowd because there are tonnes of hypothetical impacts so everyone is free to let their imagination run wild when arguing with triagers. It's also the exploit nonpareil for nerdsnipers because sanitisation is always changing and people get to spend their days coming up with increasingly ridiculous payloads to bypass them. In reality, find me one active threat actor who has compromised a business lately with an XSS. It's not an irrelevant risk, but the attention it gets is wildly disproportionate to its real-world impact.
You log in to goodsite.com
goodsite.com loads a script from user-generated-content-size.com/evil.js
evil.js reads and writes all your goodsite.com account data.
Damn, this is a good era to be in high school (or university) with a lot of free time. $4000 is a pretty good haul for a few hours of work poking at stuff.
They have more security incidents than you'd expect for a documentation company. There was another one just last month.
The collected bounty on this should have been so much higher than $14K :/
Everything is Swiss cheese. Let's just go back to paper and pen and one time pads.
> If you didn't know, you can embed JavaScript into an SVG file.
Oh yikes. I did not know.
Who ever invented the idea that you can embed Javasript to picture files?
16 year olds rule the world.
this was very well-written and the moving parts were quite easy to understand.
simultaneously there are many opportunities throughout to harden one's app to avoid similar exploits.
Really nice finding for such a young folk - really liked reading into it.Also what i love most about it is what an actually simple vuln it is.
Tho what i find mostly funny bout it is how many people are complaining about the 4k$.
I mean sure the potential "damage" could have been alot higher, tho at the same time there was no contract in place or , at least as far as i understood, a clear bug bounty targeted. This was a, even if well done, random checking of XHR/Requests to see if anything vulnerable can be found - searching for kinda file exposure / xss / RFI/LFI. So everything paid (and especially since this is a mintlify bug not an actual discord bug) is just a nice net gain.
Also ill just drop here : ask yourself, are you searching for such vulns just for money or to make the net a safer place for everyone. Sure getting some bucks for the work is nice, but i personally just hope stuff gets fixed on report.
- enormously awesome
- that bug bounty was insufficient (Fidelity?!?!)
every commit in every open source project should now go through an AI to see if it can detect anything nefarious. I'm sure there are ways to fool it but it makes it a lot easier for bad actors to get caught.
Link here is to gist , but on lobste.rs some one posted link to Eva's blog. And it with links to friends blogs, feel so much like old internet. I dont even know what I enjoyed more, reading technical side or discovering this dark forest.
could `Sec-Fetch-Dest: image` mitigate this?
[dead]
Cool bug. Bug bounty money is pathetic.
I was going to ask. Isn't 4k from Discord pretty low for the work conducted here? I'm not familiar with bounty payouts. I'm hoping these companies aren't taking advantage of them.
4k is sadly discords highest bounty they give out (screenshot from their bugcrowd program: https://imgur.com/a/KNIdeXh) even more critical issues then this one get paid the same amount out
What is the reason for the low values? I would understand if it was a small company, but we are talking about Discord here.
Supply and demand. Selling via grey markets is an option, but many white hats don't go that route due to risk. There's plenty of people that will also find vulnerabilities without any money attached.
That's a limited view. The damage this could cause should be accounted for. People don't have to sell shit, they could fuck things up just for the fun of it. That's something to consider, especially with a bunch of teenagers. Now, these big corpos didn't take the chance to sponsor and encourage these kids early careers and make this fuck-up good PR, at least.
That's not how economics works. I can't do my job without a computer or glasses but that doesn't mean I can pay the suppliers of these things most of my salary each. Preventing a 100k€ problem says almost nothing about what the payout should be. As for them just causing chaos for fun, that nets them just about nothing (what's an evening of fun worth, like what are you willing to pay for a cinema ticket?). This is certainly more (hundreds of times more) and so covers that risk as well
In an ideal world, these bugs, especially low-hanging fruits, shouldn't be discoverable by some random kids. These billion dollar companies should have their own security researchers constantly monitoring their stack. But those costs are cut, because the law de facto doesn't hold them liable for getting hacked. It's a very good deal for companies to pay bug bounties, but they mostly cheap out on that, too.
It's like a finders reward elsewhere in life. If you lost your wallet, your immaterial and material loss is quite high, but apart from cash the contents are of way less value for a finder/thief. These type of rewards are meant to manipulate emotions and motivation. Twitter paid these kids each between $1 and $20. That's insulting. As I said elsewhere, bug bounties are PR. And it's bad PR in this case. Black market pricing is the absolute low end for valuation (it's basically the cash value in the wallet example).
> these bugs, especially low-hanging fruits, shouldn't be discoverable by some random kids. These billion dollar companies should have their own security researchers [...]
I'm twice this kid's age and have been doing this hobby-turned-work as long as they have. I can tell you the work we do is no different. It doesn't matter if you're 16 or 64 or what your credentials are or salary is. We're all just hackers. Hacker ethos is judging by skill, not appearance. Welcome to hacker news :P
https://en.wikipedia.org/wiki/Hacker_ethic#The_hacker_ethics item #4
> Twitter paid these kids each between $1 and $20.
The submission doesn't say they've even contacted Xitter. I thought it was in the title just to drop names that we've heard of that used this dependency. Did you legit find somewhere that they got ≤20$ for an exploitable XSS on the x.com or twitter.com domains? That is definitely a strangely low amount but then I'm not surprised by anything where Elon is involved. It could also have been a silent fix without even replying to the reporter; I've had that often enough. But yeah from X I would expect a few hundred dollars at least and from old twitter (or another legit business) more than that (as Discord demonstrated)
Get off your high horse. In this instance it's been a kid, and it does not concern some highly arcane flaw in a crypto library or chained kernel exploit, which may have passed even a pro. I already implied this bug should have been found by in-house security, so obviously it's within the domain of professionals and teenagers alike.
> The submission doesn't say they've even contacted Xitter.
This one doesn't. This one does: https://heartbreak.ing/. Or at least, I presume they meant Twitter when they wrote "one company valued 44 billion".
> Get off your high horse
What did I say that made you reply this way?
Not sure what risk but for me it would be morals
I've rarely gotten bug bounty money and not even always a written thank-you but it doesn't cross my mind to somehow seek out a malicious actor that wants to make use of what I found. Leave the place better than you found it and all that
What "grey market" are you talking about? How specific can you be about it?
I know you love asking people this question, so sorry to spoil your fun, but you know just as well as I do that there isn't really a "grey market".
There absolutely is. I'm just not familiar with one that buys these vulnerabilities.
> Selling via grey markets is an option, but many white hats don't go that route due to risk.
I would think that such a sale makes one inherently not "white hat".
Supply and demand I guess.
Pathetic for a senior SE but pretty awesome for a 16 year old up and coming hacker.
You are right, but that could (probably not) make them go for the bad route because they would get way more money that way. 4k for a bug that could take control of your customer account sounds disrespectful to me.
Yeah, my read is that the teenage hacker confronted with this ridiculous payslip sees two ways forward: accept the pay cut for the CV benefit of working with bug bounties, or get a bit better at hiding your ass and make them really pay.
If I were 16, I’d be thinking I just made an obscene amount of money ($4,000!) messing with computers for fun, and got to meet people at a famous company.
That’s a free car. Free computer. Uber eats for months.
And my status with my peers as a hacker would be cemented.
I get that bounty amounts are low vs SE salary, but that’s not at all how my 16yo self would see it.
When I was sixteen I was already familiar with the concept of leverage. I’m not sure if I’d have had the cajones to use it though.
Playing devils advocate but 4k is probably more money than most kids that age have seen in their life
I hope I'm not assuming too much but I'm really hope the up and coming hacker is smart enough to know that his work was worth more than $4,000. That's 1-2% of an annual SE salary for someone with similar skillset.
> That's 1-2% of an annual SE salary for someone with similar skillset.
I agree $4,000 is way too low, but a $400k salary is really high, especially for security work.
> That's 1-2% of an annual SE salary for someone with similar skillset.
So commensurate for approximately 2 days of work, a little high for two hours of work, and a little low for 8 days of work.
And this will help them land that six figure job
I mean, as a hiring manager, a fresh grad with multiple bug bounties tells me a lot about their drive and skill, so I'd agree. It's a great differentiator.
market value is the same regardless, so this was pathetic
What do you expect? a16z-funded and they love to talk about how much they've raised, thought-leader style co-founders, etc.
JFC bug bounty money is pathetic now. This would have destroyed this company's reputation, downstream effects for customer reputations and data.