Add files via upload by bandarisantosh · Pull Request #11 · bandarisantosh/bad-python-app

bandarisantosh · 2024-11-26T21:55:12Z

No description provided.

private-semgrep-app · 2024-11-26T21:56:43Z

sql_injection_login.py

+    password_hash = _hash_password(password)
+
+    sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"
+    sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"


Detected user input used to manually construct a SQL string. This is usually bad practice because manual construction could accidentally result in a SQL injection. An attacker could use a SQL injection to steal or modify contents of the database. Instead, use a parameterized query which is available by default in most database engines. Alternatively, consider using the Django object-relational mappers (ORM) instead of raw SQL queries.

View Dataflow Graph

flowchart LR classDef invis fill:white, stroke: none classDef default fill:#e7f5ff, color:#1c7fd6, stroke: none subgraph File0["sql_injection_login.py"] direction LR %% Source subgraph Source direction LR v0["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L14 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 14] request.form</a>"] end %% Intermediate subgraph Traces0[Traces] direction TB v2["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L14 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 14] form</a>"] v3["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L16 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 16] username</a>"] end v2 --> v3 %% Sink subgraph Sink direction LR v1["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L21 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 21] f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"</a>"] end end %% Class Assignment Source:::invis Sink:::invis Traces0:::invis File0:::invis %% Connections Source --> Traces0 Traces0 --> Sink

Loading

_{⚪️ This finding does not block your pull request.}
_{Ignore this finding from tainted-sql-string}

Semgrep Assistant suggests the following fix: Use parameterized queries instead of manually constructing SQL strings.

View step-by-step instructions

Replace the SQL query construction with a parameterized query to prevent SQL injection.

Use a database library that supports parameterized queries, such as SQLAlchemy or the database library you are using.

Modify the SQL query to use placeholders for the parameters. For example, change the query to: sql = "SELECT * FROM users WHERE username=:username AND password=:password".

Pass the parameters as a dictionary to the execute_read method. For example: db_result = app.db_helper.execute_read(sql, {"username": username, "password": password_hash}).

Alternatively, if you are using Django, consider using the Django ORM to handle database queries, which automatically uses parameterized queries.

This code change should be a good starting point:

Suggested change

sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"

sql = "SELECT * FROM users WHERE username=:username AND password=:password"

db_result = app.db_helper.execute_read(sql, {"username": username, "password": password_hash})

_{Leave feedback with a 👍 / 👎. Save a memory with /remember <your custom instructions>.}

private-semgrep-app · 2024-11-26T21:56:44Z

sql_injection_login.py

+    sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"
+    sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"
+    sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"
+    flask.render_template_string(username)


Found a template created with string formatting. This is susceptible to server-side template injection and cross-site scripting attacks.

_{⚪️ This finding does not block your pull request.}
_{Ignore this finding from render-template-string}

Semgrep Assistant suggests the following fix: Use render_template with a predefined template file instead of render_template_string with user input.

View step-by-step instructions

Avoid using render_template_string with user input directly. Instead, use render_template with a predefined template file.

If you need to pass the username to the template, ensure it is properly escaped to prevent injection attacks. You can pass it as a variable to render_template.

Replace flask.render_template_string(username) with return render_template('your_template.html', username=username), where 'your_template.html' is the path to your HTML template file.

In your HTML template file, use Jinja2's autoescaping feature to safely display the username variable, like this: {{ username }}. This will automatically escape any HTML special characters in username.

This code change should be a good starting point:

Suggested change

flask.render_template_string(username)

return render_template('your_template.html', username=username)

_{Leave feedback with a 👍 / 👎. Save a memory with /remember <your custom instructions>.}

private-semgrep-app · 2024-11-26T21:56:46Z

sql_injection_login.py

+
+    username = form.get('username')
+    password = form.get('password')
+    password_hash = _hash_password(password)


It looks like MD5 is used as a password hash. MD5 is not considered a secure password hash because it can be cracked by an attacker in a short amount of time. Use a suitable password hashing function such as scrypt. You can use hashlib.scrypt.

View Dataflow Graph

flowchart LR classDef invis fill:white, stroke: none classDef default fill:#e7f5ff, color:#1c7fd6, stroke: none subgraph File0["sql_injection_login.py"] direction LR %% Source subgraph Source direction LR v0["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L47 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 47] hashlib.md5</a>"] end %% Intermediate subgraph Traces0[Traces] direction TB v2["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L47 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 47] md5_pass</a>"] v3["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L18 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 18] _hash_password</a>"] end v2 --> v3 %% Sink subgraph Sink direction LR v1["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L18 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 18] _hash_password(password)</a>"] end end %% Class Assignment Source:::invis Sink:::invis Traces0:::invis File0:::invis %% Connections Source --> Traces0 Traces0 --> Sink

Loading

_{⚪️ This finding does not block your pull request.}
_{Ignore this finding from md5-used-as-password}

Semgrep Assistant suggests the following fix: Use hashlib.scrypt for password hashing instead of MD5.

View step-by-step instructions

Replace the use of MD5 with a more secure hashing algorithm. You can use hashlib.scrypt for password hashing.

Modify the _hash_password function to use hashlib.scrypt instead of hashlib.md5. For example:
import os import hashlib def _hash_password(password): salt = os.urandom(16) scrypt_pass = hashlib.scrypt(password.encode('utf-8'), salt=salt, n=16384, r=8, p=1) return scrypt_pass

Ensure that the salt is stored alongside the hash in your database, as it is needed for verifying passwords later.

Update any code that verifies passwords to use hashlib.scrypt with the stored salt to check the password against the stored hash.

This code change should be a good starting point:

Suggested change

password_hash = _hash_password(password)

import os

import hashlib

def _hash_password(password):

# Generate a random salt

salt = os.urandom(16)

# Use scrypt for hashing the password with the generated salt

scrypt_pass = hashlib.scrypt(password.encode('utf-8'), salt=salt, n=16384, r=8, p=1)

# Return both the salt and the hash, as the salt is needed for verification

return salt + scrypt_pass

_{Leave feedback with a 👍 / 👎. Save a memory with /remember <your custom instructions>.}

private-semgrep-app · 2024-11-26T21:56:47Z

sql_injection_login.py

+    password = form.get('password')
+    password_hash = _hash_password(password)
+
+    sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"


Detected user input used to manually construct a SQL string. This is usually bad practice because manual construction could accidentally result in a SQL injection. An attacker could use a SQL injection to steal or modify contents of the database. Instead, use a parameterized query which is available by default in most database engines. Alternatively, consider using the Django object-relational mappers (ORM) instead of raw SQL queries.

View Dataflow Graph

flowchart LR classDef invis fill:white, stroke: none classDef default fill:#e7f5ff, color:#1c7fd6, stroke: none subgraph File0["sql_injection_login.py"] direction LR %% Source subgraph Source direction LR v0["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L14 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 14] request.form</a>"] end %% Intermediate subgraph Traces0[Traces] direction TB v2["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L14 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 14] form</a>"] v3["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L16 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 16] username</a>"] end v2 --> v3 %% Sink subgraph Sink direction LR v1["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L20 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 20] f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"</a>"] end end %% Class Assignment Source:::invis Sink:::invis Traces0:::invis File0:::invis %% Connections Source --> Traces0 Traces0 --> Sink

Loading

_{⚪️ This finding does not block your pull request.}
_{Ignore this finding from tainted-sql-string}

Semgrep Assistant suggests the following fix: Use parameterized queries instead of string interpolation to prevent SQL injection.

View step-by-step instructions

Replace the SQL query string with a parameterized query to prevent SQL injection. Change the line sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'" to sql = "SELECT * FROM users WHERE username=%s AND password=%s".

Pass the parameters as a tuple to the execute_read method. Update the call to db_result = app.db_helper.execute_read(sql, (username, password_hash)).

Ensure that your database helper method execute_read supports parameterized queries. If it uses a library like psycopg2 or MySQLdb, it should already support this.

This code change should be a good starting point:

Suggested change

sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"

def sql_injection_login_api(request, app):

form = request.form

username = form.get('username')

password = form.get('password')

password_hash = _hash_password(password)

# Use parameterized query to prevent SQL injection

sql = "SELECT * FROM users WHERE username=%s AND password=%s"

# Pass parameters as a tuple

db_result = app.db_helper.execute_read(sql, (username, password_hash))

user = list(

map(

lambda u: {

'id': u[0],

'username': u[1],

'password': u[2]

},

db_result

)

)[0] if len(db_result) > 0 else None

return render_template(

'sql_injection/login.html',

sql=sql,

logged=user is not None

)

_{Leave feedback with a 👍 / 👎. Save a memory with /remember <your custom instructions>.}

private-semgrep-app · 2024-11-26T21:56:47Z

sql_injection_login.py

+
+
+def _hash_password(password):
+    md5_pass = hashlib.md5(password.encode('utf-8')).hexdigest()


Detected MD5 hash algorithm which is considered insecure. MD5 is not collision resistant and is therefore not suitable as a cryptographic signature. Use SHA256 or SHA3 instead.

_{⚪️ This finding does not block your pull request.}
_{Ignore this finding from insecure-hash-algorithm-md5}

Semgrep Assistant suggests the following fix: Use SHA-256 instead of MD5 for hashing passwords.

View step-by-step instructions

Replace the MD5 hashing algorithm with a more secure algorithm such as SHA-256. Change the line md5_pass = hashlib.md5(password.encode('utf-8')).hexdigest() to sha256_pass = hashlib.sha256(password.encode('utf-8')).hexdigest().

Update the return statement in the _hash_password function to return sha256_pass instead of md5_pass. This means changing return md5_pass to return sha256_pass.

Using SHA-256 provides better security because it is more resistant to collision attacks compared to MD5.

This code change should be a good starting point:

Suggested change

md5_pass = hashlib.md5(password.encode('utf-8')).hexdigest()

def _hash_password(password):

sha256_pass = hashlib.sha256(password.encode('utf-8')).hexdigest()

return sha256_pass

_{Leave feedback with a 👍 / 👎. Save a memory with /remember <your custom instructions>.}

private-semgrep-app · 2024-11-26T21:56:48Z

sql_injection_login.py

+    sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"
+    sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"
+    sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"
+    sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"


Detected user input used to manually construct a SQL string. This is usually bad practice because manual construction could accidentally result in a SQL injection. An attacker could use a SQL injection to steal or modify contents of the database. Instead, use a parameterized query which is available by default in most database engines. Alternatively, consider using the Django object-relational mappers (ORM) instead of raw SQL queries.

View Dataflow Graph

flowchart LR classDef invis fill:white, stroke: none classDef default fill:#e7f5ff, color:#1c7fd6, stroke: none subgraph File0["sql_injection_login.py"] direction LR %% Source subgraph Source direction LR v0["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L14 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 14] request.form</a>"] end %% Intermediate subgraph Traces0[Traces] direction TB v2["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L14 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 14] form</a>"] v3["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L16 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 16] username</a>"] end v2 --> v3 %% Sink subgraph Sink direction LR v1["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L23 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 23] f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"</a>"] end end %% Class Assignment Source:::invis Sink:::invis Traces0:::invis File0:::invis %% Connections Source --> Traces0 Traces0 --> Sink

Loading

_{⚪️ This finding does not block your pull request.}
_{Ignore this finding from tainted-sql-string}

Semgrep Assistant suggests the following fix: Use parameterized queries instead of manually constructing SQL strings.

View step-by-step instructions

Replace the SQL string construction with a parameterized query to prevent SQL injection.

Use a parameterized query syntax provided by your database library. For example, if using a library like sqlite3, you can use placeholders like ? or named placeholders like :username.

Modify the SQL query to use placeholders: sql = "SELECT * FROM users WHERE username=:username AND password=:password_hash".

Pass the parameters as a dictionary to the execute_read method: db_result = app.db_helper.execute_read(sql, {"username": username, "password_hash": password_hash}).

This change ensures that user inputs are safely handled by the database engine, preventing SQL injection attacks.

This code change should be a good starting point:

Suggested change

sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"

sql = "SELECT * FROM users WHERE username=:username AND password=:password_hash"

db_result = app.db_helper.execute_read(sql, {"username": username, "password_hash": password_hash})

_{Leave feedback with a 👍 / 👎. Save a memory with /remember <your custom instructions>.}

private-semgrep-app · 2024-11-26T21:56:49Z

sql_injection_login.py

+
+
+def _hash_password(password):
+    md5_pass = hashlib.md5(password.encode('utf-8')).hexdigest()


It looks like MD5 is used as a password hash. MD5 is not considered a secure password hash because it can be cracked by an attacker in a short amount of time. Use a suitable password hashing function such as scrypt. You can use hashlib.scrypt.

View Dataflow Graph

flowchart LR classDef invis fill:white, stroke: none classDef default fill:#e7f5ff, color:#1c7fd6, stroke: none subgraph File0["sql_injection_login.py"] direction LR %% Source subgraph Source direction LR v0["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L47 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 47] hashlib.md5</a>"] end %% Intermediate %% Sink subgraph Sink direction LR v1["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L47 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 47] hashlib.md5(password.encode('utf-8')).hexdigest()</a>"] end end %% Class Assignment Source:::invis Sink:::invis File0:::invis %% Connections Source --> Sink

Loading

_{⚪️ This finding does not block your pull request.}
_{Ignore this finding from md5-used-as-password}

Semgrep Assistant suggests the following fix: Use hashlib.scrypt with a secure salt instead of MD5 for password hashing.

View step-by-step instructions

Replace the MD5 hashing function with a more secure hashing function. You can use hashlib.scrypt for this purpose.

Modify the _hash_password function to use hashlib.scrypt. First, import os and hashlib at the top of your file if they are not already imported.

Generate a salt using os.urandom(16) and store it securely. For demonstration, you can use salt = os.urandom(16).

Update the _hash_password function to use scrypt as follows:
def _hash_password(password): salt = os.urandom(16) scrypt_pass = hashlib.scrypt(password.encode('utf-8'), salt=salt, n=16384, r=8, p=1) return scrypt_pass.hex()

Ensure that the salt is stored alongside the hashed password in your database, as it will be needed for password verification.

Update any password verification logic to use the same scrypt parameters and the stored salt to verify passwords.

This code change should be a good starting point:

Suggested change

md5_pass = hashlib.md5(password.encode('utf-8')).hexdigest()

import os

import hashlib

def _hash_password(password):

# Generate a secure random salt

salt = os.urandom(16)

# Use scrypt for password hashing with the generated salt

scrypt_pass = hashlib.scrypt(password.encode('utf-8'), salt=salt, n=16384, r=8, p=1)

# Return the salt and hashed password as a hex string

return salt.hex() + scrypt_pass.hex()

_{Leave feedback with a 👍 / 👎. Save a memory with /remember <your custom instructions>.}

private-semgrep-app · 2024-11-26T21:56:50Z

sql_injection_login.py

+
+    sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"
+    sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"
+    sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"


Detected user input used to manually construct a SQL string. This is usually bad practice because manual construction could accidentally result in a SQL injection. An attacker could use a SQL injection to steal or modify contents of the database. Instead, use a parameterized query which is available by default in most database engines. Alternatively, consider using the Django object-relational mappers (ORM) instead of raw SQL queries.

View Dataflow Graph

flowchart LR classDef invis fill:white, stroke: none classDef default fill:#e7f5ff, color:#1c7fd6, stroke: none subgraph File0["sql_injection_login.py"] direction LR %% Source subgraph Source direction LR v0["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L14 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 14] request.form</a>"] end %% Intermediate subgraph Traces0[Traces] direction TB v2["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L14 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 14] form</a>"] v3["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L16 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 16] username</a>"] end v2 --> v3 %% Sink subgraph Sink direction LR v1["<a href=https://github.com/bandarisantosh/bad-python-app/commit/94974cb05250d6f66c19ce59611530fbf6942c86/sql_injection_login.py#L22 target=_blank style='text-decoration:none; color:#1c7fd6'>[Line: 22] f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"</a>"] end end %% Class Assignment Source:::invis Sink:::invis Traces0:::invis File0:::invis %% Connections Source --> Traces0 Traces0 --> Sink

Loading

_{⚪️ This finding does not block your pull request.}
_{Ignore this finding from tainted-sql-string}

Semgrep Assistant suggests the following fix: Use parameterized queries instead of manually constructing SQL strings.

View step-by-step instructions

Replace the SQL query string with a parameterized query to prevent SQL injection. Change the line sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'" to sql = "SELECT * FROM users WHERE username=%s AND password=%s".

Pass the parameters username and password_hash as a tuple to the execute_read method. Update the call to db_result = app.db_helper.execute_read(sql, (username, password_hash)).

Ensure that the execute_read method in your database helper supports parameterized queries. If it doesn't, modify it to use parameterized queries with your database library (e.g., using cursor.execute(sql, params) in a library like psycopg2 for PostgreSQL).

This code change should be a good starting point:

Suggested change

sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"

sql = "SELECT * FROM users WHERE username=%s AND password=%s"

db_result = app.db_helper.execute_read(sql, (username, password_hash))

_{Leave feedback with a 👍 / 👎. Save a memory with /remember <your custom instructions>.}

Add files via upload

94974cb

private-semgrep-app bot reviewed Nov 26, 2024

View reviewed changes

	sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"
	sql = "SELECT * FROM users WHERE username=:username AND password=:password"
	db_result = app.db_helper.execute_read(sql, {"username": username, "password": password_hash})

	flask.render_template_string(username)
	return render_template('your_template.html', username=username)

-    password_hash = _hash_password(password)
+    import os
+    import hashlib
+    def _hash_password(password):
+        # Generate a random salt
+        salt = os.urandom(16)
+        # Use scrypt for hashing the password with the generated salt
+        scrypt_pass = hashlib.scrypt(password.encode('utf-8'), salt=salt, n=16384, r=8, p=1)
+        # Return both the salt and the hash, as the salt is needed for verification
+        return salt + scrypt_pass

-    sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password_hash}'"
+    def sql_injection_login_api(request, app):
+        form = request.form
+        username = form.get('username')
+        password = form.get('password')
+        password_hash = _hash_password(password)
+        # Use parameterized query to prevent SQL injection
+        sql = "SELECT * FROM users WHERE username=%s AND password=%s"
+        # Pass parameters as a tuple
+        db_result = app.db_helper.execute_read(sql, (username, password_hash))
+        user = list(
+            map(
+                lambda u: {
+                    'id': u[0],
+                    'username': u[1],
+                    'password': u[2]
+                },
+                db_result
+            )
+        )[0] if len(db_result) > 0 else None
+        return render_template(
+            'sql_injection/login.html',
+            sql=sql,
+            logged=user is not None
+        )



		def _hash_password(password):
		md5_pass = hashlib.md5(password.encode('utf-8')).hexdigest()

Conversation

bandarisantosh commented Nov 26, 2024

Uh oh!

private-semgrep-app bot Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

private-semgrep-app bot Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

private-semgrep-app bot Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

private-semgrep-app bot Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

private-semgrep-app bot Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

private-semgrep-app bot Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

private-semgrep-app bot Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

private-semgrep-app bot Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

private-semgrep-app bot Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

private-semgrep-app bot Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

private-semgrep-app bot Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

private-semgrep-app bot Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

private-semgrep-app bot Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

private-semgrep-app bot Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

private-semgrep-app bot Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

private-semgrep-app bot Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant