Skip to content

[Java]: CWE-321 - Query to detect hardcoded JWT secret keys #670

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
1 of 2 tasks
luchua-bc opened this issue May 4, 2022 · 10 comments
Closed
1 of 2 tasks

[Java]: CWE-321 - Query to detect hardcoded JWT secret keys #670

luchua-bc opened this issue May 4, 2022 · 10 comments
Labels
All For One Submissions to the All for One, One for All bounty

Comments

@luchua-bc
Copy link

luchua-bc commented May 4, 2022 •
edited
Loading

Query PR

github/codeql#9036

Language

Java

CVE(s) ID list

CVE-2022-24860

CWE

CWE-321: Use of Hard-coded Cryptographic Key

Report

  1. What is the vulnerability?
    JWT (JSON Web Token) is an open standard (RFC 7519) that defines a way to provide information within a JSON object between two parties. JWT is widely used for sharing security information between two parties in web applications. Each JWT contains encoded JSON objects, including a set of claims. JWTs are signed using a cryptographic algorithm to ensure that the claims cannot be altered after the token is issued. The most basic mistake is using hardcoded secrets for JWT generation/verification.

  2. How does the vulnerability work?
    When JWT secret keys are hardcoded, they will be leaked if the source code (and JWT secret in it) is publicly exposed or leaked. This allows an attacker to forge a valid token then use it in authentication or authorization, which leads to authentication bypass or privilege escalation.

  3. What strategy do you use in your query to find the vulnerability?
    Auth0 implementation of JWT is the de facto library used in Java applications. This query detects insecure usage of hardcoded JWT secret keys in both signing and verification.

  4. How have you reduced the number of false positives?
    By modelling the source and sink carefully, number of false positives are reduced.

  5. Other information?
    Please refer to test cases and the sample program for more information.

Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc).

  • Yes
  • No

Blog post link

No response
@luchua-bc luchua-bc added the All For One Submissions to the All for One, One for All bounty label May 4, 2022
@luchua-bc
Copy link
Author

For validating this issue, please use the database file at https://github.com/luchua-bc/files/blob/master/databasir_vul.zip.

This database was created from the vulnerable 1.0.1 version. There is no source code change to the original version and several changes were made to create the database successfully. These changes are:

  • Use Java SDK 11 to compile
  • Add missing snakeyaml-1.28-android.jar to maven repository
  • Remove all @Slf4j annotations since relevant code uses lombok.extern.slf4j.Slf4j that prevents Java classes to be included in the database
  • Added a program core/src/main/java/com/databasir/core/infrastructure/jwt/JwtTokensNew.java, which is exactly the newer version with the issue fixed

Please let me know if you need more information. Thanks.

@ghsecuritylab
Copy link
Collaborator

Your submission is now in status Test run.

For information, the evaluation workflow is the following:
Initial triage > Test run > Results analysis > Query review > Final decision > Pay > Closed

@ghsecuritylab
Copy link
Collaborator

Your submission is now in status Results analysis.

For information, the evaluation workflow is the following:
Initial triage > Test run > Results analysis > Query review > Final decision > Pay > Closed

@ghsecuritylab
Copy link
Collaborator

Your submission is now in status Query review.

For information, the evaluation workflow is the following:
Initial triage > Test run > Results analysis > Query review > Final decision > Pay > Closed

@ghsecuritylab
Copy link
Collaborator

Your submission is now in status Final decision.

For information, the evaluation workflow is the following:
Initial triage > Test run > Results analysis > Query review > Final decision > Pay > Closed

@ghsecuritylab
Copy link
Collaborator

Your submission is now in status Pay.

For information, the evaluation workflow is the following:
Initial triage > Test run > Results analysis > Query review > Final decision > Pay > Closed

@xcorail
Copy link
Contributor

xcorail commented May 13, 2022

Created Hackerone report 1567588 for bounty 390471 : [670] [Java]: CWE-321 - Query to detect hardcoded JWT secret keys

@xcorail xcorail closed this as completed May 13, 2022
@ghsecuritylab
Copy link
Collaborator

Your submission is now in status Closed.

For information, the evaluation workflow is the following:
Initial triage > Test run > Results analysis > Query review > Final decision > Pay > Closed

1 similar comment
@ghsecuritylab
Copy link
Collaborator

Your submission is now in status Closed.

For information, the evaluation workflow is the following:
Initial triage > Test run > Results analysis > Query review > Final decision > Pay > Closed

@luchua-bc
Copy link
Author

Thank @xcorail a lot for the quick turnaround and the bounty:-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
All For One Submissions to the All for One, One for All bounty
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@xcorail @luchua-bc @ghsecuritylab