We're meant to give credit to a service that fixed an XSS vulnerability in an hour, and that is indeed a better-than-market turnaround time for an XSS bugfix.
But consider an alternative perspective: this is a company that was offering users "encrypted" file transfer mediated by clientside browser Javascript, in which there is only dubious, marginal cryptographic separation between customers and the service itself, which could just as easily serve targeted customers surreptitious DOM updates to override their claimed security capabilities.
But that fundamental problem didn't matter, because the service didn't even sanitize basic, obvious user data, and was exposed to a trivial XSS.
First thing I thought was "oh let them slide, when you think about big issues, you might slip on some sanitize code".
But then I thought, if you advertise something as "encrypted" and "secure" or more secure than competition, you should get at least basic pentest. It is not cheap to get one and a good one but that kind of XSS would be ruled out...
Aren't you professionally paid to fix these kinds of problems? You would be out of work if every developer and product manager put exhaustive pen testing on its to-do list prior to launch.
First to market is your bread and butter, tptacek.
It used to be; it isn't anymore. If you gave me the choice between giving up my company and ending browser Javascript cryptography, I'd have to think about it.
(disclaimer: I'm one of the creators of this very unnamed service)
The XSS-issue that was found by Tim was indeed a very fundamental problem which shouldn't have been in there. We are very happy he disclosed the information with us so we could fix it directly.
We hired a couple of professional hackers to audit our service but launched simultaneously. Biggest lesson for us: finish the audit first, launch afterwards :-)
I'm going to give your tech team the benefit of the doubt that it would have responded to information quickly if it had that information.
Lessons learned here: pay your pen testers quickly because their findings can affect the reputation of your company, don't launch without responding to audit results, don't bullshit people working in high tech industries about what was happening simultaneously, don't blame tech staff for business decisions
Hmm, how about no? "We launched an encrypted file transfer tool, but we forgot to sanitize input" is somewhat pathetic in 2019. What else has saferequest.net fucked up?
I showed the article to the company before publishing it, and it included many references and links to their website.
The contact explicitly stated he didn't like it to get published, as it might damage their product image on quick Google searches by someone researching it (even though I praised the company in the article).
Removing direct references was a nice middle ground they accepted.
Because their intent was to provide a secure service, as is proven by their quick turnaround time well outside work hours.
Despite the lapse, they score high in authenticity, and given their small size, they deserve a second chance. Megacorps probably wouldn't have my sympathy.
He gave a pretty big hint on how to find the company.
"On the 24th of October, an article was posted on Tweakers (a Dutch tech website) showing off a newly released service to securely request files from someone through the web."
But consider an alternative perspective: this is a company that was offering users "encrypted" file transfer mediated by clientside browser Javascript, in which there is only dubious, marginal cryptographic separation between customers and the service itself, which could just as easily serve targeted customers surreptitious DOM updates to override their claimed security capabilities.
But that fundamental problem didn't matter, because the service didn't even sanitize basic, obvious user data, and was exposed to a trivial XSS.