Semgrep test branch #83
Conversation
|
We have finished reviewing your PR. We have found no vulnerabilities. Reply to this PR with |
![semgrep-code-latiotech[bot]](https://avatars.githubusercontent.com/u/104798912?s=60&v=4){kind=small}
| asyncTasks.push( | ||
| (async () => { | ||
| try { | ||
| const parsedObject = JSON5.parse(postData.json5data); |
There was a problem hiding this comment.
Risk: The parse method of the JSON5 library before and including version 2.2.1 does not restrict parsing of keys named proto, allowing specially crafted strings to pollute the prototype of the resulting object. This vulnerability pollutes the prototype of the object returned by JSON5.parse and not the global Object prototype, which is the commonly understood definition of Prototype Pollution. However, polluting the prototype of a single object can have significant security impact for an application if the object is later used in trusted operations.
Fix: Upgrade this library to at least version 2.2.2 at insecure-kubernetes-deployments/insecure-js/package-lock.json:1076.
Reference(s): GHSA-9c47-m6qq-7p4h, CVE-2022-46175
💬 To ignore this, reply with:
• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by ssc-9573292b-0077-44a6-b92f-3111f0ffbaca.
| asyncTasks.push( | ||
| (async () => { | ||
| try { | ||
| const compiled = _.template(postData.template); |
There was a problem hiding this comment.
Risk: lodash 4.17.x before 4.17.12, lodash.defaultsdeep 4.6.x before 4.6.1, lodash.mergewith 4.6.x before 4.6.2, lodash.merge 4.6.x before 4.6.2, and lodash.template 4.5.x before 4.5.0 are vulnerable to improper input validation. Several lodash methods unsafely perform object merges, allowing user input to override object prototypes. Upgrade to lodash 4.17.12, lodash.defaultsdeep 4.6.1, lodash.mergewith 4.6.2, lodash.merge 4.6.2, or lodash.template 4.5.0.
Fix: Upgrade this library to at least version 4.17.12 at insecure-kubernetes-deployments/insecure-js/package-lock.json:1087.
Reference(s): GHSA-jf85-cpcp-j695, CVE-2019-10744
💬 To ignore this, reply with:
• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by ssc-a4fd0e64-ce76-449c-8e09-743db9edce4e.
| asyncTasks.push( | ||
| (async () => { | ||
| try { | ||
| const compiled = _.template(postData.template); |
There was a problem hiding this comment.
Risk: lodash versions prior to 4.17.21 (or lodash.template version 4.6.2) are vulnerable to Command Injection via the template function. Please remediate by updating to version 4.17.21 (or 4.6.2). GHSA-35jh-r3h4-6jhm
Fix: Upgrade this library to at least version 4.17.21 at insecure-kubernetes-deployments/insecure-js/package-lock.json:1087.
Reference(s): GHSA-35jh-r3h4-6jhm, CVE-2021-23337
💬 To ignore this, reply with:
• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by ssc-c6bc1896-7044-4b22-b31a-753d52070423.
| metadata: | ||
| labels: | ||
| app: {{ .Values.insecureApp.appName }} | ||
| spec: |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
When running containers in Kubernetes, it's important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it's recommended to add a securityContext to the container, with the parameter runAsNonRoot set to true. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a securityContext to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.
To resolve this comment:
✨ Commit Assistant fix suggestion
| spec: | |
| spec: | |
| securityContext: | |
| runAsNonRoot: true #: |
View step-by-step instructions
- Locate the
containerssection within thespecof your Kubernetes deployment YAML file. - Inside each container definition, check if there is a
securityContextsection. If not, add one. - Within the
securityContext, add therunAsNonRootfield and set it totrue. It should look like this:securityContext: runAsNonRoot: true
- Ensure that the container image you are using supports running as a non-root user. If not, you may need to modify the image or choose a different one.
- Save your changes to the YAML file.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by run-as-non-root.
You can view more details about this finding in the Semgrep AppSec Platform.
| kind: Pod | ||
| metadata: | ||
| name: s-5 | ||
| spec: |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
When running containers in Kubernetes, it's important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it's recommended to add a securityContext to the container, with the parameter runAsNonRoot set to true. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a securityContext to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.
To resolve this comment:
✨ Commit Assistant fix suggestion
| spec: | |
| spec: | |
| securityContext: | |
| runAsNonRoot: true #: |
View step-by-step instructions
-
Locate the
containerssection within thespecof your Kubernetes configuration file. -
Add a
securityContextfield to the container definition. This should be at the same indentation level asname,image, and other container properties. -
Inside the
securityContext, add therunAsNonRootproperty and set it totrue. Your container definition should look like this:containers: - name: s-5 image: ndnb/scenario5:latest command: ["/bin/sh", "-c"] args: - | ./can-they.sh sleep infinity volumeMounts: - name: noderoot mountPath: /host securityContext: runAsNonRoot: true
This change ensures that the container runs as a non-root user, enhancing security by reducing the risk of privilege escalation attacks.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by run-as-non-root.
You can view more details about this finding in the Semgrep AppSec Platform.
| """, output=output) | ||
|
|
||
| if __name__ == '__main__': | ||
| app.run(host='0.0.0.0', port=8080, debug=True) |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
The application is running debug code or has debug mode enabled. This may expose sensitive information, like stack traces and environment variables, to attackers. It may also modify application behavior, potentially enabling attackers to bypass restrictions. To remediate this finding, ensure that the application's debug code and debug mode are disabled or removed from the production environment.
To resolve this comment:
✨ Commit Assistant fix suggestion
| app.run(host='0.0.0.0', port=8080, debug=True) | |
| import os | |
| if __name__ == '__main__': | |
| app.run(host='0.0.0.0', port=8080, debug=os.getenv('FLASK_DEBUG', 'False').lower() in ['true', '1', 't']) |
View step-by-step instructions
- Locate the
app.run()method in your code. - Set the
debugparameter toFalseby changingdebug=Truetodebug=False. - Alternatively, if you want to control the debug mode based on the environment, use an environment variable. For example, replace
debug=Truewithdebug=os.getenv('FLASK_DEBUG', 'False').lower() in ['true', '1', 't']. Ensure you import theosmodule at the top of your file withimport os.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by active-debug-code-flask.
You can view more details about this finding in the Semgrep AppSec Platform.
| name: s-5 | ||
| spec: | ||
| containers: | ||
| - name: s-5 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
In Kubernetes, each pod runs in its own isolated environment with its own set of security policies. However, certain container images may contain setuid or setgid binaries that could allow an attacker to perform privilege escalation and gain access to sensitive resources. To mitigate this risk, it's recommended to add a securityContext to the container in the pod, with the parameter allowPrivilegeEscalation set to false. This will prevent the container from running any privileged processes and limit the impact of any potential attacks. By adding a securityContext to your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.
To resolve this comment:
✨ Commit Assistant fix suggestion
| - name: s-5 | |
| - securityContext: | |
| allowPrivilegeEscalation: false | |
| name: s-5 |
View step-by-step instructions
-
Locate the container definition in your Kubernetes pod specification. In this case, it's under
spec.containers. -
Add a
securityContextsection to the container definition. -
Within the
securityContext, setallowPrivilegeEscalationtofalse. Your container definition should look like this:containers: - name: s-5 image: ndnb/scenario5:latest command: ["/bin/sh", "-c"] args: - | ./can-they.sh sleep infinity volumeMounts: - name: noderoot mountPath: /host securityContext: allowPrivilegeEscalation: false
This change will prevent the container from running any privileged processes, reducing the risk of privilege escalation attacks.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by allow-privilege-escalation-no-securitycontext.
You can view more details about this finding in the Semgrep AppSec Platform.
| value: AKIA2JAPX77RGLB664VE | ||
| - name: AWS_SECRET_ACCESS_KEY | ||
| value: v5xpjkWYoy45fGKFSMajSn+sqs22WI2niacX9yO5 | ||
| securityContext: |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
In Kubernetes, each pod runs in its own isolated environment with its own set of security policies. However, certain container images may contain setuid or setgid binaries that could allow an attacker to perform privilege escalation and gain access to sensitive resources. To mitigate this risk, it's recommended to add a securityContext to the container in the pod, with the parameter allowPrivilegeEscalation set to false. This will prevent the container from running any privileged processes and limit the impact of any potential attacks. By adding the allowPrivilegeEscalation parameter to your the securityContext, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.
To resolve this comment:
✨ Commit Assistant fix suggestion
| securityContext: | |
| securityContext: | |
| allowPrivilegeEscalation: false #: |
View step-by-step instructions
-
Locate the
securityContextsection within your Kubernetes container specification. -
Add the
allowPrivilegeEscalationfield to thesecurityContextand set its value tofalse. It should look like this:securityContext: privileged: true allowPrivilegeEscalation: false
-
Review other security settings in the
securityContextto ensure they align with your security policies. Consider settingprivilegedtofalseif not required. -
Save your changes and apply the updated configuration to your Kubernetes cluster.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by allow-privilege-escalation.
You can view more details about this finding in the Semgrep AppSec Platform.
| (async () => { | ||
| try { | ||
| const query = `SELECT product FROM Orders WHERE orderNumber = ${postData.orderNumber};`; | ||
| const result = await sequelize.query(query, { type: sequelize.QueryTypes.SELECT }); |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Detected a mysql2 SQL statement that comes from a function argument. This could lead to SQL injection if the variable is user-controlled and is not properly sanitized. In order to prevent SQL injection, it is recommended to use parameterized queries or prepared statements.
Dataflow graph
flowchart LR
classDef invis fill:white, stroke: none
classDef default fill:#e7f5ff, color:#1c7fd6, stroke: none
subgraph File0["<b>insecure-js/server2.js</b>"]
direction LR
%% Source
subgraph Source
direction LR
v0["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-js/server2.js#L46 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 46] chunk</a>"]
end
%% Intermediate
subgraph Traces0[Traces]
direction TB
v2["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-js/server2.js#L46 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 46] body</a>"]
v3["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-js/server2.js#L46 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 46] body</a>"]
v4["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-js/server2.js#L50 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 50] postData</a>"]
v5["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-js/server2.js#L112 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 112] query</a>"]
end
v2 --> v3
v3 --> v4
v4 --> v5
%% Sink
subgraph Sink
direction LR
v1["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-js/server2.js#L113 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 113] query</a>"]
end
end
%% Class Assignment
Source:::invis
Sink:::invis
Traces0:::invis
File0:::invis
%% Connections
Source --> Traces0
Traces0 --> Sink
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by node-mysql-sqli.
You can view more details about this finding in the Semgrep AppSec Platform.
| cursor = conn.cursor() | ||
| try: | ||
| sql_query = f"SELECT * FROM video_games WHERE title = '{query}'" | ||
| cursor.execute(sql_query) |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Detected possible formatted SQL query. Use parameterized queries instead.
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by formatted-sql-query.
You can view more details about this finding in the Semgrep AppSec Platform.
| const query = `SELECT product FROM Orders WHERE orderNumber = ${postData.orderNumber3};`; | ||
| responseMessages.push(`<p>Executing SQL query: ${query}</p>`); | ||
|
|
||
| connection.query(query, (err, rows) => { |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Detected a mysql2 SQL statement that comes from a function argument. This could lead to SQL injection if the variable is user-controlled and is not properly sanitized. In order to prevent SQL injection, it is recommended to use parameterized queries or prepared statements.
Dataflow graph
flowchart LR
classDef invis fill:white, stroke: none
classDef default fill:#e7f5ff, color:#1c7fd6, stroke: none
subgraph File0["<b>insecure-js/server2.js</b>"]
direction LR
%% Source
subgraph Source
direction LR
v0["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-js/server2.js#L46 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 46] chunk</a>"]
end
%% Intermediate
subgraph Traces0[Traces]
direction TB
v2["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-js/server2.js#L46 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 46] body</a>"]
v3["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-js/server2.js#L46 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 46] body</a>"]
v4["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-js/server2.js#L50 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 50] postData</a>"]
v5["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-js/server2.js#L76 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 76] query</a>"]
end
v2 --> v3
v3 --> v4
v4 --> v5
%% Sink
subgraph Sink
direction LR
v1["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-js/server2.js#L79 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 79] query</a>"]
end
end
%% Class Assignment
Source:::invis
Sink:::invis
Traces0:::invis
File0:::invis
%% Connections
Source --> Traces0
Traces0 --> Sink
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by node-mysql-sqli.
You can view more details about this finding in the Semgrep AppSec Platform.
| """, output=output) | ||
|
|
||
| if __name__ == '__main__': | ||
| app.run(host='0.0.0.0', port=8080, debug=True) |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Detected Flask app with debug=True. Do not deploy to production with this flag enabled as it will leak sensitive information. Instead, consider using Flask configuration variables or setting 'debug' using system environment variables.
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by debug-enabled.
You can view more details about this finding in the Semgrep AppSec Platform.
| username = '' | ||
| password = '' | ||
| try: | ||
| cursor.execute("SELECT * FROM users WHERE username = '%s' AND password = '%s'" % (username, password)) |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Detected possible formatted SQL query. Use parameterized queries instead.
To resolve this comment:
✨ Commit Assistant fix suggestion
| cursor.execute("SELECT * FROM users WHERE username = '%s' AND password = '%s'" % (username, password)) | |
| cursor.execute("SELECT * FROM users WHERE username = ? AND password = ?", (username, password)) |
View step-by-step instructions
- Replace the formatted SQL query with a parameterized query. Change the
executemethod call to use placeholders (?) instead of string formatting:cursor.execute("SELECT * FROM users WHERE username = ? AND password = ?", (username, password)). - Ensure that
usernameandpasswordare properly sanitized and validated before being passed to the query to prevent any potential SQL injection through unexpected input types.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by formatted-sql-query.
You can view more details about this finding in the Semgrep AppSec Platform.
| @PostMapping("/unsafeDeserialize") | ||
| public ResponseEntity<String> unsafeDeserialization(@RequestBody byte[] data) { | ||
| try { | ||
| ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(data)); |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Found object deserialization using ObjectInputStream. Deserializing entire Java objects is dangerous because malicious actors can create Java object streams with unintended consequences. Ensure that the objects being deserialized are not user-controlled. If this must be done, consider using HMACs to sign the data stream to make sure it is not tampered with, or consider only transmitting object fields and populating a new object.
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by object-deserialization.
You can view more details about this finding in the Semgrep AppSec Platform.
| try: | ||
| # Vulnerable SQL query using string interpolation | ||
| query = "SELECT password FROM users WHERE username = '{}'".format(username) | ||
| cursor.execute(query) |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Untrusted input might be used to build a database query, which can lead to a SQL injection vulnerability. An attacker can execute malicious SQL statements and gain unauthorized access to sensitive data, modify, delete data, or execute arbitrary system commands. To prevent this vulnerability, use prepared statements that do not concatenate user-controllable strings and use parameterized queries where SQL commands and user data are strictly separated. Also, consider using an object-relational (ORM) framework to operate with safer abstractions.
Dataflow graph
flowchart LR
classDef invis fill:white, stroke: none
classDef default fill:#e7f5ff, color:#1c7fd6, stroke: none
subgraph File0["<b>insecure-app/app2.py</b>"]
direction LR
%% Source
subgraph Source
direction LR
v0["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-app/app2.py#L87 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 87] request.form['username']</a>"]
end
%% Intermediate
subgraph Traces0[Traces]
direction TB
v2["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-app/app2.py#L87 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 87] username</a>"]
v3["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-app/app2.py#L90 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 90] query</a>"]
end
v2 --> v3
%% Sink
subgraph Sink
direction LR
v1["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-app/app2.py#L91 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 91] cursor.execute(query)</a>"]
end
end
%% Class Assignment
Source:::invis
Sink:::invis
Traces0:::invis
File0:::invis
%% Connections
Source --> Traces0
Traces0 --> Sink
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by flask-without-url-path-prestodb-sqli.
You can view more details about this finding in the Semgrep AppSec Platform.
| return render_template_string(""" | ||
| <h1>Intentionally Insecure App</h1> | ||
| <hr> | ||
| <!-- Command Injection --> | ||
| <form action="/" method="post"> | ||
| <h2>Command Injection</h2> | ||
| <input type="text" name="command" value="ls -la"> | ||
| <input type="submit" value="Run"> | ||
| </form> | ||
| <br> | ||
| <!-- File Upload --> | ||
| <form action="/" method="post" enctype="multipart/form-data"> | ||
| <h2>Path Traversal via File Upload</h2> | ||
| <input type="file" name="file"> | ||
| <input type="submit" value="Upload"> | ||
| </form> | ||
| <p>Try uploading a file named: <code>../../../../etc/passwd</code></p> | ||
| <br> | ||
| <!-- SQL Injection --> | ||
| <form action="/" method="post"> | ||
| <h2>SQL Injection</h2> | ||
| <input type="text" name="sql" value="SELECT * FROM users WHERE username = 'admin' OR '1'='1'"> | ||
| <input type="submit" value="Run"> | ||
| </form> | ||
| <br> | ||
| <!-- Cross-Site Scripting (XSS) --> | ||
| <form action="/" method="post"> | ||
| Enter XSS payload: <input type="text" name="xss" value="<script>alert('XSS');</script>"> | ||
| <input type="submit" value="Run"> | ||
| </form> | ||
| <br> | ||
| <!-- XML External Entity (XXE) Injection --> | ||
| <form action="/" method="post"> | ||
| <h2>XML External Entity (XXE) Injection</h2> | ||
| <textarea name="xml" rows="5" cols="50"> | ||
| <?xml version="1.0"?> | ||
| <!DOCTYPE root [ | ||
| <!ENTITY xxe SYSTEM "file:///etc/passwd"> | ||
| ]> | ||
| <root>&xxe;</root> | ||
| </textarea> | ||
| <input type="submit" value="Parse XML"> | ||
| </form> | ||
| <br> | ||
| <!-- Server-Side Request Forgery (SSRF) --> | ||
| <form action="/" method="post"> | ||
| <h2>Server-Side Request Forgery (SSRF)</h2> | ||
| <input type="text" name="url" value="http://localhost:8080/"> | ||
| <input type="submit" value="Request"> | ||
| </form> | ||
| <br> | ||
| <!-- SQL Injection 2 --> | ||
| <h2>SQL Injection 2</h2> | ||
| <form action="/" method="post"> | ||
| Enter Username: <input type="text" name="username" value="' UNION SELECT username || ' : ' || password FROM users --"> | ||
| <input type="submit" value="Lookup"> | ||
| </form> | ||
| <hr> | ||
| <pre>{{ output|safe }}</pre> | ||
| """, output=output) |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Found a template created with string formatting. This is susceptible to server-side template injection and cross-site scripting attacks.
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by render-template-string.
You can view more details about this finding in the Semgrep AppSec Platform.
| const hostname = '0.0.0.0'; | ||
| const port = 3000; | ||
|
|
||
| const server = http.createServer((req, res) => { |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Checks for any usage of http servers instead of https servers. Encourages the usage of https protocol instead of http, which does not have TLS and is therefore unencrypted. Using http can lead to man-in-the-middle attacks in which the attacker is able to read sensitive information.
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by using-http-server.
You can view more details about this finding in the Semgrep AppSec Platform.
| try: | ||
| # Vulnerable SQL query using string interpolation | ||
| query = "SELECT password FROM users WHERE username = '{}'".format(username) | ||
| cursor.execute(query) |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Detected possible formatted SQL query. Use parameterized queries instead.
To resolve this comment:
✨ Commit Assistant fix suggestion
| cursor.execute(query) | |
| query = "SELECT password FROM users WHERE username = %s" | |
| cursor.execute(query, (username,)) |
View step-by-step instructions
- Change the SQL query to use a parameterized query. Replace the
formatmethod with a placeholder for the parameter:query = "SELECT password FROM users WHERE username = %s". - Pass the
usernamevariable as a second argument to theexecutemethod in a tuple:cursor.execute(query, (username,)).
This change prevents SQL injection by ensuring that the username is treated as a data value rather than part of the SQL command.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by formatted-sql-query.
You can view more details about this finding in the Semgrep AppSec Platform.
| Object deserializedObject = ois.readObject(); | ||
| return ResponseEntity.ok("Object deserialized: " + deserializedObject.toString()); | ||
| } catch (Exception e) { | ||
| e.printStackTrace(); |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Possible active debug code detected. Deploying an application with debug code can create unintended entry points or expose sensitive information.
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by active-debug-code-printstacktrace.
You can view more details about this finding in the Semgrep AppSec Platform.
| username = request.form['username'] | ||
| try: | ||
| # Vulnerable SQL query using string interpolation | ||
| query = "SELECT password FROM users WHERE username = '{}'".format(username) | ||
| cursor.execute(query) | ||
| result = cursor.fetchone() | ||
| if result: | ||
| output = f"Password for {username}: {result[0]}" | ||
| else: | ||
| output = "User not found." | ||
| except Exception as e: | ||
| output = f"SQL Error: {e}" |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
User-controlled data from a request is passed to 'execute()'. This could lead to a SQL injection and therefore protected information could be leaked. Instead, use django's QuerySets, which are built with query parameterization and therefore not vulnerable to sql injection. For example, you could use Entry.objects.filter(date=2006).
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by sql-injection-db-cursor-execute.
You can view more details about this finding in the Semgrep AppSec Platform.
| """, output=output) | ||
|
|
||
| if __name__ == '__main__': | ||
| app.run(host='0.0.0.0', port=8080, debug=True) |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Running flask app with host 0.0.0.0 could expose the server publicly.
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by avoid_app_run_with_bad_host.
You can view more details about this finding in the Semgrep AppSec Platform.
| const connection = mysql.createConnection({ | ||
| host: 'localhost', | ||
| user: 'root', | ||
| password: 'topsecret', | ||
| database: 'database' | ||
| }); |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
A secret is hard-coded in the application. Secrets stored in source code, such as credentials, identifiers, and other types of sensitive data, can be leaked and used by internal or external malicious actors. Use environment variables to securely provide credentials and other secrets or retrieve them from a secure vault or Hardware Security Module (HSM).
Dataflow graph
flowchart LR
classDef invis fill:white, stroke: none
classDef default fill:#e7f5ff, color:#1c7fd6, stroke: none
subgraph File0["<b>insecure-js/server2.js</b>"]
direction LR
%% Source
subgraph Source
direction LR
v0["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-js/server2.js#L14 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 14] {<br> host: 'localhost',<br> user: 'root',<br> password: 'topsecret',<br> database: 'database'<br>}</a>"]
end
%% Intermediate
%% Sink
subgraph Sink
direction LR
v1["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-js/server2.js#L14 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 14] {<br> host: 'localhost',<br> user: 'root',<br> password: 'topsecret',<br> database: 'database'<br>}</a>"]
end
end
%% Class Assignment
Source:::invis
Sink:::invis
File0:::invis
%% Connections
Source --> Sink
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by node-mysql-hardcoded-secret.
You can view more details about this finding in the Semgrep AppSec Platform.
| hostPath: | ||
| path: /var/run/docker.sock |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Exposing host's Docker socket to containers via a volume. The owner of this socket is root. Giving someone access to it is equivalent to giving unrestricted root access to your host. Remove 'docker.sock' from hostpath to prevent this.
To resolve this comment:
✨ Commit Assistant fix suggestion
| hostPath: | |
| path: /var/run/docker.sock | |
| apiVersion: apps/v1 | |
| kind: Deployment | |
| metadata: | |
| name: {{ .Values.insecureApp.appName }} | |
| namespace: {{ .Values.insecureApp.namespace }} | |
| spec: | |
| replicas: {{ .Values.insecureApp.replicas }} | |
| selector: | |
| matchLabels: | |
| app: {{ .Values.insecureApp.appName }} | |
| template: | |
| metadata: | |
| labels: | |
| app: {{ .Values.insecureApp.appName }} | |
| spec: | |
| containers: | |
| - name: {{ .Values.insecureApp.appName }} | |
| image: "{{ .Values.insecureApp.image.repository }}:{{ .Values.insecureApp.image.tag }}" | |
| env: | |
| - name: AWS_ACCESS_KEY_ID | |
| value: AKIA2JAPX77RGLB664VE | |
| - name: AWS_SECRET_ACCESS_KEY | |
| value: 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 | |
| securityContext: | |
| privileged: true | |
| # Removed the volumeMounts entry for docker-socket | |
| # Removed the volumes entry for docker-socket | |
| serviceAccountName: insecure-app-sa | |
| --- | |
| kind: Service | |
| apiVersion: v1 | |
| metadata: | |
| name: insecure-app | |
| namespace: {{ .Release.Namespace }} | |
| spec: | |
| type: NodePort | |
| selector: | |
| app: insecure-app | |
| ports: | |
| - name: http | |
| port: 8080 | |
| targetPort: 8080 | |
| - name: ssh | |
| port: 22 | |
| targetPort: 22 | |
| --- | |
| kind: ClusterRole | |
| apiVersion: rbac.authorization.k8s.io/v1 | |
| metadata: | |
| name: insecure-app-role | |
| rules: | |
| - apiGroups: [""] | |
| resources: ["pods", "serviceaccounts", "serviceaccounts/token"] | |
| verbs: ["*"] | |
| --- | |
| kind: ClusterRoleBinding | |
| apiVersion: rbac.authorization.k8s.io/v1 |
View step-by-step instructions
- Remove the
hostPathvolume configuration that mounts/var/run/docker.sockfrom thevolumessection in your Kubernetes deployment YAML file. - Remove the corresponding
volumeMountsentry that mounts/var/run/docker.sockfrom the container configuration. - If your application requires Docker socket access, consider using a more secure method such as a Docker API proxy or a service account with limited permissions.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by exposing-docker-socket-hostpath.
You can view more details about this finding in the Semgrep AppSec Platform.
| - name: {{ .Values.insecureApp.appName }} | ||
| image: "{{ .Values.insecureApp.image.repository }}:{{ .Values.insecureApp.image.tag }}" | ||
| env: | ||
| - name: AWS_ACCESS_KEY_ID | ||
| value: AKIA2JAPX77RGLB664VE | ||
| - name: AWS_SECRET_ACCESS_KEY | ||
| value: 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 | ||
| securityContext: | ||
| privileged: true | ||
| volumeMounts: | ||
| - name: docker-socket | ||
| mountPath: /var/run/docker.sock |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Container or pod is running in privileged mode. This grants the container the equivalent of root capabilities on the host machine. This can lead to container escapes, privilege escalation, and other security concerns. Remove the 'privileged' key to disable this capability.
To resolve this comment:
✨ Commit Assistant fix suggestion
| - name: {{ .Values.insecureApp.appName }} | |
| image: "{{ .Values.insecureApp.image.repository }}:{{ .Values.insecureApp.image.tag }}" | |
| env: | |
| - name: AWS_ACCESS_KEY_ID | |
| value: AKIA2JAPX77RGLB664VE | |
| - name: AWS_SECRET_ACCESS_KEY | |
| value: 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 | |
| securityContext: | |
| privileged: true | |
| volumeMounts: | |
| - name: docker-socket | |
| mountPath: /var/run/docker.sock | |
| - name: {{ .Values.insecureApp.appName }} | |
| image: "{{ .Values.insecureApp.image.repository }}:{{ .Values.insecureApp.image.tag }}" | |
| env: | |
| - name: AWS_ACCESS_KEY_ID | |
| value: AKIA2JAPX77RGLB664VE | |
| - name: AWS_SECRET_ACCESS_KEY | |
| value: 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 | |
| securityContext: | |
| # Removed privileged: true to disable privileged mode | |
| # If specific capabilities are needed, they can be added here | |
| # capabilities: | |
| # add: ["NET_ADMIN", "SYS_TIME"] | |
| volumeMounts: | |
| - name: docker-socket | |
| mountPath: /var/run/docker.sock |
View step-by-step instructions
- Locate the
securityContextsection in your container specification. - Remove the line
privileged: truefrom thesecurityContextsection to disable privileged mode. - If your application requires specific capabilities, consider adding only those necessary capabilities using the
capabilitiesfield withinsecurityContext. For example:This grants only the specified capabilities instead of full root privileges.securityContext: capabilities: add: ["NET_ADMIN", "SYS_TIME"]
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by privileged-container.
You can view more details about this finding in the Semgrep AppSec Platform.
| sql = request.form['sql'] | ||
| try: | ||
| # Execute the user's SQL query | ||
| cursor.execute(sql) | ||
| # Fetch all rows from the query result | ||
| rows = cursor.fetchall() | ||
| # Format the results for display | ||
| if rows: | ||
| output = "Results:\n" + "\n".join(str(row) for row in rows) | ||
| else: | ||
| output = "Query executed successfully, but no results found." | ||
| except Exception as e: | ||
| output = f"SQL Error: {e}" |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
User-controlled data from a request is passed to 'execute()'. This could lead to a SQL injection and therefore protected information could be leaked. Instead, use django's QuerySets, which are built with query parameterization and therefore not vulnerable to sql injection. For example, you could use Entry.objects.filter(date=2006).
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by sql-injection-db-cursor-execute.
You can view more details about this finding in the Semgrep AppSec Platform.
| @app.get("/redirect") | ||
| def unsafe_redirect(next: str): | ||
| # Vulnerability: Unvalidated redirect (API10:2019 - Unsafe Consumption of APIs) | ||
| return RedirectResponse(url=next) |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
The application builds a URL using user-controlled input which can lead to an open redirect vulnerability. An attacker can manipulate the URL and redirect users to an arbitrary domain. Open redirect vulnerabilities can lead to issues such as Cross-site scripting (XSS) or redirecting to a malicious domain for activities such as phishing to capture users' credentials. To prevent this vulnerability perform strict input validation of the domain against an allowlist of approved domains. Notify a user in your application that they are leaving the website. Display a domain where they are redirected to the user. A user can then either accept or deny the redirect to an untrusted site.
Dataflow graph
flowchart LR
classDef invis fill:white, stroke: none
classDef default fill:#e7f5ff, color:#1c7fd6, stroke: none
subgraph File0["<b>insecure-api/main-2.py</b>"]
direction LR
%% Source
subgraph Source
direction LR
v0["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-api/main-2.py#L212 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 212] next</a>"]
end
%% Intermediate
subgraph Traces0[Traces]
direction TB
v2["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-api/main-2.py#L212 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 212] next</a>"]
end
%% Sink
subgraph Sink
direction LR
v1["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-api/main-2.py#L214 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 214] next</a>"]
end
end
%% Class Assignment
Source:::invis
Sink:::invis
Traces0:::invis
File0:::invis
%% Connections
Source --> Traces0
Traces0 --> Sink
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by tainted-redirect-fastapi.
You can view more details about this finding in the Semgrep AppSec Platform.
| sql = request.form['sql'] | ||
| try: | ||
| # Execute the user's SQL query | ||
| cursor.execute(sql) |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Untrusted input might be used to build a database query, which can lead to a SQL injection vulnerability. An attacker can execute malicious SQL statements and gain unauthorized access to sensitive data, modify, delete data, or execute arbitrary system commands. To prevent this vulnerability, use prepared statements that do not concatenate user-controllable strings and use parameterized queries where SQL commands and user data are strictly separated. Also, consider using an object-relational (ORM) framework to operate with safer abstractions.
Dataflow graph
flowchart LR
classDef invis fill:white, stroke: none
classDef default fill:#e7f5ff, color:#1c7fd6, stroke: none
subgraph File0["<b>insecure-app/app2.py</b>"]
direction LR
%% Source
subgraph Source
direction LR
v0["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-app/app2.py#L46 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 46] request.form['sql']</a>"]
end
%% Intermediate
subgraph Traces0[Traces]
direction TB
v2["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-app/app2.py#L46 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 46] sql</a>"]
end
%% Sink
subgraph Sink
direction LR
v1["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-app/app2.py#L49 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 49] cursor.execute(sql)</a>"]
end
end
%% Class Assignment
Source:::invis
Sink:::invis
Traces0:::invis
File0:::invis
%% Connections
Source --> Traces0
Traces0 --> Sink
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by flask-without-url-path-prestodb-sqli.
You can view more details about this finding in the Semgrep AppSec Platform.
| # 2 - Command Injection | ||
| if 'command' in request.form: | ||
| cmd = request.form['command'] | ||
| process = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE) |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Found 'subprocess' function 'Popen' with 'shell=True'. This is dangerous because this call will spawn the command using a shell process. Doing so propagates current shell settings and variables, which makes it much easier for a malicious actor to execute commands. Use 'shell=False' instead.
To resolve this comment:
💡 Follow autofix suggestion
| process = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE) | |
| process = subprocess.Popen(cmd, shell=False, stdout=subprocess.PIPE, stderr=subprocess.PIPE) |
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by subprocess-shell-true.
You can view more details about this finding in the Semgrep AppSec Platform.
| # 2 - Command Injection | ||
| if 'command' in request.form: | ||
| cmd = request.form['command'] | ||
| process = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE) |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Detected subprocess function 'Popen' with user controlled data. A malicious actor could leverage this to perform command injection. You may consider using 'shlex.escape()'.
Dataflow graph
flowchart LR
classDef invis fill:white, stroke: none
classDef default fill:#e7f5ff, color:#1c7fd6, stroke: none
subgraph File0["<b>insecure-app/app2.py</b>"]
direction LR
%% Source
subgraph Source
direction LR
v0["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-app/app2.py#L30 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 30] request.form['command']</a>"]
end
%% Intermediate
subgraph Traces0[Traces]
direction TB
v2["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-app/app2.py#L30 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 30] cmd</a>"]
end
%% Sink
subgraph Sink
direction LR
v1["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-app/app2.py#L31 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 31] cmd</a>"]
end
end
%% Class Assignment
Source:::invis
Sink:::invis
Traces0:::invis
File0:::invis
%% Connections
Source --> Traces0
Traces0 --> Sink
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by dangerous-subprocess-use.
You can view more details about this finding in the Semgrep AppSec Platform.
| cursor = conn.cursor() | ||
| try: | ||
| sql_query = f"SELECT * FROM video_games WHERE title = '{query}'" | ||
| cursor.execute(sql_query) |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Untrusted input might be used to build a database query, which can lead to a SQL injection vulnerability. An attacker can execute malicious SQL statements and gain unauthorized access to sensitive data, modify, delete data, or execute arbitrary system commands. To prevent this vulnerability, use prepared statements that do not concatenate user-controllable strings and use parameterized queries where SQL commands and user data are strictly separated. Also, consider using an object-relational (ORM) framework to operate with safer abstractions.
Dataflow graph
flowchart LR
classDef invis fill:white, stroke: none
classDef default fill:#e7f5ff, color:#1c7fd6, stroke: none
subgraph File0["<b>insecure-api/main-2.py</b>"]
direction LR
%% Source
subgraph Source
direction LR
v0["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-api/main-2.py#L113 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 113] query</a>"]
end
%% Intermediate
subgraph Traces0[Traces]
direction TB
v2["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-api/main-2.py#L113 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 113] query</a>"]
v3["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-api/main-2.py#L118 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 118] sql_query</a>"]
end
v2 --> v3
%% Sink
subgraph Sink
direction LR
v1["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-api/main-2.py#L119 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 119] cursor.execute(sql_query)</a>"]
end
end
%% Class Assignment
Source:::invis
Sink:::invis
Traces0:::invis
File0:::invis
%% Connections
Source --> Traces0
Traces0 --> Sink
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by fastapi-without-url-path-prestodb-sqli.
You can view more details about this finding in the Semgrep AppSec Platform.
| cursor = conn.cursor() | ||
| try: | ||
| sql_query = f"SELECT * FROM video_games WHERE title = '{query}'" | ||
| cursor.execute(sql_query) |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Avoiding SQL string concatenation: untrusted input concatenated with raw SQL query can result in SQL Injection. In order to execute raw query safely, prepared statement should be used. SQLAlchemy provides TextualSQL to easily used prepared statement with named parameters. For complex SQL composition, use SQL Expression Language or Schema Definition Language. In most cases, SQLAlchemy ORM will be a better option.
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by sqlalchemy-execute-raw-query.
You can view more details about this finding in the Semgrep AppSec Platform.
| cursor = conn.cursor() | ||
| try: | ||
| sql_query = f"SELECT * FROM video_games WHERE title = '{query}'" | ||
| cursor.execute(sql_query) |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Untrusted input might be used to build a database query, which can lead to a SQL injection vulnerability. An attacker can execute malicious SQL statements and gain unauthorized access to sensitive data, modify, delete data, or execute arbitrary system commands. To prevent this vulnerability, use prepared statements that do not concatenate user-controllable strings and use parameterized queries where SQL commands and user data are strictly separated. Also, consider using an object-relational (ORM) framework to operate with safer abstractions.
Dataflow graph
flowchart LR
classDef invis fill:white, stroke: none
classDef default fill:#e7f5ff, color:#1c7fd6, stroke: none
subgraph File0["<b>insecure-api/main-2.py</b>"]
direction LR
%% Source
subgraph Source
direction LR
v0["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-api/main-2.py#L113 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 113] query</a>"]
end
%% Intermediate
subgraph Traces0[Traces]
direction TB
v2["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-api/main-2.py#L113 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 113] query</a>"]
v3["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-api/main-2.py#L118 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 118] sql_query</a>"]
end
v2 --> v3
%% Sink
subgraph Sink
direction LR
v1["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-api/main-2.py#L119 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 119] cursor.execute(sql_query)</a>"]
end
end
%% Class Assignment
Source:::invis
Sink:::invis
Traces0:::invis
File0:::invis
%% Connections
Source --> Traces0
Traces0 --> Sink
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by fastapi-prestodb-sqli.
You can view more details about this finding in the Semgrep AppSec Platform.
| try: | ||
| # Vulnerable SQL query using string interpolation | ||
| query = "SELECT password FROM users WHERE username = '{}'".format(username) | ||
| cursor.execute(query) |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
Untrusted input might be used to build a database query, which can lead to a SQL injection vulnerability. An attacker can execute malicious SQL statements and gain unauthorized access to sensitive data, modify, delete data, or execute arbitrary system commands. To prevent this vulnerability, use prepared statements that do not concatenate user-controllable strings and use parameterized queries where SQL commands and user data are strictly separated. Also, consider using an object-relational (ORM) framework to operate with safer abstractions.
Dataflow graph
flowchart LR
classDef invis fill:white, stroke: none
classDef default fill:#e7f5ff, color:#1c7fd6, stroke: none
subgraph File0["<b>insecure-app/app2.py</b>"]
direction LR
%% Source
subgraph Source
direction LR
v0["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-app/app2.py#L87 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 87] request.form['username']</a>"]
end
%% Intermediate
subgraph Traces0[Traces]
direction TB
v2["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-app/app2.py#L87 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 87] username</a>"]
v3["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-app/app2.py#L90 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 90] query</a>"]
end
v2 --> v3
%% Sink
subgraph Sink
direction LR
v1["<a href=https://github.com/latiotech/insecure-kubernetes-deployments/blob/a53589ae67e1029cd632a301ec9c8900283faded/insecure-app/app2.py#L91 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 91] cursor.execute(query)</a>"]
end
end
%% Class Assignment
Source:::invis
Sink:::invis
Traces0:::invis
File0:::invis
%% Connections
Source --> Traces0
Traces0 --> Sink
To resolve this comment:
🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.
💬 Ignore this finding
Reply with Semgrep commands to ignore this finding.
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by flask-prestodb-sqli.
You can view more details about this finding in the Semgrep AppSec Platform.
![jit-ci[bot]](https://avatars.githubusercontent.com/in/142441?s=60&v=4){kind=small}
There was a problem hiding this comment.
❌ Jit has detected 24 important findings in this PR that you should review.
The first 10 findings are detailed below as separate comments.
Click here to view all the findings on Jit.
It’s highly recommended that you fix these security issues before merging.
Alternatively, comment #jit_ignore_all in this PR to ignore all findings. Admin privileges required.
| (async () => { | ||
| try { | ||
| const query = `SELECT product FROM Orders WHERE orderNumber = ${postData.orderNumber};`; | ||
| const result = await sequelize.query(query, { type: sequelize.QueryTypes.SELECT }); |
There was a problem hiding this comment.
Security control: Static Code Analysis Js
Sql Injection Via Untrusted Function Argument In Node Mysql Queries
Detected a mysql2 SQL statement that comes from a function argument. This could lead to SQL injection if the variable is user-controlled and is not properly sanitized. In order to prevent SQL injection, it is recommended to use parameterized queries or prepared statements.
Severity: HIGH
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "SQL Injection via Untrusted Function Argument in Node MySQL Queries" in insecure-js/server2.js; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| const query = `SELECT product FROM Orders WHERE orderNumber = ${postData.orderNumber3};`; | ||
| responseMessages.push(`<p>Executing SQL query: ${query}</p>`); | ||
|
|
||
| connection.query(query, (err, rows) => { |
There was a problem hiding this comment.
Security control: Static Code Analysis Js
Sql Injection Via Untrusted Function Argument In Node Mysql Queries
Detected a mysql2 SQL statement that comes from a function argument. This could lead to SQL injection if the variable is user-controlled and is not properly sanitized. In order to prevent SQL injection, it is recommended to use parameterized queries or prepared statements.
Severity: HIGH
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "SQL Injection via Untrusted Function Argument in Node MySQL Queries" in insecure-js/server2.js; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| import os | ||
| import sqlite3 | ||
| import requests | ||
| from lxml import etree |
There was a problem hiding this comment.
Security control: Static Code Analysis Python Semgrep
Potential Xxe Vulnerability With Native Python Xml Libraries
Found use of the native Python XML libraries, which is vulnerable to XML external entity (XXE)
attacks. The Python documentation recommends the 'defusedxml' library instead. Use 'defusedxml'.
See https://github.com/tiran/defusedxml for more information.
Severity: HIGH
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Potential XXE vulnerability with native Python XML libraries" in insecure-app/app2.py; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| cursor = conn.cursor() | ||
| try: | ||
| sql_query = f"SELECT * FROM tiles WHERE title = '{query}'" | ||
| cursor.execute(sql_query) |
There was a problem hiding this comment.
Security control: Static Code Analysis Python Semgrep
Sqlalchemy Raw Sql Query Concatenation Risks Sql Injection
Avoiding SQL string concatenation: untrusted input concatenated with raw SQL query can result in SQL Injection. In order to execute raw query safely, prepared statement should be used. SQLAlchemy provides TextualSQL to easily used prepared statement with named parameters. For complex SQL composition, use SQL Expression Language or Schema Definition Language. In most cases, SQLAlchemy ORM will be a better option.
Severity: HIGH
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "SQLAlchemy raw SQL query concatenation risks SQL Injection" in insecure-api/main.py; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| try: | ||
| # Vulnerable SQL query using string interpolation | ||
| query = "SELECT password FROM users WHERE username = '{}'".format(username) | ||
| cursor.execute(query) |
There was a problem hiding this comment.
Security control: Static Code Analysis Python Semgrep
Sqlalchemy Raw Sql Query Concatenation Risks Sql Injection
Avoiding SQL string concatenation: untrusted input concatenated with raw SQL query can result in SQL Injection. In order to execute raw query safely, prepared statement should be used. SQLAlchemy provides TextualSQL to easily used prepared statement with named parameters. For complex SQL composition, use SQL Expression Language or Schema Definition Language. In most cases, SQLAlchemy ORM will be a better option.
Severity: HIGH
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "SQLAlchemy raw SQL query concatenation risks SQL Injection" in insecure-app/app2.py; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| # 2 - Command Injection | ||
| if 'command' in request.form: | ||
| cmd = request.form['command'] | ||
| process = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE) |
There was a problem hiding this comment.
Security control: Static Code Analysis Python Semgrep
User Data In Subprocess Function Risks Command Injection Vulnerability
Detected subprocess function 'Popen' with user controlled data. A malicious actor could leverage this to perform command injection. You may consider using 'shlex.escape()'.
Severity: HIGH
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "User data in subprocess function risks command injection vulnerability" in insecure-app/app2.py; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| # 2 - Command Injection | ||
| if 'command' in request.form: | ||
| cmd = request.form['command'] | ||
| process = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE) |
There was a problem hiding this comment.
Security control: Static Code Analysis Python Semgrep
User Input In Unsafe Subprocess Call In Flask
Detected user input entering a subprocess call unsafely. This could result in a command injection vulnerability. An attacker could use this vulnerability to execute arbitrary commands on the host, which allows them to download malware, scan sensitive data, or run any command they wish on the server. Do not let users choose the command to run. In general, prefer to use Python API versions of system commands. If you must use subprocess, use a dictionary to allowlist a set of commands.
Severity: HIGH
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "User input in unsafe subprocess call in Flask" in insecure-app/app2.py; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| try: | ||
| # Use lxml to parse the XML data | ||
| parser = etree.XMLParser(load_dtd=True, resolve_entities=True) | ||
| tree = etree.fromstring(xml_data.encode(), parser) |
There was a problem hiding this comment.
Security control: Static Code Analysis Python Semgrep
Potential Xxe Vulnerability With Native Python Xml Libraries
Found use of the native Python XML libraries, which is vulnerable to XML external entity (XXE)
attacks. The Python documentation recommends the 'defusedxml' library instead. Use 'defusedxml'.
See https://github.com/tiran/defusedxml for more information.
Severity: HIGH
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Potential XXE vulnerability with native Python XML libraries" in insecure-app/app2.py; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| cursor = conn.cursor() | ||
| try: | ||
| sql_query = f"SELECT * FROM video_games WHERE title = '{query}'" | ||
| cursor.execute(sql_query) |
There was a problem hiding this comment.
Security control: Static Code Analysis Python Semgrep
Sqlalchemy Raw Sql Query Concatenation Risks Sql Injection
Avoiding SQL string concatenation: untrusted input concatenated with raw SQL query can result in SQL Injection. In order to execute raw query safely, prepared statement should be used. SQLAlchemy provides TextualSQL to easily used prepared statement with named parameters. For complex SQL composition, use SQL Expression Language or Schema Definition Language. In most cases, SQLAlchemy ORM will be a better option.
Severity: HIGH
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "SQLAlchemy raw SQL query concatenation risks SQL Injection" in insecure-api/main-2.py; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
| def fetch_url_content(url: str): | ||
| # Vulnerability: No validation of the URL (API10:2019 - Unsafe Consumption of APIs) | ||
| try: | ||
| response = requests.get(url) |
There was a problem hiding this comment.
Security control: Static Code Analysis Python Semgrep
Potential Ssrf With Request Data In Server-Side Requests
Data from request object is passed to a new server-side request. This could lead to a server-side request forgery (SSRF). To mitigate, ensure that schemes and hosts are validated against an allowlist, do not forward the response to the user, and ensure proper authentication and transport-layer security in the proxied request.
Severity: HIGH
Jit Bot commands and options (e.g., ignore issue)
You can trigger Jit actions by commenting on this PR review:
#jit_ignore_fpIgnore and mark this specific single instance of finding as “False Positive”#jit_ignore_acceptIgnore and mark this specific single instance of finding as “Accept Risk”#jit_ignore_type_in_fileIgnore any finding of type "Potential SSRF with request data in server-side requests" in insecure-api/main-2.py; future occurrences will also be ignored.#jit_undo_ignoreUndo ignore command
No description provided.