This blows my mind. These programmers can implement quite complex contacts-financial-exchanges on top of a quite complex distributed system, but then fail to sanitize user input in their web interface. It makes no sense.
They're pretty different programming disciplines, though. For a company as a whole it's not really excusable, but I'm sure there are plenty of fintech or distributed systems programmers who aren't up on web attack vectors, just as there are lots of web people who're well aware of them but who know nothing about fintech.
This is like saying "It's impossible to perfectly secure a bike on a city steet" when it gets stolen because you forgot to engage the lock. I have fuzzers that would of likely found this pretty quickly.
I doubt that. What sort of fuzzer is going to create an Ethereum smart contract of a very specific type, insert JavaScript into the contract title, insert the contract into the Ethereum block chain, synthesise the correct URL (which doesn't contain any JavaScript) and then detect that data from the backend was emitted unescaped?
Someone else in this thread said, well, serves them right, they should have used CSP, and then someone else pointed out that doesn't work for inline scripts, and there was a reply of the form "only stupid people use inline scripts" although this is news to me, as nearly every website I see uses inline scripts of some form or another. This whole discussion looks like people in denial.
The problem here is that XSS is so easy to create. A jungle of half-broken workarounds, mitigations, static analysis tools, fuzzers etc doesn't change the basic truth that the web is a fundamentally unsound platform on which to do secure coding. Data and code bleed together far, far too easily - by design.
The reason is, the data after the hash was not escaped.
Perhaps a fuzzer would have caught that. But a good tool would make it hard to make such mistakes by default. A desktop app would not have suffered from such errors, by construction. The web is not a good tool.
>A desktop app would not have suffered from such errors, by construction. The web is not a good tool.
While you are correct it would not of suffered from this particular vulnerability, a improperly utilized malloc for example could have similar if not more disastrous effects and would be exploitable under the same threat model. Yet I wouldn't call it a bad tool, just a tool used by an inexperienced carpenter.