Also look for the CodeQL bundle at the custom GitHub AE endpoint. - #393
chrisgavin merged 3 commits into
Conversation
Sorry, something went wrong.
| // We also don't want to send an authorization header if there's already a token provided in the URL. | ||
| if ( | ||
| codeqlURL.startsWith(`${apiDetails.url}/`) && | ||
| parsedQueryString["token"] === undefined |
There was a problem hiding this comment.
Should we be concerned about the security of sending the token as part of the query string? The url will be encrypted, but there is a possibility that the token will be logged and secret scanning may or may not find it.
It's low risk, but would it be better to remove the token from the query string and add it as an authorization header?
Sorry, something went wrong.
There was a problem hiding this comment.
I don't think we get control over how authentication to the assets server is done, so unless we can change what the server accepts we're probably stuck with sending the token in the URL.
Given that the token only grants access to the CodeQL bundle, which is already publicly available on GitHub.com I think the risk of someone obtaining it is pretty minimal.
Sorry, something went wrong.
There was a problem hiding this comment.
I'm fine with that.
Sorry, something went wrong.
aeisenberg
left a comment
There was a problem hiding this comment.
Looks reasonable to me.
Sorry, something went wrong.
This updates the CodeQL bundle finding logic to work on GitHub AE, where we always have to use a custom endpoint to get the CodeQL bundle rather than going to the repository directly.
Merge / deployment checklist