According to the pci dss auditor I had when doing a pci das level 1 audit. The most common credit card leak vector is logging middlewares logging credit card nunbers

When I did application security I had to argue with developers about PCI and PII data in logs all the time. They would insist that there was "no other way" and that it was secure inside our system. I'd refuse to change the status of the vuln to anything other than critical. I found many similar vulns in our database that had been marked as false positives or non-critical by other infosec people in the company. The common thread was none of them had a background in software development so they just trusted what the developer told them. This seems to happen frequently in places where there's a culture of compliance being more important than actual security.

Can confirm, have broken GDPR before through logging customer (and customer's customer) PII. It lasted for about a month before we realised and I had to go through the logs 1 by 1 over 3 days to remove all the data.

unless you are Facebook and tightly collaborating with police and intelligence in countries with no respect for human rights

hmm.. that's a very sympathetic take.

Most frameworks blot out passwords from logs by default, so even a newbie programmer on their first day doesn't make the mistake of logging plaintext passwords, yet facebook somehow made that mistake...

It should raise eyebrows when the security practices of SWEs at a billion dollar company are outperformed by any newbie developer working a toy project.

Passwords are just data. If said data is not tagged in a way that makes it clear it is a password, finding an algorithm that will successfully blot out passwords in the general case is intractable without being far too aggressive to be useful.

All such tools rely on assumptions about what will be logged following certain rules that the logging can check against - it's not hard to accidentally convert data to a format that when logged happens to fail these kinds of tests.

They should have caught it. But it's not surprising that it occasionally happens.

Not that hard [1]:

    Rails.application.config.filter_parameters += [
      :passw, :email, :secret, :token, :_key, :crypt, :salt, :certificate, :otp, 
    :ssn, :cvv, :cvc
    ]

[1] https://github.com/rails/rails/blob/8a2e28d7451d5ae4cb194fcc...

Assuming, of course, that the data is logged as a parameter rather than as a raw string, or as an instance variable in another object, or any number of other ways. Developers thinking it is "not that hard" is a big red flag to me, suggesting odds are high your logs are full of things that should not be there. Using filters is a first step only.

HN does it, if I post my password it will automatically change it to stars, see: *************

hunter2

correct-horse-battery-staple

Hmm… Not sure if it worked?

I think it’s actually much easier to make such mistakes at large companies with sprawling codebases and potential for settings that inadvertently end up logging sensitive data. Especially for nobody to notice either.

True but they're also better resourced in terms of humans (and their experience) and tooling that should prevent or at least catch any blunders quickly.

You’d be surprised, but from my first hand FAANG experience that is definitely not the case. Tooling can capture things that are known to it - but not everything is setup perfectly.

> It should raise eyebrows when the security practices of SWEs at a billion dollar company are outperformed by any newbie developer working a toy project.

Facebook isn’t “a billion dollar” company it’s “a 1,435 billion dollar” company.

Excuses start to run thin.