[Snyk] Fix for 23 vulnerabilities

[madchap]

This PR was automatically created by Snyk using the credentials of a real user.

Snyk has created this PR to fix one or more vulnerable packages in the `pip` dependencies of this project.

Changes included in this PR

• Changes to the following files to upgrade the vulnerable dependencies to a fixed version:
  • requirements.txt

⚠️ Warning

pyOpenSSL 23.3.0 has requirement cryptography<42,>=41.0.5, but you have cryptography 41.0.3.
celery 5.3.0 requires kombu, which is not installed.

Vulnerabilities that will be fixed

By pinning:

Severity	Priority Score (*)	Issue	Upgrade	Breaking Change	Exploit Maturity
	554/1000 Why? Has a fix available, CVSS 6.8	Insufficient Verification of Data Authenticity SNYK-PYTHON-CERTIFI-3164749	certifi: 2021.10.8 -> 2023.7.22	No	No Known Exploit
	704/1000 Why? Has a fix available, CVSS 9.8	Improper Following of a Certificate's Chain of Trust SNYK-PYTHON-CERTIFI-5805047	certifi: 2021.10.8 -> 2023.7.22	No	No Known Exploit
	369/1000 Why? Has a fix available, CVSS 3.1	Directory Traversal SNYK-PYTHON-DJANGO-1066259	django: 1.11.29 -> 3.2.23	No	No Known Exploit
	379/1000 Why? Has a fix available, CVSS 3.3	Directory Traversal SNYK-PYTHON-DJANGO-1279042	django: 1.11.29 -> 3.2.23	No	No Known Exploit
	579/1000 Why? Has a fix available, CVSS 7.3	HTTP Header Injection SNYK-PYTHON-DJANGO-1290072	django: 1.11.29 -> 3.2.23	No	No Known Exploit
	589/1000 Why? Has a fix available, CVSS 7.5	Directory Traversal SNYK-PYTHON-DJANGO-1298665	django: 1.11.29 -> 3.2.23	No	No Known Exploit
	479/1000 Why? Has a fix available, CVSS 5.3	Access Restriction Bypass SNYK-PYTHON-DJANGO-2312875	django: 1.11.29 -> 3.2.23	No	No Known Exploit
	399/1000 Why? Has a fix available, CVSS 3.7	Directory Traversal SNYK-PYTHON-DJANGO-2329158	django: 1.11.29 -> 3.2.23	No	No Known Exploit
	399/1000 Why? Has a fix available, CVSS 3.7	Information Exposure SNYK-PYTHON-DJANGO-2329159	django: 1.11.29 -> 3.2.23	No	No Known Exploit
	479/1000 Why? Has a fix available, CVSS 5.3	Denial of Service (DoS) SNYK-PYTHON-DJANGO-2329160	django: 1.11.29 -> 3.2.23	No	No Known Exploit
	424/1000 Why? Has a fix available, CVSS 4.2	Cross-site Scripting (XSS) SNYK-PYTHON-DJANGO-2389002	django: 1.11.29 -> 3.2.23	No	No Known Exploit
	589/1000 Why? Has a fix available, CVSS 7.5	Denial of Service (DoS) SNYK-PYTHON-DJANGO-2389021	django: 1.11.29 -> 3.2.23	No	No Known Exploit
	704/1000 Why? Has a fix available, CVSS 9.8	SQL Injection SNYK-PYTHON-DJANGO-2606966	django: 1.11.29 -> 3.2.23	No	No Known Exploit
	811/1000 Why? Proof of Concept exploit, Has a fix available, CVSS 9.8	SQL Injection SNYK-PYTHON-DJANGO-2606969	django: 1.11.29 -> 3.2.23	No	Proof of Concept
	776/1000 Why? Proof of Concept exploit, Has a fix available, CVSS 9.1	SQL Injection SNYK-PYTHON-DJANGO-2940618	django: 1.11.29 -> 3.2.23	No	Proof of Concept
	564/1000 Why? Has a fix available, CVSS 7	Reflected File Download (RFD) SNYK-PYTHON-DJANGO-2968205	django: 1.11.29 -> 3.2.23	No	No Known Exploit
	589/1000 Why? Has a fix available, CVSS 7.5	Denial of Service (DoS) SNYK-PYTHON-DJANGO-3319450	django: 1.11.29 -> 3.2.23	No	No Known Exploit
	479/1000 Why? Has a fix available, CVSS 5.3	Arbitrary File Upload SNYK-PYTHON-DJANGO-5496950	django: 1.11.29 -> 3.2.23	No	No Known Exploit
	589/1000 Why? Has a fix available, CVSS 7.5	Regular Expression Denial of Service (ReDoS) SNYK-PYTHON-DJANGO-5750790	django: 1.11.29 -> 3.2.23	No	No Known Exploit
	589/1000 Why? Has a fix available, CVSS 7.5	Denial of Service (DoS) SNYK-PYTHON-DJANGO-5880505	django: 1.11.29 -> 3.2.23	No	No Known Exploit
	509/1000 Why? Has a fix available, CVSS 5.9	Regular Expression Denial of Service (ReDoS) SNYK-PYTHON-DJANGO-5932095	django: 1.11.29 -> 3.2.23	No	No Known Exploit
	479/1000 Why? Has a fix available, CVSS 5.3	Denial of Service (DoS) SNYK-PYTHON-DJANGO-6041515	django: 1.11.29 -> 3.2.23	No	No Known Exploit
	519/1000 Why? Has a fix available, CVSS 6.1	Information Exposure SNYK-PYTHON-REQUESTS-5595532	requests: 2.27.1 -> 2.31.0	No	No Known Exploit

(*) Note that the real score may have changed since the PR was raised.

Some vulnerabilities couldn't be fully fixed and so Snyk will still find them when the project is tested again. This may be because the vulnerability existed within more than one direct dependency, but not all of the affected dependencies could be upgraded.

Check the changes in this PR to ensure they won't cause issues with your project.

---

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information:
🧐 View latest project report

🛠 Adjust project settings

📚 Read more about Snyk's upgrade and patch logic

---

Learn how to fix vulnerabilities with free interactive lessons:

🦉 Directory Traversal
🦉 Access Restriction Bypass
🦉 Denial of Service (DoS)
🦉 More lessons are available in Snyk Learn

[secureflag-knowledge-base]

SQL Injection

Play Labs on this vulnerability with SecureFlag!

Description

A SQL Injection is not a new or overly complicated type of attack, yet it continues to sit atop the OWASP Top Ten Application Security Risks after more than 20 years of it having been publicly utilized. This is primarily due to its inherent relative ease of use, coupled with its severity of impact when directed toward the staggeringly high number of websites with poorly written, vulnerable code.

SQL is a query language that is designed to access, modify, and delete data stored in relational databases. Numerous web applications and websites use SQL databases as their method of data storage. Applications with a higher prevalence of older functional interfaces such as PHP and ASP are relatively more susceptible to SQL Injection flaws than applications based on more recent technologies.

Applications are vulnerable to attacks when user-supplied data is not validated, filtered for escape characters or sanitized by the application.

An attacker can use SQL Injection to manipulate an SQL query via the input data from the client to the application, thus forcing the SQL server to execute an unintended operation constructed using untrusted input.

Read more

Impact

A successful SQL Injection attack can result in a malicious user gaining complete access to all data in a database server with the ability to execute unauthorized SQL queries and compromise the confidentiality, integrity, and availability of the application. Depending on the backend DBMS used and the permissions granted to the user on the database, a SQL Injection could result in arbitrary file read/write and even remote code execution.

The severity of attacks that have leveraged SQL Injection should not be understated. Notorious breaches, including the devastating and internationally renowned hacks of Sony Pictures and LinkedIn, for example, are reported to have been executed using SQL Injection.

Scenarios

Subverting application logic through SQL can lead to unpredictable outcomes depending on the context of the SQL statement the strategy of the attacker.

There are well-known exploitation techniques that attackers leverage depending on the vulnerability within the implementation of the code:

• Manipulating an SQL query logic to bypass access controls.
• Retrieving hidden data to return additional results, including data from other tables within the databases, e.g., leveraging the UNION keyword.
• Executing arbitrary SQL code in the context of the database whether stacked queries are allowed.
• Accessing files and executing commands in the operating system, depending on the vulnerable code and the database management system.

It is called blind SQL Injection when the injection succeeds, but the code doesn't return the result of the manipulated query to the attacker. Blind injections are still exploitable to retrieve the content using timing analysis, content analysis, or other out-of-bound techniques.

The following is a classic example of subverting application logic to bypass access controls.

Usernames and passwords are ubiquitous as the method for logging into applications. In this benign scenario, a user submits the username user and the password secret. The application then performs a SQL query to verify the credentials:

SELECT * FROM users WHERE username = 'user' AND password = 'secret'

The login is successful if the query returns the details of the user. If the query doesn't return the user details, it is rejected.

By leveraging single quotes and SQL comments (--), it is possible to log in as any user without a password, as the password check from the WHERE clause is removed from the query.

The following example illustrates this in action. By entering administrator'-- in the username field and leaving the password field blank, the SQL statement would result as the following:

SELECT * FROM users WHERE username = 'administrator'--' AND password = '

The database evaluates this statement without the commented out part, executing just the first part:

SELECT * FROM users WHERE username = 'administrator'

Since the manipulated query always returns the details of the administrator user, the attacker can successfully log in without knowing the correct password.

Prevention

To avoid SQL Injection vulnerabilities, developers need to use parameterized queries, specifying placeholders for parameters so that they are not considered as a part of the SQL command; rather, as solely data by the database.

When working with legacy systems, developers need to escape inputs before adding them to the query. Object Relational Mappers (ORMs) make this easier for the developer; however, they are not a panacea, with the underlying mitigations still entirely relevant: untrusted data needs to be validated, query concatenation should be avoided unless absolutely necessary, and minimizing unnecessary SQL account privileges is crucial.

Testing

Verify that where parameterized or safer mechanisms are not present, context-specific output encoding is used to protect against injection attacks, such as the use of SQL escaping to protect against SQL Injection.

• OWASP ASVS: 5.3.5
• OWASP Testing Guide: Testing for SQL Injection

View this in the SecureFlag Knowledge Base