Skip to content
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.

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

Update dependency org.liquibase:liquibase-core to v4.11.0 #4287

Merged
merged 2 commits into from
May 25, 2022

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented May 25, 2022

WhiteSource Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
org.liquibase:liquibase-core (source) 4.10.0 -> 4.11.0 age adoption passing confidence

Release Notes

liquibase/liquibase

v4.11.0

Compare Source

Liquibase 4.11 release

Please report any issues to https://github.com/liquibase/liquibase/issues.

Breaking Changes

Starting with 4.11, we moved the global libraries we ship with the CLI from the lib directory to a new internal directory structure. The lib directory is still included in the classpath as the place users can add whatever additional global drivers/libraries they need.

The liquibase --version output has been enhanced to also include the 3rd party libraries being used and their versions.

Impacts:

  • If you are upgrading Liquibase by overwriting an existing directory, you will have duplicate libraries between lib and internal/lib. You should manually delete any files in lib which you did not add yourself. Liquibase will continue to work even with the duplicate libraries, but you may not be running the latest version of ones we ship, since the lib files take priority over what is in internal/lib. New installs are not impacted by this.
  • If you have any automation that did anything with our shipped files in lib you will need to update it to reflect the new internal/lib location

For security reasons, we have also changed what is logged by the CLI to only log liquibase channel messages by default, rather than all log channels. If you are relying on logging from non-Liquibase libraries, you can add channels with the new --log-channels flag, including --log-channels=all to restore the old functionality.

Enhancements
Fixes
Updates
Security Updates
  • No security updates needed in this release
JDBC Driver and Third-Party Library Updates
OWASP Dependency Check: Reported Vulnerabilities
New Contributors

Full Changelog: liquibase/liquibase@v4.10.0...v4.11.0


Configuration

📅 Schedule: At any time (no schedule defined).

🚦 Automerge: Enabled.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by WhiteSource Renovate. View repository job log here.

@secureflag-knowledge-base
Copy link

SQL Injection

Click here to find a SQL Injection training lab

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.

View this in the SecureFlag Knowledge Base

@secure-code-warrior-for-github

Micro-Learning Topic: SQL injection (Detected by phrase)

Matched on "SQLi"

What is this? (2min video)

This is probably one of the two most exploited vulnerabilities in web applications and has led to a number of high profile company breaches. It occurs when an application fails to sanitize or validate input before using it to dynamically construct a statement. An attacker that exploits this vulnerability will be able to gain access to the underlying database and view or modify data without permission.

Try this challenge in Secure Code Warrior

@secure-code-warrior-for-github

Micro-Learning Topic: Injection attack (Detected by phrase)

Matched on "Injection attack"

Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. Source: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Try this challenge in Secure Code Warrior

@pethers pethers merged commit 2783b72 into master May 25, 2022
@renovate renovate bot deleted the renovate/org.liquibase-liquibase-core-4.x branch May 25, 2022 05:11
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants