Thanks for the PR @boris-petrov!

Did you run using the existing Gradle Wrapper instead of gradle 7.1?

For this PR, can you also please be sure to add a test? See https://github.com/spring-io/nohttp/blob/0.0.8/nohttp-gradle/src/test/kotlin/io/spring/nohttp/gradle/NoHttpCheckstylePluginITest.kt#L53 and https://github.com/spring-io/nohttp/blob/0.0.8/nohttp-gradle/src/test/kotlin/io/spring/nohttp/gradle/NoHttpCheckstylePluginITest.kt#L175

Long live fairness. Thank you for your review and answer. @pwntester @xcorail @smowton .

Thank you for your reply. I understand what you mean. One embarrassing point is that some general open source software requires customized rules. Reference article: Castor and Hessian java deserialization vulnerabilities

Thanks for understanding, we are aware that rating the scope of the query by running it on LGTM is not perfect and may have both FPs and FNs that are not caused by the query being evaluated. However, it gives a good enough estimation of the scope in an objective way, which is much better and fair than subjectively rating it.

Hi @haby0, just reviewed the seclab score for this submission.

So I think it is high risk to evaluate from the severity of the vulnerability and the number of users.

We agree with the severity (impact) assessment and we scored your submission accordingly in the highest range. However, we didn't find any data backing your second statement (number or users). A query run on 26K projects on LGTM returned a very low number of hits (12) and most of them were on 0-star projects (student or test projects). These libraries you added support for were featured in the popular Marshalsec research but the adoption of these libraries in OSS software is very low.

I hope this helps clarify the discrepancies. We encourage you to keep up with the great work!

Thank you for your reply. I understand what you mean. One embarrassing point is that some general open source software requires customized rules. Reference article: Castor and Hessian java deserialization vulnerabilities

Thank you!

Hi @haby0, just reviewed the seclab score for this submission.

So I think it is high risk to evaluate from the severity of the vulnerability and the number of users.

We agree with the severity (impact) assessment and we scored your submission accordingly in the highest range. However, we didn't find any data backing your second statement (number or users). A query run on 26K projects on LGTM returned a very low number of hits (12) and most of them were on 0-star projects (student or test projects). These libraries you added support for were featured in the popular Marshalsec research but the adoption of these libraries in OSS software is very low.

I hope this helps clarify the discrepancies. We encourage you to keep up with the great work!

Fixes #49

cc @rwinch

Not sure how to test this as any Gradle command that I run leads to:

No such property: COMPILE_CONFIGURATION_NAME for class: org.gradle.api.plugins.JavaPlugin

Any ideas?

As I said, and as written in the FAQ, other factors such as the quality of the code and documentation of the CodeQL query are also taken into account in the determination of the bounty award. I will ask in the team for other opinions and let you know.

thanks for the reply.

As I said, and as written in the FAQ, other factors such as the quality of the code and documentation of the CodeQL query are also taken into account in the determination of the bounty award. I will ask in the team for other opinions and let you know.

Hello @haby0

Because it can detect more deserialization vulnerabilities

The scoring of our program depends on various factors, not only how many vulns it can detect. See the FAQ about how we determine the rewards.

I also added more sinks to other PRs (no bounty application).

This is much appreciated, but this is not uncommon, as for other open source projects. Community members regularly propose query improvements or entire new queries without submitting through the bounty program.

I have read carefully about how to determine the bounty amount. In this pr deserialization vulnerability detection, some can be found in general software, such as: hessian, castor, etc. So I think it is high risk to evaluate from the severity of the vulnerability and the number of users.

thanks

Hello @haby0

Because it can detect more deserialization vulnerabilities

The scoring of our program depends on various factors, not only how many vulns it can detect. See the FAQ about how we determine the rewards.

I also added more sinks to other PRs (no bounty application).

This is much appreciated, but this is not uncommon, as for other open source projects. Community members regularly propose query improvements or entire new queries without submitting through the bounty program.

@xcorail thank you. For this PR, I want to apply for an increase in bounty awards. Because it can detect more deserialization vulnerabilities, including personal research results. In addition, I also added more sinks to other PRs (no bounty application).

Your submission is now in status Closed.

For information, the evaluation workflow is the following: SecLab review > Generate Query Results > FP Check > CodeQL review > SecLab finalize > Pay > Closed

Query

Link to pull request with your CodeQL query:

Relevant PR: https://github.com/github/codeql/pull/5842

CVE ID(s)

• No CVEs

Report

The main goal of my PR it to add support of pqxx connector. Right now there are only MyQSL and SQlite support. And it is based solely on function name. Pqxx sink is a bit more complex, because functions like "exec" may lead to high false positive rate.

I basically reused existing SqlTainted query, and created a custom SqlPqxxTainted query. I think that pqxx support should be implemented in Security.qll, but i seems not so simple to overwrite the logic behind SqlTainted query and it's Taint Configuration. That is why i decides to create separate query. I have also added example file SqlPqxxTainted.c and SqlPqxxTainted.qhelp which almost completely repeats SqlTainted.qhelp.

• [x] Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc). We would love to have you spread the word about the good work you are doing

Probably i would tell about my experience on upcoming conference on defense track about SAST.

Result(s)

Provide at least one useful result found by your query, on some revision of a real project.

• I dont have useful findings with this query.
• For example this injection on contributors list which comes from config file. Not sure it's an issue.
• Also i have send a PR to fix potential sqli with originates from reading fs path. But this one does not look risky too
• I think it's because currently CodeQL in unable to find more complex source types than described in Security.qll. But i am in process. It's not simple and fast, because vast majority of C++ projects are not easy to compile. As i said the main goal it to add support for pqxx connector. It actually successfully find that type of sink in open source projects i have tested. Also it helped me to find issues on my work by using predicate isSource(DataFlow::Node source) { any() } as Source and wide isAdditionalTaintStep:

  override predicate isAdditionalTaintStep(DataFlow::Node pred, DataFlow::Node succ) {
    exists(FunctionCall fc |
      fc.getAnArgument() = pred.asExpr() and
      fc.(Expr) = succ.asExpr()
    )
  }

Created Hackerone report 1241583 for bounty 313179 : [361] C++: Support Pqxx connector to search for sql injections to Postgres

Your submission is now in status Closed.

For information, the evaluation workflow is the following: SecLab review > Generate Query Results > FP Check > CodeQL review > SecLab finalize > Pay > Closed

Your submission is now in status Closed.

For information, the evaluation workflow is the following: SecLab review > Generate Query Results > FP Check > CodeQL review > SecLab finalize > Pay > Closed

Query

Link to pull request with your CodeQL query:

Relevant PR: https://github.com/github/codeql/pull/5957

CVE ID(s)

List the CVE ID(s) associated with this vulnerability. GitHub will automatically link CVE IDs to the GitHub Advisory Database.

• CVE-2016-2510

Report

Describe the vulnerability. Provide any information you think will help GitHub assess the impact your query has on the open source community.

BeanShell is a small, free, embeddable Java source interpreter with object scripting language features, written in Java. BeanShell dynamically executes standard Java syntax and extends it with common scripting conveniences such as loose types, commands, and method closures like those in Perl and JavaScript. At present, BeanShell is also used in the Spring framework.

If the code executed by BeanShell is controlled by the user, it will cause arbitrary code execution vulnerabilities.

• [X] Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc). We would love to have you spread the word about the good work you are doing

Result(s)

Provide at least one useful result found by your query, on some revision of a real project.

e-cology: Before the 9.0 version of the Fanwei e-cology OA collaborative business system, there is a BeanShell injection vulnerability, which can cause arbitrary user code execution. this is an exploit tool.

CNVD-2021-30167: UFIDA NC BeanShell remote code execution vulnerability

Created Hackerone report 1241574 for bounty 313170 : [376] [Java] BeanShell Injection

Query

Link to pull request with your CodeQL query:

Relevant PR: https://github.com/github/codeql/pull/5881

CVE ID(s)

List the CVE ID(s) associated with this vulnerability. GitHub will automatically link CVE IDs to the GitHub Advisory Database.

Report

Describe the vulnerability. Provide any information you think will help GitHub assess the impact your query has on the open source community.

• [x] Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc). We would love to have you spread the word about the good work you are doing

Result(s)

Provide at least one useful result found by your query, on some revision of a real project.

Created Hackerone report 1241575 for bounty 313171 : [367] [Java]: CWE-502 Add UnsafeDeserialization sinks

Your submission is now in status Closed.

For information, the evaluation workflow is the following: SecLab review > Generate Query Results > FP Check > CodeQL review > SecLab finalize > Pay > Closed

Your submission is now in status Closed.

For information, the evaluation workflow is the following: SecLab review > Generate Query Results > FP Check > CodeQL review > SecLab finalize > Pay > Closed

Query

Link to pull request with your CodeQL query:

Relevant PR: https://github.com/github/codeql-go/pull/529

Report

The HttpOnly flag directs compatible browsers to prevent client-side script from accessing cookies. Including the HttpOnly flag in the Set-Cookie HTTP response header helps mitigate the risk associated with Cross-Site Scripting (XSS) where an attacker's script code might attempt to read the contents of a cookie and exfiltrate information obtained. When set, browsers that support the flag will not reveal the contents of the cookie to a third party via client-side script executed via XSS.

• [ ] Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc). We would love to have you spread the word about the good work you are doing

Created Hackerone report 1241576 for bounty 313172 : [348] [GO] CWE-1004: Sensitive cookie without HttpOnly

Created Hackerone report 1241577 for bounty 313173 : [354] [JavaScript]: CWE-1004: Sensitive cookie without HttpOnly

Query

Link to pull request with your CodeQL query:

Relevant PR: https://github.com/github/codeql/pull/5785

Report

The HttpOnly flag directs compatible browsers to prevent client-side script from accessing cookies. Including the HttpOnly flag in the Set-Cookie HTTP response header helps mitigate the risk associated with Cross-Site Scripting (XSS) where an attacker's script code might attempt to read the contents of a cookie and exfiltrate information obtained. When set, browsers that support the flag will not reveal the contents of the cookie to a third party via client-side script executed via XSS

• [ ] Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc). We would love to have you spread the word about the good work you are doing