Migrate atlas-web-core to the new skeleton-project for bulk

[ke4]

In this task I have to migrate our existing common library for Bulk and Single Cell Atlas to our new SpringBoot based project and fix all the broken code that might happen because of Java and Spring Framework version changes.

Steps:

• Create a new GitHub repository
• Copy the necessary source code to our new SpringBoot project
• Fix the dependency issues
• Fix the broken code that might be caused by various version changes of dependencies
  • Almost done, some test assertion related codes need to be refactored, but for that I need to be able to execute the tests
• HandlerInterceptorAdapter is deprecated in Spring 5.3 and has been removed in Spring 6
• Need to check the correct use of annotations:
  • @Inject ----> @Autowired
  • @nAmed ----> @controller
• HtmlExceptionHandlingController looks like is not used and its env variable is @Autowired but it looks like that is not a proper bean
• Execute all the test of the app
• Consider to remove the org.jetbrains:annotations library as a dependency if we are only using the @NotNull annotation

At the end of this task we should be able to execute successfully all the tests based on this library.

[ke4]

New repo has ben created: https://github.com/ebi-gene-expression-group/atlas-web-core2

[ke4]

Need to check the correct use of @Inject and @Autowired annotations.
I am going to add this with a checkbox to the ticket's description.

[ke4]

The same as the above with @nAmed ---> @component

[ke4]

org.apache.solr:solr-core:8.7.0 has 10 vulnerabilities.

It looks like that we should have update to 9.x branch, but we just updated and replace 7.x last year.
We would have to do it in our servers, too.

I am going to postpone this change for later.

Here is the full report:

Dependency maven:org.apache.solr:solr-core:8.7.0 is vulnerable

Upgrade to 9.7.0

CVE-2021-27905, Score: 9.8

The ReplicationHandler (normally registered at "/replication" under a Solr core) in Apache Solr has a "masterUrl" (also "leaderUrl" alias) parameter that is used to designate another ReplicationHandler on another Solr core to replicate index data into the local core. To prevent a SSRF vulnerability, Solr ought to check these parameters against a similar configuration it uses for the "shards" parameter. Prior to this bug getting fixed, it did not. This problem affects essentially all Solr versions prior to it getting fixed in 8.8.2.

Read More: https://www.mend.io/vulnerability-database/CVE-2021-27905?utm_source=JetBrains

CVE-2021-44548, Score: 9.8

An Improper Input Validation vulnerability in DataImportHandler of Apache Solr allows an attacker to provide a Windows UNC path resulting in an SMB network call being made from the Solr host to another host on the network. If the attacker has wider access to the network, this may lead to SMB attacks, which may result in: * The exfiltration of sensitive data such as OS user hashes (NTLM/LM hashes), * In case of misconfigured systems, SMB Relay Attacks which can lead to user impersonation on SMB Shares or, in a worse-case scenario, Remote Code Execution This issue affects all Apache Solr versions prior to 8.11.1. This issue only affects Windows.

Read More: https://www.mend.io/vulnerability-database/CVE-2021-44548?utm_source=JetBrains

CVE-2024-45216, Score: 9.8

Solr instances using the PKIAuthenticationPlugin, which is enabled by default when Solr Authentication is used, are vulnerable to Authentication bypass.
A fake ending at the end of any Solr API URL path, will allow requests to skip Authentication while maintaining the API contract with the original URL Path. This fake ending looks like an unprotected API path, however it is stripped off internally after authentication but before API routing.

Read More: https://www.mend.io/vulnerability-database/CVE-2024-45216?utm_source=JetBrains

CVE-2021-29943, Score: 9.1

When using ConfigurableInternodeAuthHadoopPlugin for authentication, Apache Solr versions prior to 8.8.2 would forward/proxy distributed requests using server credentials instead of original client credentials. This would result in incorrect authorization resolution on the receiving hosts.

Read More: https://www.mend.io/vulnerability-database/CVE-2021-29943?utm_source=JetBrains

CVE-2023-50386, Score: 8.8

Improper Control of Dynamically-Managed Code Resources, Unrestricted Upload of File with Dangerous Type, Inclusion of Functionality from Untrusted Control Sphere vulnerability in Apache Solr.This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9.0.0 before 9.4.1.

In the affected versions, Solr ConfigSets accepted Java jar and class files to be uploaded through the ConfigSets API.
When backing up Solr Collections, these configSet files would be saved to disk when using the LocalFileSystemRepository (the default for backups).
If the backup was saved to a directory that Solr uses in its ClassPath/ClassLoaders, then the jar and class files would be available to use with any ConfigSet, trusted or untrusted.

When Solr is run in a secure way (Authorization enabled), as is strongly suggested, this vulnerability is limited to extending the Backup permissions with the ability to add libraries.
Users are recommended to upgrade to version 8.11.3 or 9.4.1, which fix the issue.
In these versions, the following protections have been added:

• Users are no longer able to upload files to a configSet that could be executed via a Java ClassLoader.
• The Backup API restricts saving backups to directories that are used in the ClassLoader.

Read More: https://www.mend.io/vulnerability-database/CVE-2023-50386?utm_source=JetBrains

CVE-2021-29262, Score: 7.5

When starting Apache Solr versions prior to 8.8.2, configured with the SaslZkACLProvider or VMParamsAllAndReadonlyDigestZkACLProvider and no existing security.json znode, if the optional read-only user is configured then Solr would not treat that node as a sensitive path and would allow it to be readable. Additionally, with any ZkACLProvider, if the security.json is already present, Solr will not automatically update the ACLs.

Read More: https://www.mend.io/vulnerability-database/CVE-2021-29262?utm_source=JetBrains

CVE-2023-50291, Score: 7.5

Insufficiently Protected Credentials vulnerability in Apache Solr.

This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9.0.0 before 9.3.0.
One of the two endpoints that publishes the Solr process' Java system properties, /admin/info/properties, was only setup to hide system properties that had "password" contained in the name.
There are a number of sensitive system properties, such as "basicauth" and "aws.secretKey" do not contain "password", thus their values were published via the "/admin/info/properties" endpoint.
This endpoint populates the list of System Properties on the home screen of the Solr Admin page, making the exposed credentials visible in the UI.

This /admin/info/properties endpoint is protected under the "config-read" permission.
Therefore, Solr Clouds with Authorization enabled will only be vulnerable through logged-in users that have the "config-read" permission.
Users are recommended to upgrade to version 9.3.0 or 8.11.3, which fixes the issue.
A single option now controls hiding Java system property for all endpoints, "-Dsolr.hiddenSysProps".
By default all known sensitive properties are hidden (including "-Dbasicauth"), as well as any property with a name containing "secret" or "password".

Users who cannot upgrade can also use the following Java system property to fix the issue:
'-Dsolr.redaction.system.pattern=.(password|secret|basicauth).'

Read More: https://www.mend.io/vulnerability-database/CVE-2023-50291?utm_source=JetBrains

CVE-2023-50298, Score: 7.5

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Solr.This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9.0.0 before 9.4.1.

Solr Streaming Expressions allows users to extract data from other Solr Clouds, using a "zkHost" parameter.
When original SolrCloud is setup to use ZooKeeper credentials and ACLs, they will be sent to whatever "zkHost" the user provides.
An attacker could setup a server to mock ZooKeeper, that accepts ZooKeeper requests with credentials and ACLs and extracts the sensitive information,
then send a streaming expression using the mock server's address in "zkHost".
Streaming Expressions are exposed via the "/streaming" handler, with "read" permissions.

Users are recommended to upgrade to version 8.11.3 or 9.4.1, which fix the issue.
From these versions on, only zkHost values that have the same server address (regardless of chroot), will use the given ZooKeeper credentials and ACLs when connecting.

Read More: https://www.mend.io/vulnerability-database/CVE-2023-50298?utm_source=JetBrains

CVE-2024-45217, Score: 5.3

Insecure Default Initialization of Resource vulnerability in Apache Solr.

New ConfigSets that are created via a Restore command, which copy a configSet from the backup and give it a new name,
are created without setting the "trusted" metadata.
ConfigSets that do not contain the flag are trusted implicitly if the metadata is missing, therefore this leads to
"trusted" ConfigSets that may not have been created with an Authenticated request.
"trusted" ConfigSets are able to load custom code into classloaders, therefore the flag is supposed to only be set when
the request that uploads the ConfigSet is Authenticated & Authorized.

Read More: https://www.mend.io/vulnerability-database/CVE-2024-45217?utm_source=JetBrains

Results powered by Mend.io

[ke4]

If we are only using the @NotNull annotation from org.jetbrains:annotations library, then we should consider to refactor it to another @NotNull annotation that provides the same feature.
I am going to leave it now, but add to the list to end end of this ticket.

[ke4]

HtmlExceptionHandlingController looks like is not used and its env variable is @Autowired but it looks like that is not a proper bean.
I added this issue to the main list to check this problem at the end.

[ke4]

HandlerInterceptorAdapter is deprecated in Spring 5.3 and has been removed in Spring 6, which is used in Spring Boot 3. Instead of using HandlerInterceptorAdapter, we should implement the HandlerInterceptor interface directly. This change is necessary due to the deprecation of HandlerInterceptorAdapter in Spring 5.3 and its removal in Spring 6, as Spring moved from the javax to the jakarta root package.

[ke4]

ExperimentAttributesServiceTest has 2 broken assert statement because latestorg.springframework.boot:spring-boot-starter-test has newer version from org.assertj:assertj-core library (3.11.1 -> 3.26.3).
Need to refactor those assert statements.

[ke4]

I am going to continue with the next task: Add atlas-web-bulk for the skeleton project for bulk as it is needed to be done or at least done in a way to be able to execute the tests in the atlas-web-core2 submodule.