6 ms·

> I want to make one point clear: I believe that EtherDelta, in concept, is safer and more “trustworthy” than a traditional exchange. Everything about how Ether

by jdp23 9y ago

> I want to make one point clear: I believe that EtherDelta, in concept, is safer and more “trustworthy” than a traditional exchange. Everything about how EtherDelta functions is transparent and verifiable by users.... The attack detailed in this piece could have been identified by anyone before it was exploited, and if there had been a security review protocol in place, it would have been easily prevented. Even "in concept", releasing fintech software without doing the security basics verges on professional misconduct.

imaginenore 9y ago
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.
- vosper 9y ago
  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.
- mike_hearn 9y ago
  Well, from my blog post three days ago, discussed here: https://news.ycombinator.com/item?id=15321015 https://news.ycombinator.com/item?id=15321015 "I put it to you that it’s impossible to write secure web apps."
  - KekDemaga 9y ago
    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.
    - mike_hearn 9y ago
      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.
      - KekDemaga 9y ago
        I misunderstood the design then. I assumed the XSS was done via an input on the page not an input in Ethereum itself.
        mike_hearn 9y ago
        The article was updated. Apparently there were two different XSS at the same time. One is the exploit I describe above: data taken from the block chain was not escaped properly. Another is a more "traditional" XSS. It was possible to format a URL such that it contained script tags that were injected into the page. https://github.com/etherdelta/etherdelta.github.io/issues/143 https://github.com/etherdelta/etherdelta.github.io/issues/14... 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.
        KekDemaga 9y ago
        >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.
deleted 9y ago
[deleted]

by jdp23 9y ago

imaginenore 9y ago

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.

vosper 9y ago
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.
mike_hearn 9y ago
Well, from my blog post three days ago, discussed here: https://news.ycombinator.com/item?id=15321015 https://news.ycombinator.com/item?id=15321015 "I put it to you that it’s impossible to write secure web apps."
- KekDemaga 9y ago
  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.
  - mike_hearn 9y ago
    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.
    - KekDemaga 9y ago
      I misunderstood the design then. I assumed the XSS was done via an input on the page not an input in Ethereum itself.
      - mike_hearn 9y ago
        The article was updated. Apparently there were two different XSS at the same time. One is the exploit I describe above: data taken from the block chain was not escaped properly. Another is a more "traditional" XSS. It was possible to format a URL such that it contained script tags that were injected into the page. https://github.com/etherdelta/etherdelta.github.io/issues/143 https://github.com/etherdelta/etherdelta.github.io/issues/14... 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.
        KekDemaga 9y ago
        >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.

deleted 9y ago

[deleted]