Skip to content

Update app.py #4

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Update app.py #4

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion insecure-app/app.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@ def index():
sql = request.form['sql']
try:
# Execute the user's SQL query
cursor.execute(sql)
cursor.execute(sql) #oh-o
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SQL Injection ( 🔴 High ) - The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. View in Corgea ↗

More Details
🎟️Issue Explanation: The code builds an SQL command using external input without proper checks, allowing attackers to change the query and access or harm the database.

- "cursor.execute(sql)" runs a command that likely includes unchecked user input, enabling SQL Injection.
- Attackers can insert SQL code, e.g., ' OR 1=1 --, to bypass authentication or extract data.
- This risks exposing sensitive data or corrupting the database since SQL commands aren’t safely handled.

🪄Fix Explanation: The fix mitigates SQL Injection by separating the SQL query from its parameters and passing them separately to "cursor.execute", ensuring user inputs are properly escaped and not executed as SQL code.
The original code directly interpolated user input with "cursor.execute(sql)", which allowed SQL injection.
The fix uses "cursor.execute(sql_query, sql_params)", parameterizing inputs to neutralize malicious SQL.
User inputs are split into query text "sql_query" and parameters "sql_params" via "request.form.get" and "getlist".
This approach relies on the DB-API's parameter substitution, which safely escapes inputs rather than concatenating strings.

💡Important Instructions: Ensure the client side sends parameters in the expected params[] format and verify query templates disallow unsafe constructs to prevent logic flaws or errors.
Suggested change
cursor.execute(sql) #oh-o
# Split user input into SQL text and parameters for safer execution

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SQL Injection ( 🔴 Critical ) - The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. View in Corgea ↗

More Details
🎟️Issue Explanation: The code runs an SQL command built from outside input without properly cleaning it, allowing attackers to change the query's behavior.

- The "cursor.execute(sql)" runs the raw SQL string without filtering special characters like quotes or SQL keywords.
- An attacker can inject SQL code (e.g., "1; DROP TABLE users;") to manipulate or damage the database.
- This happens because the external input is directly inserted into "sql" without any validation or escaping.

We could not generate a fix for this.

# Fetch all rows from the query result
rows = cursor.fetchall()
# Format the results for display
Expand Down