Snyk Code CLIのパブリックベータ版が利用可能に

1Testing . ...
2
3 ✗ [Medium] Cross-Site Request Forgery (CSRF) 
4     Path: app.js, line 16 
5     Info: Consider using csurf middleware for your Express app to protect against CSRF attacks.
6
7 ✗ [Medium] Use of Hard-coded Credentials 
8     Path: index.js, line 10 
9     Info: Do not hardcode credentials in code. Found hardcoded credential used in mysql.createConnection.
10
11 ✗ [Medium] Allocation of Resources Without Limits or Throttling 
12     Path: app.js, line 46 
13     Info: This endpoint handler performs a file system operation and does not use a rate-limiting mechanism. It may enable the attackers to perform Denial-of-service attacks. Consider using a rate-limiting middleware such as express-limit.
14
15 ✗ [Medium] Allocation of Resources Without Limits or Throttling 
16     Path: index.js, line 15 
17     Info: This endpoint handler performs a file system operation and does not use a rate-limiting mechanism. It may enable the attackers to perform Denial-of-service attacks. Consider using a rate-limiting middleware such as express-limit.
18
19 ✗ [Medium] Allocation of Resources Without Limits or Throttling 
20     Path: index.js, line 21 
21     Info: This endpoint handler performs a file system operation and does not use a rate-limiting mechanism. It may enable the attackers to perform Denial-of-service attacks. Consider using a rate-limiting middleware such as express-limit.
22
23 ✗ [Medium] Allocation of Resources Without Limits or Throttling 
24     Path: createDummyData.js, line 16 
25     Info: This endpoint handler performs a file system operation and does not use a rate-limiting mechanism. It may enable the attackers to perform Denial-of-service attacks. Consider using a rate-limiting middleware such as express-limit.
26
27 ✗ [Medium] Use of Hard-coded Credentials 
28     Path: index.js, line 11 
29     Info: Do not hardcode passwords in code. Found hardcoded password used in mysql.createConnection.
30
31 ✗ [High] Path Traversal 
32     Path: index.js, line 25 
33     Info: Unsanitized input from an HTTP parameter flows into fs.readFile, where it is used as a path. This may result in a Path Traversal vulnerability and allow an attacker to read arbitrary files.
34
35 ✗ [High] SQL Injection 
36     Path: index.js, line 39 
37     Info: Unsanitized input from an HTTP parameter flows into get, where it is used in an SQL query. This may result in an SQL Injection vulnerability.
38
39✔ Test completed
40
41Organization:      undefined
42Test type:         Static code analysis
43Project path:      .
44
459 Code issues found
462 [High]  7 [Medium] 

1{
2  "$schema": "https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json",
3  "version": "2.1.0",
4  "runs": [
5    {
6      "tool": {
7        "driver": {
8          "name": "SnykCode",
9          "semanticVersion": "1.0.0",
10          "version": "1.0.0",
11          "rules": [
12            {
13              "id": "javascript/UseCsurfForExpress",
14              "name": "UseCsurfForExpress",
15              "shortDescription": {
16                "text": "Cross-Site Request Forgery (CSRF)"
17              },
18              "defaultConfiguration": {
19                "level": "warning"
20              },
21              "help": {
22                "markdown": "\n## Details\nCross-site request forgery is an attack in which a malicious third party takes advantage of a user's authenticated credentials (such as a browser cookie) to impersonate that trusted user and perform unauthorized actions. The web application server cannot tell the difference between legitimate and malicious requests. This type of attack generally begins by tricking the user with a social engineering attack, such as a link or popup that the user inadvertently clicks, causing an unauthorized request to be sent to the web server. Consequences vary: At a standard user level, hackers can change passwords, transfer funds, make purchases, or connect with contacts; from an administrator account, hackers can then make changes to or even take down the app itself.\n\n### Best practices for prevention\n* Use development frameworks that defend against CSRF, using a nonce, hash, or some other security device to the URL and/or to forms.\n* Implement secure, unique, hidden tokens that are checked by the server each time to validate state-change requests.\n* Never assume that authentication tokens and session identifiers mean a request is legitimate.\n* Understand and implement other safe-cookie techniques, such as double submit cookies.\n* Terminate user sessions when not in use, including automatic timeout.\n* Ensure rigorous coding practices and defenses against other commonly exploited CWEs, since cross-site scripting (XSS), for example, can be used to bypass defenses against CSRF.\n\n## References\n\n* [Express Documentation - Implement CSRF Protection](https://expressjs.com/en/resources/middleware/csurf.html)\n* [Node Security Checklist - CSRF](https://blog.risingstack.com/node-js-security-checklist/#csrf)",
23                "text": ""
24              },
25              "properties": {
26                "tags": [
27                  "javascript",
28                  "maintenance",
29                  "express",
30                  "server",
31                  "CSRF"
32                ],
33                "categories": [
34                  "Security"
35                ],
36                "exampleCommitFixes": [
37                  {
38                    "commitURL": "https://github.com/eclipse/orion.client/commit/ad8f3bce33a1ea9d1e2144e6c42f075ad25829d6?diff=split#diff-16594450dc1f06f7d9cf4a47859cfa52L175",
39                    "lines": [
40                      {
41                        "line": "}",
42                        "lineNumber": 172,
43                        "lineChange": "none"
44                      },
45...