The newer global node IDs (which can be forced via the 'X-Github-Next-Global-ID' header [1]) have a prefix indicating the "type" of object delimited by an underscore, then a base64 encoded msgpack payload. For most objects it contains just a version (starting at 0) followed by the numeric "databaseId" field, but some are more complex.
For example, my GitHub user [2] has the node ID "U_kgDOAAhEkg". Users are "U_" and then the remaining data decodes to: [0, 541842] which matches the numeric ID for my user accepted by the REST API [3].
You shouldn't rely on any of this implementation of course, instead just directly query the "databaseId" field from the GraphQL API where you need interoperability. And in the other direction the REST API returns the "node_id" field for the GraphQL API.
For folks who finds this interesting, you might also like [4] which details GitHub's ETag implementation for the REST API.
CodeQL is based on an existing product from a company called Semmle which GitHub acquired in late 2019 [1]
They have been part of GitHub for barely a year so it's not too surprising, especially given they are continuing to support the product for the enterprise customers they had previously not just GitHub.
If anyone is interested in even more data than Artem released, I did a similar experiment based off Artem's work except with a couple hundred domains and with TLS certificates for every one a few years ago: https://bitfl1p.com/
Why does this comment appear on every bug bounty HN thread? Straight from the horse's mouth [0]:
The black market is very unlikely to be a place you could sell a bug in a specific
website or service. It is not “worth millions”. Please stop repeating this.
What a cute strawman (and completely incorrect strawman from the wrong horse at that, this is Trumpist drivel from the guy who runs the actual bug bounty who of course has some acute rationalizations for underpaying for some of the most intricate technical work in the industry).
Nobody said it was "worth millions" but I have second-degree connections in Scandinavia that would pay 10x, like I said ($100,000).
@collingreene doesn't sound too familiar with these rather-illicit organizations, he strikes me as a product manager type person with a loud voice, not someone who actually has found and sold zero-days before. Maybe he doesn't have the technical acumen to do so, but hey, I'm not one to judge.
It's hard to establish proof that the market value on the black market is, in fact, much higher given that it is the black market (you're not going to find these people on Medium); However, one public example of this is the leaked Stuxnet details showing similarly high 5-digit prices for zero-days.
This isn't a specific bug either (it wasn't "oh, the log files for that one UberEATS micro-service were visible"), this flaw allows you to intercept the emails of pretty much any single one of SendGrid's clients. Imagine the damage someone could do with that, had it gotten into the wrong hands. Only $10k, what an insult.
EDIT: Upon further examination, it turns out that said author also contradicts himself and corroborates my own argument:
Technically they did employ some DNS validation. You had to setup a MX record to point to SendGrid before you could add the domain to your account. The problem was in order to send emails from a domain you had to add the same MX record. If you never setup the receiving end as well (on SendGrid) you were vulnerable to a takeover from another SendGrid account.
I do not believe the author circulated this report to multiple companies, however once it was made public a number of other reporters in the community did and continued to iterate on it until SendGrid fixed the issues.
But that's not what happened here at all. Bitbucket has responded explaining why this (self-inflicted) bug exists (a security decision in an underlying framework) and deferred to the framework maintainers for further discussion because they have the best context on why that decision was initially made and under what scenarios it might be changed.
They chose to use a framework without understanding the implications of its security issues. When one comes up, they tell their users it's someone else's problem. Maybe they're an impoverished company that can't afford to pay to solve the problem. Or they dont care much.
I think you're misunderstanding the attack scenario here:
> Anyway, if the browser is connecting via port 80, the MITM can just use a transparent http->https proxy to rewrite the referrer, and forward the request to the https server, so you've already lost.
That wouldn't actually work since the user's active session cookie has the "Secure" flag set (i.e. isn't sent over HTTP). Sure if the user logged-in again on the HTTP page you could exploit this with a transparent proxy but there's very little outside of implementing HPKP that BitBucket could do to prevent that attack.
But even shutting down access to port 80 on the server wouldn't be enough: the attacker only needs the victim to send the request, it doesn't need for the plaintext request to actually reach the server
(did you mean HSTS instead of HPKP, btw? The scenario I described didn't involve MITM of a HTTPS connection, and thus HPKP wouldn't be strictly needed )
also, I agree that the condition under which this check might be useful are quite convoluted... since Security is often in tension with Usability there is a case to be made for less defense-in-depth, and removing (potentially?) redundant checks... but I think we should be wary of making simplistic arguments for it, due to how delicate web app security is
Agreed; killing port 80 just decreases the chances the browser makes subsequent port 80 requests.
I still think the referrer is only helping paper over a deeper design flaw (using cookies to carry post state) at the expense of getting some users to trade privacy for availability, and decreasing performance/opening up attacks for people that install extensions as a workaround.
I'm not a member of the Facebook security team, but I work in the industry and your comment frustrates me. I can understand criticizing companies for poor security decisions if they are legitimately bad decisions, but I don't think that's the case here...
Let's imagine, for the sake of argument, that all those numbers in the URL are predictable and 100% the security relies on the "oh" and "oe" parameters. Taking a rather naive approach both of these appear to be exclusively hex strings. Therefor "oh" is 16 bytes and "oe" is 4 bytes making the total 8*(16+4) = 160 bits
In other words, assuming both parameters are truly random, an attacker would have to try (worst-case) this many combinations to view a victim's image:
2,135,987,035,920,910,082,395,021,706,169,552,114,602,704,522,356,652,769,947,041,607,822,219,725,780,640,550,022,962,086,936,576
For example, my GitHub user [2] has the node ID "U_kgDOAAhEkg". Users are "U_" and then the remaining data decodes to: [0, 541842] which matches the numeric ID for my user accepted by the REST API [3].
You shouldn't rely on any of this implementation of course, instead just directly query the "databaseId" field from the GraphQL API where you need interoperability. And in the other direction the REST API returns the "node_id" field for the GraphQL API.
For folks who finds this interesting, you might also like [4] which details GitHub's ETag implementation for the REST API.
[1] https://docs.github.com/en/graphql/guides/migrating-graphql-... [2] https://api.github.com/user/541842 [3] https://gchq.github.io/CyberChef/#recipe=Find_/_Replace(%7B'... [4] https://github.com/bored-engineer/github-conditional-http-tr...