5.1.1 - Example
SCA results
**# npm audit report**
**braces** <3.0.3
Severity: **high**
**Uncontrolled resource consumption in braces** - https://github.com/advisories/GHSA-grv7-fg5c-xmjg
**fix available** via `npm audit fix --force`
Will install nodemon@3.1.4, which is a breaking change
node_modules/micromatch/node_modules/braces
node_modules/nodemon/node_modules/braces
**chokidar** 1.3.0 - 2.1.8
Depends on vulnerable versions of **anymatch**
Depends on vulnerable versions of **braces**
Depends on vulnerable versions of **readdirp**
node_modules/nodemon/node_modules/chokidar
**nodemon** 1.3.5 - 2.0.16 || 2.0.18
Depends on vulnerable versions of **chokidar**
Depends on vulnerable versions of **update-notifier**
node_modules/nodemon
**micromatch** *
Depends on vulnerable versions of **braces**
node_modules/micromatch
**anymatch** 1.2.0 - 2.0.0
Depends on vulnerable versions of **micromatch**
node_modules/nodemon/node_modules/anymatch
**readdirp** 2.2.0 - 2.2.1
Depends on vulnerable versions of **micromatch**
node_modules/nodemon/node_modules/readdirp
**got** <11.8.5
Severity: **moderate**
**Got allows a redirect to a UNIX socket** - https://github.com/advisories/GHSA-pfrx-2q88-qq97
**fix available** via `npm audit fix --force`
Will install nodemon@3.1.4, which is a breaking change
node_modules/got
**package-json** <=6.5.0
Depends on vulnerable versions of **got**
node_modules/package-json
**latest-version** 0.2.0 - 5.1.0
Depends on vulnerable versions of **package-json**
node_modules/latest-version
**update-notifier** 0.2.0 - 5.1.0
Depends on vulnerable versions of **latest-version**
node_modules/update-notifier
**jsonwebtoken** <=8.5.1
Severity: **high**
**jsonwebtoken vulnerable to signature validation bypass due to insecure default algorithm in jwt.verify()** - https://github.com/advisories/GHSA-qwph-4952-7xr6
**jsonwebtoken unrestricted key type could lead to legacy keys usage** - https://github.com/advisories/GHSA-8cf7-32gw-wr33
**jsonwebtoken's insecure implementation of key retrieval function could lead to Forgeable Public/Private Tokens from RSA to HMAC** - https://github.com/advisories/GHSA-hjrf-2m68-5959
**fix available** via `npm audit fix --force`
Will install jsonwebtoken@9.0.2, which is a breaking change
node_modules/jsonwebtoken
**11** vulnerabilities (6 **moderate**, 5 **high**)
Semgrep results
┌─────────────────┐
│ 3 Code Findings │
└─────────────────┘
helpers/JWTHelper.js
- javascript.jsonwebtoken.security.audit.jwt-exposed-data.jwt-exposed-data
The object is passed strictly to jsonwebtoken.sign(...) Make sure that sensitive information is not exposed through JWT token payload.
Details: https://sg.run/5Qkj
8┆ return (jwt.sign(data, APP_SECRET, { algorithm:'HS256' }))
index.js
- javascript.express.security.audit.express-check-csurf-middleware-usage.express-
check-csurf-middleware-usage A CSRF middleware was not detected in your express application. Ensure you are either using one such as `csurf` or `csrf` (see rule references) and/or you are properly doing CSRF validation in your routes with a token or cookies. Details: https://sg.run/BxzR
4┆ const app = express();
views/interface.html
- html.security.audit.missing-integrity.missing-integrity
This tag is missing an 'integrity' subresource integrity attribute. The `integrity`attribute allows for the browser to verify that externally hosted files (for example from aCDN) are delivered without unexpected manipulation. Without this attribute, if an attacker can modify the externally hosted resource, this could lead to XSS and other types of attacks. To prevent this, include the base64-encoded cryptographic hash of the resource (file) you’re telling the browser to fetch in the `integrity` attribute for all externally hosted files. Details: https://sg.run/krXA
9┆ **<link rel="stylesheet" type="text/css" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.7.0/css/font-awesome.css">
Given the input that we have for our test results from SCA and Semgrep we can update and refine our testplan with the following items:
| Feature ID | Description | potential Vulnerability | Test Method | References |
|---|---|---|---|---|
| F001 | User Authentication | JWT is prone to signature bypasses | SCA should point out CVE. There is also other methods of attack that need to be tested described here: https://portswigger.net/web-security/jwt jsonwebtoken <=8.5.1 CVE-2022-23540 https://github.com/advisories/GHSA-qwph-4952-7xr6 Also, verify by decoding the JWT that no sensitive information goes in there. |
SCA scanning output. |
| F002 | User login | SQLI | A potential POC can be build following this resource. https://flattsecurity.medium.com/finding-an-unseen-sql-injection-by-bypassing-escape-functions-in-mysqljs-mysql-90b27f6542b4 |
Screenshot-1 |
| F003 | SpikyFactor.js | RCE | SonarQube detected a potential RCE in the calculate function of the challenge/helpers/SpikyFactor.js |
Screenshot-2 |
| F004 | index.js | CSRF | No CSRF middleware detected verify if we can perform CSRF somewhere in the app | Semgrep output |
In this scenario, given the relatively small size of our codebase, we encountered only a limited number of findings through Static Application Security Testing (SAST) and Software Composition Analysis (SCA) with Semgrep. It’s important to emphasize that not every finding necessitates immediate action or a deep dive analysis; rather, our approach should be strategic, focusing on issues that may have a direct and significant impact.
For SCA findings, we prioritize those for which we can develop a proof of concept (POC), as demonstrated in the image below. This approach helps to substantiate the practical implications of the vulnerabilities and facilitates more informed decision-making. For Semgrep findings, our focus shifts to identifying ‘quick wins’—findings that are straightforward to resolve and pertain to critical vulnerabilities, such as injection attacks or configuration errors. These are chosen for their potential to deliver substantial security enhancements promptly.
All other findings flagged by these tools, which do not pose an immediate threat, can be addressed subsequently as part of our ongoing process improvements. It’s vital to distinguish between activities aimed at uncovering high-severity vulnerabilities and those designed to enhance the overall security maturity of our development teams. By doing so, we can allocate our resources more effectively and ensure that our security assessments yield meaningful and impactful results.
