Added GitLab OAuth Detector#4729
Added GitLab OAuth Detector#4729shahzadhaider1 wants to merge 3 commits intotrufflesecurity:mainfrom
Conversation
|
|
||
| for clientId := range uniqueIdMatches { | ||
| for clientSecret := range uniqueSecretMatches { | ||
| for _, endpoint := range s.Endpoints() { |
There was a problem hiding this comment.
I think we should keep the endpoints loop at the top level.
There was a problem hiding this comment.
Any specific reason why? I just followed the pattern in the existing GitLab detectors
There was a problem hiding this comment.
It doesn't change anything but I have to agree it would feel more natural 😀
There was a problem hiding this comment.
In that case, I'd prefer to keep consistency with existing GitLab detectors. What do you guys think?
| // | ||
| // Note: Apps with `api` scope may return 422, which we treat as unverified (not verified or invalid) | ||
| // to avoid false positives. | ||
| switch res.StatusCode { |
There was a problem hiding this comment.
No 200 OK or success code handling?
There was a problem hiding this comment.
This API never returns 200, even for valid credentials, and I also couldn't find an official documentation where all the possible status codes are listed for this API, so I went with what I experienced during testing. Feel free to let me know if you think we need to add 200 for additional safety
What Claude said: "You're using grant_type=client_credentials, which GitLab doesn't support for OAuth apps. So even with valid credentials, you'll never get 200 — only 400 with invalid_scope."
b1daae3 to
48f063b
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
ee28670 to
eb1df56
Compare
eb1df56 to
11d3127
Compare
| s1.SetVerificationError(verificationErr, clientSecret) | ||
|
|
||
| if s1.Verified { | ||
| // if secret is verified with one endpoint, break the loop to continue to next secret |
There was a problem hiding this comment.
If one client_id + secret combination is verified with one endpoint, is it possible it can be verified with another secret? If not, we should skip that pair fully and move to next client_id.
There was a problem hiding this comment.
Usually client_id + secret combinations are unique and if we found the verified one, we should not try to match same client_id with remaining secrets.
…r and use available ctx in tests
…against one client id
03e1d44 to
7001aca
Compare
Adds a new detector for GitLab OAuth application credentials (
client_id+client_secret).Credential Format
gloas-prefix followed by 64 hex charactersExample:
Additional Notes
EndpointCustomizerhttps://gitlab.comChecklist:
make test-community)?make lintthis requires golangci-lint)?Note
Medium Risk
Introduces a new detector with network-based verification logic and a protobuf enum change, which can affect scan behavior/performance and downstream consumers relying on detector type IDs.
Overview
Adds a new
gitlaboauth2detector that identifies GitLab OAuth application credentials by pairing a context-prefixed 64-hexclient_idwith agloas-64-hexclient_secret, and optionally verifies them via a POST to/<endpoint>/oauth/token(with custom/self-hosted endpoints supported).Registers the detector in
defaultsand adds a new protobuf enum valueDetectorType_GitLabOauth2plus unit/integration tests and benchmarks covering matching behavior and verification error handling.Written by Cursor Bugbot for commit 7001aca. This will update automatically on new commits. Configure here.