3 ms·
It's fairly standard for network clients to assume potential malicious control of the server they are connecting to. It helps reduce the blast radius of a comp
by DanielDent 8y ago
It's fairly standard for network clients to assume potential malicious control of the server they are connecting to.
It helps reduce the blast radius of a compromised server.
In the case where the server is operated by a third party (as is the case with the B2 API server), there can be many compliance implications if that third-party-operated server has access to an internal network.
We don't accept when SSH clients or web browsers have the ability to do things they shouldn't based on instructions sent by the server they connect to.
Why would we suddenly have lower expectations of our file storage API clients? (or any other network/HTTP clients for that matter)
- voltagex_ 8y agoAh, I see what you're getting at. It'd be better if the URL for get_upload_url (I think that's what the API was called) could be calculated client side. At the moment, you're probably still more at risk of downloading a malicious library from PyPi or npm but this is sure to turn up in a CTF at some point - even curl is technically vulnerable. Have you talked to anyone from Backblaze about this?
- DanielDent 8y agoYes, client-side URL calculation and/or a whitelist of acceptable URLs would be a significant improvement. Thankfully command-line curl won't follow redirects unless you pass it a special flag, though if you do need it to follow redirects, I'm not sure what the best way is to restrict the range of redirects that it will follow. This issue was part of a broader coordinated disclosure and was only published today. I've gotten in touch with B2 support & I'm hoping my support ticket will make it to the correct people.