scipro/owasp.xml
Andreas Svanberg 6bdd5c63ea
All checks were successful
Build and test / build-and-test (push) Successful in 16m22s
Suppress warning about CVE-2024-49203 (#71)
https://nvd.nist.gov/vuln/detail/CVE-2024-49203
https://github.com/querydsl/querydsl/issues/3757

Basically if you allow untrusted user input to be used in the "ORDER BY" clause you can be vulnerable to SQL injection.

I believe this is nonsense and akin to saying every Java application has a security vulnerability because JDBC allows you to execute arbitrary SQL if you do not properly use PreparedStatement with parameters over a string-concatenated Statement.

Even if this is considered a valid vulnerability we do not, currently, allow untrusted user input to be used in the "ORDER BY" clause.

Fixes #45

Reviewed-on: https://gitea.dsv.su.se/DMC/scipro/pulls/71
Reviewed-by: Tom Zhao <tom.zhao@dsv.su.se>
Co-authored-by: Andreas Svanberg <andreass@dsv.su.se>
Co-committed-by: Andreas Svanberg <andreass@dsv.su.se>
2025-01-09 12:54:43 +01:00

94 lines
3.4 KiB
XML

<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd">
<!-- -->
<suppress>
<notes>Wicket includes jQuery 1, 2, and 3 but only 3 is used</notes>
<packageUrl regex="true">^pkg:javascript/jquery@(1|2)\..*$</packageUrl>
<cve>CVE-2015-9251</cve>
<cve>CVE-2019-11358</cve>
<cve>CVE-2020-11022</cve>
<cve>CVE-2020-11023</cve>
</suppress>
<suppress>
<notes><![CDATA[
The vulnerability appears to be for iText 7 while SciPro uses 2.
None of the referenced classes appear in version 2.
file name: itext-2.1.7.js9.jar
]]></notes>
<packageUrl regex="true">^pkg:maven/com\.lowagie/itext@.*$</packageUrl>
<vulnerabilityName>CVE-2021-43113</vulnerabilityName>
</suppress>
<suppress>
<notes><![CDATA[
This exploit is for an Amazon patched version of log4j that we do not use.
file name: log4j-core-2.18.0.jar
]]></notes>
<packageUrl regex="true">^pkg:maven/org\.apache\.logging\.log4j/log4j\-.*@.*$</packageUrl>
<cve>CVE-2022-33915</cve>
</suppress>
<suppress>
<notes><![CDATA[
False positive from some Python library.
file name: querydsl-core-5.0.0.jar
]]></notes>
<cve>CVE-2022-31548</cve>
</suppress>
<suppress>
<notes>No usages of com.google.common.io.Files#createTempDir</notes>
<cve>CVE-2020-8908</cve>
</suppress>
<suppress>
<notes>
This is when trying to serialize recursive datastructures,
such as a list containing itself or similar.
Since an attacker can only craft strings that are *de*-serialized it
is impossible to use this "exploit" and it is only something we can
do to ourselves.
The same problem exists with Map#hashCode for example and everyone
is fine with that.
</notes>
<cve>CVE-2023-35116</cve>
</suppress>
<suppress>
<notes>
This is a complete nonsense vulnerability. Some automated tool has
gone completely bananas.
</notes>
<cve>CVE-2024-22949</cve>
</suppress>
<suppress>
<notes>
This is a complete nonsense vulnerability. Some automated tool has
gone completely bananas.
</notes>
<cve>CVE-2023-52070</cve>
</suppress>
<suppress>
<notes>
This is a complete nonsense vulnerability. Some automated tool has
gone completely bananas.
</notes>
<cve>CVE-2024-23076</cve>
</suppress>
<suppress>
<notes>
https://nvd.nist.gov/vuln/detail/CVE-2024-49203
https://github.com/querydsl/querydsl/issues/3757
Basically if you allow untrusted user input to be used in the "ORDER BY" clause
you can be vulnerable to SQL injection.
I believe this is nonsense and akin to saying every Java application has a
security vulnerability because JDBC allows you to execute arbitrary SQL if you
do not properly use PreparedStatement with parameters over a string-concatenated
Statement.
Even if this is considered a valid vulnerability we do not, currently, allow
untrusted user input to be used in the "ORDER BY" clause.
</notes>
<cve>CVE-2024-49203</cve>
</suppress>
</suppressions>