5 ms·

Isn’t this a bit hasty. Backblaze fixed thr issue immediately, wrote a detailed blog posted and it was also found to have only been in a single webpage of their

Isn’t this a bit hasty. Backblaze fixed thr issue immediately, wrote a detailed blog posted and it was also found to have only been in a single webpage of theirs. https://www.backblaze.com/blog/privacy-update-third-party-tracking/ https://www.backblaze.com/blog/privacy-update-third-party-tr... Now while I certainly agree that I don’t like this info leaked, there was no mal-intent and they quickly took action once notified. I feel like their action is what makes me like them so much.

dannyw 6y ago
Yes and no. This issue was perhaps X lines of code away from accidentally transferring the contents of your files (or login email and password!) to Facebook, or a malicious attacker. For one, this highlights they don't have automated tests detecting arbitrary/malicious JS injection on their web app. This is a serious security risk: we are talking about your cloud filesystem here, and "spear phish / bribe your marketing intern to adding malicious.js" is a real attack vector. Alarms should be going off internally whenever a new external JS file gets included in your webapp, either ststically or dynamically. Facebook pixel today, a malicious hacker tomorrow. I'd expect a private cloud to have better security procedures than "wait till someone on Twitter discovers a bug". (Personally, I will continue to use Backblaze, but just highlighting why it's a serious security concern.)
- jscheel 6y ago
  You should not be backing up plaintext passwords to offsite storage anywhere. Or do you mean malicious JS capturing your form entry at login?
  - dannyw 6y ago
    That's what I mean. But the specific issue I see is that a piece of external JS got inserted into their web app, and their security team didn't realise it. The fact that its from GTM is no excuse: give me Google tag manager, I'll exfil your users data in an hour ;)
    - jscheel 6y ago
      Ahh, fair enough. They definitely snippets to be vetted by their security team. I'm sure they've learned from this mistake though, and I'm not sure I would trust anyone else any more than them.
      - magicalhippo 6y ago
        It would be far better if they described how they managed to let Google Tag Manager be included for so long, and how they've changed their deployment process to avoid third-party scripts from being included in the future.
    - deleted 6y ago
      [deleted]
- brightball 6y ago
  Out of curiosity, do you have a recommendation of a tool / structure for an automated test to catch that type of injection? This is something I haven’t considered in my own pipeline that I’d like to address.
  - kilburn 6y ago
    For external files in particular you can use Content Security Policies [1] in the server configuration. Injecting third-party content then requires editing both your site and the server setup. Of course, you can make the policies more or less strict depending on how much you want to tighten this kind of attack vector. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
- peteretep 6y ago
  > This issue was perhaps X lines of code away from This is a weird metric.
  - dylan604 6y ago
    It's really bad, and might as well be X lines of code away from Bacon
  - spzb 6y ago
    Yep. Logically any piece of code is X lines away from any other for sufficiently large values of X.
robin_reala 6y ago
They haven’t yet explained the series of events that lead to GTM being included on non-marketing pages. That’s the main worry.
jscheel 6y ago
I too have been really shocked at how nasty our community has been regarding this issue.
- andrewzah 6y ago
  I don't think sending info about filenames and sizes is acceptable, ever. It's a shame as backblaze has been a solid backup choice for a while. edit: and enabling facebook tracking on customer pages...
  - dewey 6y ago
    That was not a deliberate action though, that's just the default behavior of the analytics snippet that someone included on the page. If there's humans involved there will always be bugs, the question is how well you deal with them and react. I think they did a good job once it was pointed out.
- stanmancan 6y ago
  Everyone gets mad when there’s a breach or a bug that doesn’t get full disclosure. When a company provides full disclosure people are shocked and abandon the platform. Every company has bugs. Everyone eventually gets breached. If a company is honest with what happened, follows up with their users, and fixes it, what more can you ask for? Should it have happened? No. Did they find the issue? Yes. Did they fix it? Yes. Did they disclose it? Yes. Perfect, thanks.
- tertius 6y ago
  Because corporation didn't deliver on promises. Trust was broken and their attempts at fixing said trust is meaningless given what they've already done to break said trust.
  - anamexis 6y ago
    Why is their attempts at fixing trust meaningless?
  - mkr-hn 6y ago

dannyw 6y ago

Yes and no. This issue was perhaps X lines of code away from accidentally transferring the contents of your files (or login email and password!) to Facebook, or a malicious attacker. For one, this highlights they don't have automated tests detecting arbitrary/malicious JS injection on their web app. This is a serious security risk: we are talking about your cloud filesystem here, and "spear phish / bribe your marketing intern to adding malicious.js" is a real attack vector. Alarms should be going off internally whenever a new external JS file gets included in your webapp, either ststically or dynamically. Facebook pixel today, a malicious hacker tomorrow. I'd expect a private cloud to have better security procedures than "wait till someone on Twitter discovers a bug". (Personally, I will continue to use Backblaze, but just highlighting why it's a serious security concern.)

jscheel 6y ago
You should not be backing up plaintext passwords to offsite storage anywhere. Or do you mean malicious JS capturing your form entry at login?
- dannyw 6y ago
  That's what I mean. But the specific issue I see is that a piece of external JS got inserted into their web app, and their security team didn't realise it. The fact that its from GTM is no excuse: give me Google tag manager, I'll exfil your users data in an hour ;)
  - jscheel 6y ago
    Ahh, fair enough. They definitely snippets to be vetted by their security team. I'm sure they've learned from this mistake though, and I'm not sure I would trust anyone else any more than them.
    - magicalhippo 6y ago
      It would be far better if they described how they managed to let Google Tag Manager be included for so long, and how they've changed their deployment process to avoid third-party scripts from being included in the future.
  - deleted 6y ago
    [deleted]
brightball 6y ago
Out of curiosity, do you have a recommendation of a tool / structure for an automated test to catch that type of injection? This is something I haven’t considered in my own pipeline that I’d like to address.
- kilburn 6y ago
  For external files in particular you can use Content Security Policies [1] in the server configuration. Injecting third-party content then requires editing both your site and the server setup. Of course, you can make the policies more or less strict depending on how much you want to tighten this kind of attack vector. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
peteretep 6y ago
> This issue was perhaps X lines of code away from This is a weird metric.
- dylan604 6y ago
  It's really bad, and might as well be X lines of code away from Bacon
- spzb 6y ago
  Yep. Logically any piece of code is X lines away from any other for sufficiently large values of X.

robin_reala 6y ago

They haven’t yet explained the series of events that lead to GTM being included on non-marketing pages. That’s the main worry.

jscheel 6y ago

I too have been really shocked at how nasty our community has been regarding this issue.

andrewzah 6y ago
I don't think sending info about filenames and sizes is acceptable, ever. It's a shame as backblaze has been a solid backup choice for a while. edit: and enabling facebook tracking on customer pages...
- dewey 6y ago
  That was not a deliberate action though, that's just the default behavior of the analytics snippet that someone included on the page. If there's humans involved there will always be bugs, the question is how well you deal with them and react. I think they did a good job once it was pointed out.
stanmancan 6y ago
Everyone gets mad when there’s a breach or a bug that doesn’t get full disclosure. When a company provides full disclosure people are shocked and abandon the platform. Every company has bugs. Everyone eventually gets breached. If a company is honest with what happened, follows up with their users, and fixes it, what more can you ask for? Should it have happened? No. Did they find the issue? Yes. Did they fix it? Yes. Did they disclose it? Yes. Perfect, thanks.
tertius 6y ago
Because corporation didn't deliver on promises. Trust was broken and their attempts at fixing said trust is meaningless given what they've already done to break said trust.
- anamexis 6y ago
  Why is their attempts at fixing trust meaningless?
- mkr-hn 6y ago