Comment by Aissen | Hacker News Reader

Comment by Aissen | Hacker News Reader

Parent Full thread

    After checking the contents of the file to send the report, I was surprised.
    Surprisingly, clearly sensitive information such as GITHUB_REPO_API_KEY and WORKERS_KV_API_TOKEN was displayed. I couldn’t understand what happened for a moment, and when I checked the command log, I found that I accidentally put a link to /proc/self/environ instead of /proc/self/maps.
    […]
    It seems that GitHub notified Cloudflare immediately because GITHUB_REPO_API_KEY (API key of GitHub) was included in the repository, and Cloudflare started incident response immediately after the notification.

    […]

    April 6, 2021 20:30 cdnjs processed the file
    At the same time    GitHub sent an alert to Cloudflare
    At the same time    Cloudflare started an incident response
    Within minutes      Cloudflare finished revocation of credentials
    April 6, 2021 20:40 I sent an initial report

This a nice Github feature. Also kudos to Cloudflare for quickly reacting to this.

> This a nice Github feature.

Indeed. See https://docs.github.com/en/code-security/secret-security/abo... for more details on how it works.

Is there a reason github can’t just have a setting to prevent you from pushing secrets in the first place? Is it really that processing heavy?

You might have strings that match one of their secrets regex's that are not an actual secret. It would be extremely annoying if they blocked you from pushing a commit in that case.

But they have the secrets, can't they check that it's the actual secret ?

Github doesn't check if the secrets are real or not. Any string that matches one of the regexs gets shared with the appropriate API provider. The provider checks to see if the its a valid credential or not and revokes the key if necessary.

From the security side, thaaat sounds like a can of worms.

It's more to avoid false positives. I've had bug bounty hunters flag secrets in my projects before looking for a bounty, but in actuality it was some random string in a variable named AWS_ACCESS_KEY etc that we used in a unit test (which mocked out the SDK but still expected the config values to exist at init)

I assume they could. Meanwhile, I’ve used the git-secrets tool

I'm wondering if this couldn't be used as a way to confirm or search for secrets: push huge files with many "secrets", if it's rejected, then you know it has a valid one, then rince and repeat with a binary search to find the one.

Pretty sure it just checks against a pattern, doesn't actually check validity

Nice, but I was thinking ahead, for a real check that would block the commit, but using the actual secrets.

I doubt ppl would want to give github all their actual secrets

Reply on news.ycombinator.com