Openlogic 彙整 - 頁9，共10

Preparing for Your Next Tomcat Upgrade

Planning an Apache Tomcat upgrade (or migrating to the latest version of Tomcat) can pose challenges to unsuspecting enterprises. But Tomcat migrations and upgrades are key to maintaining security and to unlocking the potential of newly-supported features and improvements found in later versions of Tomcat.

In this blog, we look at how to prepare for your next Tomcat upgrade, with details on the Tomcat community support lifecycle, considerations like how often enterprises should be upgrading/migrating, and the basic steps of performing an Apache Tomcat migration or upgrade.

Editor’s Note: This blog was originally published in 2022 and was updated in 2024.

Understanding the Apache Tomcat Lifecycle

There are two active branches of Tomcat at the time of this writing: 9 and 10. Tomcat 8.5 reached end of life (EOL) on March 31, 2024. The Tomcat community typically does a good job of communicating end of life at least a year in advance for versions going EOL. These EOL announcements are typically accompanied by news regarding the next major version; the Tomcat 8.5 EOL date was announced around the same time as information about Tomcat 11 first emerged.

Tomcat Version	Release Date	End of Community Support
6.0	February 28, 2007	December 31, 2012
7.0	January 14, 2011	March 31, 2021
8.0	June 25, 2014	June 30, 2018
8.5	June 13, 2016	March 31, 2024
9.0	January 18, 2018	TBD
10.0	February 2, 2021	TBD

Ultimately, which branch you choose is likely based on what version of Java you’re using along with it. The Tomcat website has a reference chart to help you figure out what versions of Java work with what versions of Tomcat.

What to Consider Before Your Apache Tomcat Migration or Upgrade

If you happen to be upgrading in the same major branch versions, your configuration file will likely transfer easily in between versions. This means your testing of minor releases should be relatively pain free and not take a lot of time and resources from your team.

Migrating from a major version to another, however, requires that you rewrite your configuration based around all the major changes incorporated into the new major version. Testing for this will take a greater amount of time and resources due to the nature of there being significant changes between major versions of Tomcat.

Reading the release notes is going to provide you with an overview of what to expect. Because of this, we advise you pick the newest version of Tomcat that you can, so that you get the longest range of time of support from the Apache community.

How Often Should You Upgrade Tomcat?

Some apps function so smoothly, we set them out in production and they do their job so well, that touching it becomes almost out of the question because if it isn’t broken, does it need fixing? That is a complicated question, because the answer can be circumstantial. If the app and infrastructure around it are all working soundly, you may not see any reason to do a minor upgrade. But then one day, you hear from the community that there is a CVE or more relating to a version that you’re currently using. Now, there’s a motivating factor to remediate the security issue. Keeping up with the security of Tomcat is important for anyone using it in a production environment, and the longer you wait to upgrade or migrate, the less smoothly things are likely to go.

How Often Should You Migrate to a New Tomcat Version?

Migrating to a newer Tomcat branch is a trickier task, since bringing over your configuration from the previous branch will not work. Migration will require significant testing to verify that your code will work with the app server. The more moving parts in play the greater the risk of older apps not being fully compatible.

Knowing the EOL dates ahead of time is going to give your organization the necessary heads up of when they will have a greater need to migrate.

Tomcat’s website states that on average a major release of Tomcat is good for 10 years. This is a significant window by comparison to other known application servers, giving your organization time to plan accordingly. Apache has also written specific documentation for migrating.

Back to top

How to Prepare for Your Next Apache Tomcat Upgrade / Migration

The very first thing to do before migration is to take back ups of everything. Document what sort of changes you’re going to be making to the environment so that you have an accurate account for everything you’re going to do. Going over metrics of when the app is in use will allow you to know when the best time to perform the migration is.

Step #1: Determine Your Migration / Upgrade Path

Determine which version of Tomcat you will be upgrading to, along with the required version of Java that Tomcat requires. Read the release notes to see what sort of major changes you’ll be dealing with, as it might also give you insight to the new features available as well.

Step #2: Complete a Test Install and Compare Configuration Files

Using the same OS that you will be deploying your app on, set up the version of Tomcat you will be upgrading to in a test environment. Testing is critical for migration and is still a good practice for upgrades as well. One of the tests that you can run is a git command that compares configuration files against one another. An example of this command would look something like:

git diff 10.1.0-M1 10.1.0-M2 -- conf/

Step #3: Configure Your Test Install and Deploy Your Application to Test Environment

Configure your Tomcat instance and see if you can deploy your application in the test environment. Once you have your app up and running, you’ll want to do some testing to make sure it can handle the standard work load it’ll be under in production. The method you use to generate traffic to the server will vary depending on the type of application you’re running. It’s advised you push your server past the point that it might hit in production to prepare for any upticks in traffic.

Step #4: Bring Test Environment to Production and Gradually Transition Workloads

Once you’ve done thorough testing of workloads on the new server, you’ll want to schedule time to bring your environment to production. The best practice is to stand the new servers up alongside the production servers, allow traffic to the new environment while maintaining the older live environment. When you’ve established that the new servers can properly handle live workloads, you may then take down the older servers one at a time, making sure that the new live servers are able to handle the workload gradually.

Back to top

Final Thoughts

With enough planning — and a proper test environment and traffic tools — you should be able to properly plan a fairly stress-free Tomcat upgrade or migration. While Tomcat versions are good for roughly ten years, there are performance gains and new features to be had when you decide to migrate or upgrade to a newer version. Upgrading and migrating should be a regular part of every organizations maintenance plan and is also critical for preventing exposure to security vulnerabilities.

About Version 2 Digital

Version 2 Digital is one of the most dynamic IT companies in Asia. The company distributes a wide range of IT products across various areas including cyber security, cloud, data protection, end points, infrastructures, system monitoring, storage, networking, business productivity and communication products.

Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, different vertical industries, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.

About Perforce
The best run DevOps teams in the world choose Perforce. Perforce products are purpose-built to develop, build and maintain high-stakes applications. Companies can finally manage complexity, achieve speed without compromise, improve security and compliance, and run their DevOps toolchains with full integrity. With a global footprint spanning more than 80 countries and including over 75% of the Fortune 100, Perforce is trusted by the world’s leading brands to deliver solutions to even the toughest challenges. Accelerate technology delivery, with no shortcuts.

OpenLogic 2024

Apache Tomcat Security Best Practices

In this blog, we look at eight ways to improve your Apache Tomcat security hardening, ranging from basic best practices like not running your Tomcat as the root user, to more advanced tips like using realms to control resource access. At the end of the blog, we’ll wrap up with some final thoughts about how to secure Tomcat and then link to some related resources you should check out. Let’s dive in!

Editor’s Note: This blog was originally published on December 29, 2020 and was revised and updated with new content on September 3, 2024.

Why You Need to Secure Tomcat

Apache Tomcat is a robust application server that includes many features available right out of the box. However, just because these features and settings are available right away doesn’t mean that your Tomcat server is ready for production. Before you go to production, you need to perform thorough tuning and security hardening to ensure your Tomcat server is secure.

Back to top

How to Keep Your Tomcat Secure: 8 Tomcat Security Hardening Tips

There are many ways to improve Apache Tomcat security, and this blog is no replacement for a thorough dive into the possible ways in which you can do so. However, the tips below are a good starting point for people interested in hardening their Tomcat server deployment.

1. Don’t Run Tomcat as the Root User

The root or administrator account has access to everything in the file system. It is best practice to create a separate account that has read, write, and execute access to the Tomcat installation directory and specific folders the application needs access to. Grant this account minimum operating system permissions.

Vulnerabilities are exposed periodically with Tomcat releases and updates to your application and any frameworks your application uses. Fixes for these vulnerabilities are provided rapidly by the community, but it can give an attacker a small window of time to do something malicious.

2. Default Samples and Test Applications

There are four web applications that come out of the box with Apache Tomcat:

docs: This is the documentation for Apache Tomcat. This is a duplicate of the documentation you will find on Apache Tomcat’s website.
examples: This is servlet, JSP, and WebSocket examples along with the source code that runs those examples.
manager: This is the Tomcat Web Application Manager application that enables you to administer the application server via a user interface. You need the role “manager-gui” to access this application.
host-manager: This is the Tomcat Virtual Host Manager is a web application that allows users to manage virtual hosts. Virtual hosts allow you to deploy multiple websites (or domains) in single instance of a Tomcat server. The “admin-gui” role is required to access this application.

You can remove these four applications and still have a fully functional application server, but by default they are only accessible by the machine they are running on. You can change this behavior in each application’s META-INF/context.xml (more on this later).

The examples application does have some vulnerabilities (session manipulation) and should be removed from any production environment. The docs application should be removed because it identifies to a potential attacker what application server and version you are running.

The manager and host-manager applications can remain on the Tomcat instance, but these applications should be locked down by setting the proper permissions using roles in tomcat-users.xml and setting a very strict Remote Host or CIDR Valve in the applications META-INF/context.xml file.

3. Set Your Tomcat Permissions Carefully

The SecurityManager in Jakarta EE 11 has finally been removed, so you will not find a conf/catalina.policy for Apache Tomcat versions 11 and greater. This file controlled an application’s permissions to internal Catalina jars and classes.

If you are running a version of Tomcat prior to version 11, then a review of this file would be worthwhile. Most of our customers do not touch this file, and fortunately the format of this policy file is self-documenting and easy to read. If you compare the catalina.policy with the out of the box unmodified file, then you can identify any changes easily.

4. Upgrade to Tomcat 11

Apache Tomcat 11 (currently in beta but we expect the GA release any day now) includes security enhancements and implements six specifications of Jakarta EE 11, which also includes additional enhancements to Tomcat including:

Removing sensitive HTTP headers from TRACE requests
Mandatory HTTPS support
Updated HTTP RFC references to the latest versions
Examples and documentation web applications are only accessible from localhost by default as this might expose a cookie to an attacker.
rejectIllegalHeader hard-code to true: We can either ignore illegal HTTP headers or send a 40x.
allowHostHeaderMismatch hard-coded to false: issues in reverse proxy situations where header is different from the URL.
Align AJP connector handling of invalid HTTP headers with HTTP connector.
Added RateLimitFilter: Prevents Denial of Service (DoS) and brute force attacks by limiting the number of requests that are allowed from a single IP address within a time window.
Log TLS certificate information on startup.
Dedicated loggers for detailed TLS configuration information.
Added TLSCertificateReloadListener: Monitors certificate expirations and trigger automatic reloading of the TLS configuration a set number of days before the TLS certificate expires. Tomcat restart required or JMX command to reload it. It periodically checks on a frequency you define. Shows how close that certificate is from expiring. If you do not update it, then it will start logging warnings.

5. Enable TLS

A critical step in hardening your configuration is setting up end-to-end encryption between the browser and the application server. The first step is creating a keystore using the JDK’s keytool:

keytool -genkey -alias openlogic -keyalg RSA -keysize 2048 -keystore keystore.jks

keytool will ask a series of questions. The most important question is “What is your first and last name?” This should be set to the domain name the server will sit behind and not your first and last name. The question should be reworded to: “What is your CN (Common Name)?” This means the domain which your server will be known by. The output of the keytool should look like the following:

Enter keystore password: changeit

Re-enter new password: changeit

Enter the distinguished name. Provide a single dot (.) to leave a sub-component empty or press ENTER to use the default value in braces.

What is your first and last name?

[Unknown]: openlogic.com

What is the name of your organizational unit?

[Unknown]: OpenLogic

What is the name of your organization?

[Unknown]: Perforce

What is the name of your City or Locality?

[Unknown]: Minneapolis

What is the name of your State or Province?

[Unknown]: MN

What is the two-letter country code for this unit?

[Unknown]: US

Is CN=openlogic.com, OU=OpenLogic, O=Perforce, L=Minneapolis, ST=MN, C=US correct?

[no]: yes

Generating 2,048 bit RSA key pair and self-signed certificate (SHA384withRSA) with a validity of 90 days

for: CN=openlogic.com, OU=OpenLogic, O=Perforce, L=Minneapolis, ST=MN, C=US

This command will create a keystore.jks in the directory keytool was run from.

A certificate signing request (CSR) will need to be generated from the keystore.jks and sent to a trusted certificate authority if you want the certificate to be trusted by the browser. This step is optional if you are testing. The traffic will still be encrypted, but you will receive a “not trusted” message from the browser.

To generate a CSR run:

keytool -genkey -alias openlogic -keyalg RSA -file openlogic.csr -keystore keystore.jks

Then send openlogic.csr to a trusted certificate authority for signing. We will not cover the steps here, but the certificate authority will send you back a certificate to import into your keystore.jks.

There are certificate authorities which will send you a free 90-day signed certificate for free as long as you are the domain owner. They will require you to import their root, intermediate, and your signed domain certificate into keystore.jks.

First import the root certificate:

keytool -importcert -alias root -file root.cer -keystore keystore.jks

Then import the intermediate certificate:

keytool -importcert -alias intermediate -file intermediate.cer -keystore keystore.jks

Last, import your signed domain certificate:

keytool -importcert -alias openlogic -file openlogic.cer -keystore keystore.jks

You cannot only import your signed certificate because the browser also needs the root and any intermediate certificates to trust the domain certificate.

The next step is configuring your server.xml to listen on a trusted secure port by presenting a valid certificate and end-to-end encryption. The syntax assumes Tomcat 9.0+; versions of Tomcat prior to 9.0 require a different syntax which we will not cover here.

Create the following snippet of XML in Tomcat’s conf/server.xml:

…

…

…

<Connector port=”8443″
protocol=”org.apache.coyote.http11.Http11NioProtocol”

maxThreads=”150″ SSLEnabled=”true”>

<Certificate certificateKeystoreFile=”conf/keystore.jks”

certificateKeystorePassword=”changeit”

type=”RSA”

/>

</SSLHostConfig>

</Connector>

…

</Service>

</Server>

This assumes the keystore.jks is in Tomcat’s conf directory.

The configuration changes up to this point do not force plain-text port 8080 to redirect to 8443. To enable this functionality, modify Tomcat’s conf/web.xml by adding the following XML snippet:

<web-app…>

…

<security-constraint>

<web-resource-collection>

<web-resource-name>everything</web-resource-name>

<url-pattern>/*</url-pattern>

</web-resource-collection>

<user-data-constraint>

<transport-guarantee>CONFIDENTIAL</transport-guarantee>

</user-data-constraint>

</security-constraint>

</web-app>

By modifying Tomcat’s conf/web.xml with this change, this tells the application server that you want all unencrypted traffic to be handled by an encrypted port. Restart Tomcat for the configuration changes to take effect. Then go to http://localhost:8080.

If you did not send the CSR from the earlier step to a trusted certificate authority, then you may receive some warnings from the browser. Tomcat will then redirect the browser to https://localhost:8443.

The server I tested with is Apache Tomcat 11 with OpenJDK 21.0.4. After running a protocol test, the server was found to support TLS 1.2 and 1.3 with no support of outdated protocols SSLv3, TLS v1.0 and 1.1 (which is desired due to vulnerabilities).

6. Log Your Network Traffic

To enable logging of network traffic in Tomcat, use the AccessLogValve component. This can be configured on a host, engine, or context basis and will create a standard web server log file for traffic to any resources associated with it.

The Access Log Valve supports a variety of attributes to control the output of the valve. This valve is enabled by default in server.xml:

…

<Host name=”localhost”…

<Valve className=”org.apache.catalina.valves.AccessLogValve” directory=”logs”prefix=”localhost_access_log” suffix=”.txt”

pattern=”%h %l %u %t "%r" %s %b” />

</Host>

…

This valve creates a daily rotating localhost_access_log.yyyy-mm-dd.txt file in Tomcat’s log directory. With the pattern configured in the statement above, the valve will print the remote host (%h), username (%l), date and time (%t), first line of the request (%r), HTTP status of the response (%s), and bytes sent (%b) of every request.

The following output results when the root page is accessed:

35.139.184.195 – – [30/Jul/2024:21:05:18 +0000] “GET / HTTP/2.0” 200 11223

The pattern can be customized in numerous permutations; see Tomcat 11 documentation for details.

Be careful in using this valve as it can put write pressure on the disk if the application server is busy.

7. Limit Access to the Tomcat Manager App

The Tomcat Manager application is a built-in webapp used to manage Tomcat instances, application deployment and other various settings. By default, the Manager application can only be accessed from the machine it is running on or an address in the 127.0.0.0 subnet range using IPv4 or the IPv6 loopback (::1 or 0:0:0:0:0:0:0:1), and this is configured in the META-INF/context.xml using the Remote Address Valve:

<Valve className=”org.apache.catalina.valves.RemoteAddrValve”

allow=”127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1″ />

If there are specific IP addresses you want to allow, then use the following syntax:

<Valve className=”org.apache.catalina.valves.RemoteAddrValve”

allow=”192.168.1.2|192.168.1.3″ deny=”” />

This configuration allows access into the application if your IP address is either 192.168.1.2 or 192.168.1.3.

The Remote Address Valve also has a deny attribute which is used if there are any specific addresses separated by commas that you want to blacklist.

This valve can be used in any application that is deployed on Tomcat.

If a range of addresses is preferred to limit access, then use the Remote CIDR Valve in META-INF/context.xml:

<Valve className=”org.apache.catalina.valves.RemoteCIDRValve”

allow=”127.0.0.1, 192.168.1.0/24″ deny=”” />

This allows access from the loopback address as well as any addresses in the 192.168.1.0 subnet range.

8. Use Realms to Control Resource Access

Realms are another method of controlling authentication and authorization to resources in Tomcat. A realm is a collection of users and roles that are assigned access to a given application or group of applications and the privileges they have within the application once logged in.

There are four built-in manager roles:

manager-gui: HTML GUI and the status pages
manager-script: HTTP API and the status pages
manager-jmx: JMX proxy and the status pages
manager-status: Status pages only

Realms are pluggable. Realms can be configured to connect to a relational database, LDAP, JAAS, a global JNDI resource (such as an XML file), or a combination of realms.

The LockOut Realm is the default in Tomcat which uses the conf/tomcat-users.xml file to control authentication and authorization.The role and users are by default commented out, but a simple example with one user with the manager-gui role would look like the following:

<tomcat-users>

</tomcat-users>

The LockOut realm by default will cause a user to be locked out for five minutes if the password is guessed incorrectly five times which will be displayed in the catalina.out log file:

05-Aug-2024 21:29:39.980 WARNING [https-jsse-nio-8443-exec-4] org.apache.catalina.realm.LockOutRealm.filterLockedAccounts An attempt was made to authenticate the locked user [tomcat]

In addition, the plain-text passwords in tomcat-users.xml can be encrypted. In server.xml, find the UserDatabaseRealm and change it to:

<Realm className=”org.apache.catalina.realm.UserDatabaseRealm”

resourceName=”UserDatabase”>

</Realm>

Any changes to server.xml require a server restart. Modifications to tomcat-users.xml do not necessitate a server restart as this file is monitored for changes.

Generate a hash from a plain-text password:

${TOMCAT_HOME}/bin/digest.sh -a SHA-256 -h org.apache.catalina.realm.MessageDigestCredentialHandler changeme

The “-a” is for the algorithm to be used when encrypting the password. Any algorithm available to the JDK can be used such as SHA-512.

The hash of the password will be displayed after the colon:

changeme:5d56e72f51f7ec5a0bd724e026fa2856ce7f8821358c0f854b3 e18bf20780960$1$5979cdb240050fbb72ad6ed1f69ac8d161634ea91e3f f52e83176fb44fc1562f

Place the hash in the tomcat-users.xml for the particular user:

<tomcat-users>

</tomcat-users>

Keep in mind that all passwords must be hashed in tomcat-users.xml if the MessageDigestCredentialHandler is used.

Tomcat should detect the file changed without a restart:

05-Aug-2024 21:26:22.987 INFO [Catalina-utility-2] org.apache.catalina.users.MemoryUserDatabase.backgroundProcess Reloading memory user database [UserDatabase] from updated source [file:/home/rocky/apache-tomcat-11.0.0/conf/tomcat-users.xml]

Lastly, file access to Tomcat’s conf should be limited to the account running Tomcat.

Back to top

Final Thoughts

While these are some of the many ways you can secure Tomcat, there are still plenty of other things out there that can be done which go beyond the scope of just a blog article. We encourage all our Tomcat users to take a deep dive approach to Tomcat security, utilizing all the resources out there.

About Version 2 Digital

Version 2 Digital is one of the most dynamic IT companies in Asia. The company distributes a wide range of IT products across various areas including cyber security, cloud, data protection, end points, infrastructures, system monitoring, storage, networking, business productivity and communication products.

Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, different vertical industries, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.

About Perforce
The best run DevOps teams in the world choose Perforce. Perforce products are purpose-built to develop, build and maintain high-stakes applications. Companies can finally manage complexity, achieve speed without compromise, improve security and compliance, and run their DevOps toolchains with full integrity. With a global footprint spanning more than 80 countries and including over 75% of the Fortune 100, Perforce is trusted by the world’s leading brands to deliver solutions to even the toughest challenges. Accelerate technology delivery, with no shortcuts.

OpenLogic 2024

Own Your Big Data Infrastructure With the Hadoop Service Bundle from OpenLogic

As a longtime developer and champion of open source, I’m always looking for ways to remove barriers to adoption. So I’m especially proud today to announce the Hadoop Service Bundle from OpenLogic, a new offering that will enable enterprises to switch from subscription-based platforms to a fully open source Big Data stack.

Why We Created the Hadoop Service Bundle

For years, vendors like Cloudera have been selling companies an open-core Big Data solution based on Apache Hadoop that takes the complexity of Hadoop administration off their plates. Open source technologies power their product, and enterprise support and managed services are included as part of the deal. Lately, however, they have been pressuring their customers to migrate to their public cloud platform, the Cloudera Data Platform (CDP).

Why is this a problem? Moving data to the public cloud presents a number of significant issues — new compliance considerations, security risks, and ballooning costs, as well as less cost predictability. Many organizations would prefer to keep their data on-prem or in a hybrid environment and not pay cloud-hosting and migration fees.

Another concern is vendor lock-in: what if Cloudera starts making some or all of their tools proprietary? We’ve seen it happen before, with Oracle Java and Red Hat Enterprise Linux. Companies are understandably nervous about handing over control of their Big Data and then being forced to pay for software they don’t want or need.

The Hadoop Service Bundle was devised as a more customizable and cost-effective alternative that gives organizations more freedom and flexibility with their Big Data. With the Hadoop Service Bundle, organizations can host their data wherever they want and deploy only what they need for their use case, in a 100% open source Hadoop implementation remotely monitored and supported by OpenLogic.

Back to top

What’s Included in the Hadoop Service Bundle?

There are three components of the Hadoop Service Bundle:

Installation and Migration

After conducting a thorough assessment of your current data infrastructure, we will oversee the cutover process from Cloudera, with a side-by-side parallel installation so that we can test for stability before completing the migration.

You decide which components (up to 11) you want to include in your OpenLogic open source Hadoop stack and we will take care of the rest. In the table below, you can see which open source technologies replace the proprietary tools offered by Cloudera — and how much overlap there is, software-wise, between their platform and our offering.

Functionality	Cloudera	OpenLogic Open Source Hadoop
Cluster Administration	Cloudera Manager	Apache Ambari
Cluster Data Services	HDFS, Hive, HBase, Hue	Hadoop, Hive, HBase, Hue
Cluster Execution Services	MapReduce, Yarn, Spark, Oozie	Hadoop, Yarn, Spark, Oozie
Cluster Coordination	ZooKeeper	ZooKeeper

After the migration, we will adapt it to a “reference installation” to give you the flexibility to grow and add new integrations while monitoring the entire stack.

Technical Support

Of course, it’s essential to have 24/7/365 Hadoop support, backed by SLAs, so if something happens, we can remediate issues quickly. You will have direct access to Enterprise Architects with at least 15 years of experience working on complex, large-scale open source deployments.

Admin as a Service

We understand that not all teams have the internal knowledge or resources to manage a Hadoop implementation. OpenLogic will provide administration, including health checks and supervision of security updates, to ensure that your Hadoop instance is fully optimized and monitored around the clock.

Back to top

Benefits of the Hadoop Service Bundle

The biggest benefit is cost savings — when compared to subscription and cloud-hosting fees charged by vendors like Cloudera, the Hadoop Service Bundle can reduce your annual Big Data management spend by up to 60%.

Other benefits include more freedom and flexibility in terms of your Big Data infrastructure. A straightforward pricing model with no surprise fees. Working with a partner with deep OSS expertise that goes beyond Hadoop. And of course, the peace of mind knowing your data is an open source stack and won’t ever be held hostage in a proprietary platform.

About Version 2 Digital

Version 2 Digital is one of the most dynamic IT companies in Asia. The company distributes a wide range of IT products across various areas including cyber security, cloud, data protection, end points, infrastructures, system monitoring, storage, networking, business productivity and communication products.

Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, different vertical industries, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.

About Perforce
The best run DevOps teams in the world choose Perforce. Perforce products are purpose-built to develop, build and maintain high-stakes applications. Companies can finally manage complexity, achieve speed without compromise, improve security and compliance, and run their DevOps toolchains with full integrity. With a global footprint spanning more than 80 countries and including over 75% of the Fortune 100, Perforce is trusted by the world’s leading brands to deliver solutions to even the toughest challenges. Accelerate technology delivery, with no shortcuts.

2024 OpenLogic

New Bootstrap Vulnerabilities to Watch

New Bootstrap vulnerabilities could spell trouble for those with websites or web apps running Bootstrap 3 or Bootstrap 4, which are end of life and no longer community-supported.

Keep reading to find out how these vulnerabilities can be exploited to engineer cross-site scripting (XSS) attacks and what to do to enhance your Bootstrap security.

Recently Disclosed Bootstrap Vulnerabilities: Who Is Impacted?

In July 2024, three vulnerabilities affecting end-of-life (EOL) versions Bootstrap were disclosed:

CVE-2024-6484

CVE-2024-6485

CVE-2024-6531

All three CVEs received a CVSS score of 6.4 from the National Vulnerability Database, indicating medium severity.

Learn more about CVEs and CVSS Scores >>

CVE-2024-6484 and CVE-2024-6485 impacts Bootstrap 3 and CVE-2024-6531 affects Bootstrap 4. If you have applications or websites running either of these EOL versions, you are at risk.

Back to top

How Do These Bootstrap Vulnerabilities Work?

CVE-2024-6484 and CVE-2024-6531 are identical cross-site scripting (XSS) vulnerabilities in the Bootstrap carousel component targeting different Bootstrap versions. This component allows you to define slide behavior of links in the carousel via “data” attributes. The exploit can be achieved if user-supplied values are provided for these attributes without adequate sanitization.

CVE-2024-6485 is a similar vulnerability, but targets the button plugin and its loading text state.

Consequences and Costs of a Cross-Site Scripting Attack

As defined by the Open Worldwide Application Security Project (OWASP), a cross-site scripting (XSS) attack is a vector by which a malicious script is injected into a website. These can be relatively trivial, and just inject new content or data into the website — or more nefarious, and transmit data, like session login information, to a third party under the attacker’s control.

Some examples of what can be accomplished via an XSS attack:

Form contents could be sent to a third party instead of the site, leading to leakage of PII or financial information.

A link could submit a form to a malicious site, returning data that the browser than assumes is trusted, but in fact contains and executes additional malicious code.

A session cookie could be hijacked and used by the attacker to gain access to the user session and data on the website. The attacker can now impersonate the user and gain access to their information, which might include PII or payment methods. If the user has admin privileges on the website, the attacker could gain access to administration tools, potentially changing any content on the site.

A script could modify site contents, such as a press release or blog post, providing false information to consumers and damaging the credibility of the site owner.

While XSS attacks have been known about and categorized for literally decades, they are still serious security concerns for web-based applications.

Back to top

Mitigation and How to Improve Bootstrap Security

There are a number of general measures you can take to mitigate XSS attacks. The most basic is to validate all user input, and use robust sanitization and normalization measures when rendering user-provided input to prevent script injection from occurring in the first place. Additionally, you can set things such as HttpOnly cookies, which prevents JavaScript from accessing cookies, and add Content Security Policy HTTP headers, which prevents third-party JavaScript.

However, when using third-party JavaScript frameworks such as Bootstrap, sometimes you cannot audit every bit of JS that your application executes.

In those cases, you can apply your own patch or migrate to the current version of Bootstrap, Bootstrap 5. If neither of those are possible, it is recommended to get long-term support through a commercial partner like OpenLogic so that you have access to patches when vulnerabilities affecting EOL versions are disclosed. OpenLogic has patched all three of these CVEs for our Bootstrap LTS customers.

Back to top

Final Thoughts

Once open source software reaches end of life, vulnerabilities become harder to deal with since you can’t rely on the community to provide a fix quickly. As described above, the fallout from XSS attacks can be somewhat minor (false information/vandalism to your site) or devastating (sensitive customer data stolen), so if you are running an older version of Bootstrap, it’s time to upgrade or make sure you have an LTS provider.

About Version 2 Digital

Version 2 Digital is one of the most dynamic IT companies in Asia. The company distributes a wide range of IT products across various areas including cyber security, cloud, data protection, end points, infrastructures, system monitoring, storage, networking, business productivity and communication products.

Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, different vertical industries, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.

About Perforce
The best run DevOps teams in the world choose Perforce. Perforce products are purpose-built to develop, build and maintain high-stakes applications. Companies can finally manage complexity, achieve speed without compromise, improve security and compliance, and run their DevOps toolchains with full integrity. With a global footprint spanning more than 80 countries and including over 75% of the Fortune 100, Perforce is trusted by the world’s leading brands to deliver solutions to even the toughest challenges. Accelerate technology delivery, with no shortcuts.

2024 OpenLogic

How to Choose a JavaScript Framework to Replace AngularJS

AngularJS has been end of life (EOL) since 2022, and yet more than 20% of large enterprises have not yet migrated to a different framework*. Usually when software becomes end of life, there is a clear successor, but that’s not exactly the case with AngularJS.

In this blog, we explore how to choose a JavaScript framework to replace AngularJS, with overviews of the most popular JavaScript frameworks as well as different ways to approach your AngularJS migration.

*Source: 2024 State of Open Source Report

Why Replace AngularJS?

As just mentioned, the main reason to replace AngularJS is because it is end of life. This means no more updates, bug fixes, or security patches are being issued from the community. Staying on EOL software exposes your application(s) to vulnerabilities that can be exploited — resulting in serious fiscal and/or reputational damage that puts your business in the headlines for all the wrong reasons.

Read more about AngularJS vulnerabilities >>

While security is the most important consideration here, it’s not the only reason to get off AngularJS. New browser versions and updates to jQuery can also wreak havoc and cause breaking changes and downtime. As an older framework, compatibility is another potential problem. As the web development landscape continues to evolve, there is a good chance AngularJS will not always integrate seamlessly with the latest and greatest tools and libraries.

Back to top

Key Considerations for Choosing a JavaScript Framework

In general, assessment in three key areas is important as you evaluate AngularJS alternatives: scalability, community, and learning curve.

Scalability: Scalability should be one of your top concerns when selecting your next JavaScript framework. Think about your project’s size and complexity, as well as future plans for growth. You need a framework that can scale as your business scales.

Community: The landscape of JavaScript frameworks has grown over the years, but not every project has been widely adopted or proven stable enough to be viable for enterprise. How established is the community? Can you rely on them for support or guidance if you need it? An active community means there will likely be regular updates, bug fixes, and a robust ecosystem with tools and documentation.

Learning Curve: Before adopting a new framework, it’s a good idea to consider how long it will take to learn and your dev team’s current expertise. Is your team already familiar with the framework’s concepts and syntax? Obviously, choosing a framework that is aligned with your team’s existing skills can speed development.

Back to top

Popular JavaScript Frameworks

Let’s take a look at a few of the top JavaScript frameworks for frontend development that could be suitable replacements for AngularJS. We’ll focus on how they compare to AngularJS in terms of architecture, DOM, and data-binding, and highlight some benefits and drawbacks.

Angular

Angular is written in Typescript, which is a superset of JavaScript, so migrating means committing to coding in Typescript moving forward, which may extend the learning curve. Angular does, however, have interoperability with AngularJS, so an upgrade via ngUpgrade is possible. The architecture of Angular is also different from AngularJS: Angular’s component-based architecture (compared to AngularJS’s model-view-controller, or MVC, architecture) is a better fit for mobile-first development and makes it very scalable, due to reusable modular components that simplify the development of complex applications.

Pros: Extensive list of libraries supported by the core team, very stable, and continually evolving.

Cons: Significant vendor lock-in and extremely difficult to write framework-agnostic parts.

Learn more about Angular vs. AngularJS >>

ReactJS

ReactJS was developed by Facebook and offers a component-based architecture like Angular. While AngularJS is MVC, ReactJS is just V, or View-based, and can be used to build dynamic user interfaces. The biggest difference between AngularJS and ReactJS is their scope: AngularJS is more broad and feature-rich, whereas ReactJS is more narrow in scope, making it lightweight and flexible. AngularJS also relies on the real DOM, which can slow things down compared to virtual DOM frameworks like ReactJS and VueJS.

Pros: Highly flexible and popular, with the option to use other JSX alternatives if needed.

Cons: Despite established best practices, there is no clear consensus on implementation, requiring strong technical leadership to deploy.

Read more about AngularJS vs. ReactJS >>

VueJS

VueJS is known for its versatility and intuitive syntax, making it easy to learn. Like ReactJS, it is lightweight with a small API footprint and focused on the “view” part of the typical MVC architecture. VueJS supports two-way data binding, similar to AngularJS, but discourages it in favor of one-way data flow, which is more flexible. Many developers find it easy to get started with VueJS, but before migrating, be sure to consider how your AngularJS deployments are using behaviors from the AngularJS ecosystem.

Pros: Community-driven framework with excellent developer experience (DX) and a robust ecosystem.

Cons: Transition from Vue 2 to Vue 3 demonstrates that community-driven changes can be challenging to manage and maintain, posing future risks.

Get a more in-depth comparison of AngularJS vs. VueJS >>

EmberJS

Compared to the lightweight simplicity of ReactJS and VueJS, EmberJS is more “complete” and well-suited to complex, high-traffic mobile or desktop applications. It follows the MVVM (model-view-view-model) architecture, and components cannot be reused. Compared to AngularJS’s modular approach, EmberJS utilizes routers, templates, models, and components. While two-way data binding is preferred according to the documentation, one-way data binding is also supported. EmberJS uses a rendering engine called Glimmer, which behaves similarly to a virtual DOM.

Pros: Comprehensive, all-in-one framework providing more than necessary to develop single-page applications.

Cons: Declining usage makes EmberJS less resourceful in terms of available solutions.

Explore more differences between AngularJS and EmberJS >>

Back to top

Planning Your AngularJS Migration

Both the choice of framework and migration strategy is likely going to be informed by how you/your stakeholders prioritize quality, time, and cost. In the ideal-but-unlikely scenario that you have unlimited money and unlimited time, you won’t have to sacrifice at all in terms of quality. However, most teams will have to make decisions based on tight deadlines and budgets.

Questions to Answer Before Migrating

As with any legacy codebase modernization project, you should start by analyzing things like size, complexity, dependencies, and your dev team’s bandwidth. Answering the following questions is a good starting point:

What are the parts and responsibilities the existing application has? Mainly Views? Controllers or Services that integrate with other pieces?

Which tools and libraries or 3rd party solution does the application rely on?

Which parts of the existing application can be reused or slightly adjusted?

By moving to another framework, will there be a new list of technical requirements?

What resources are required to maintain the existing solution stack?

What resources are needed to execute a migration?

Once you’ve answered these questions and chosen the framework to replace AngularJS, you’re ready to plan the migration itself. There are essentially two approaches:

A phased migration, aka gradually replacing AngularJS components with the new framework. Depending on your application, this can be technically challenging, but it can be done. It may require partnering with a commercial vendor for long-term support (LTS) for your existing system while you migrate and/or expertise to guide the migration itself.
A complete rewrite, aka rebuilding the application from scratch on the new framework. This can be both time- and resource-intensive; on the other hand, a rewrite could unlock opportunities for a new version with a different vision.

There are some tools that can help automate refactoring, analysis, and running codemods, including ngMigration Assistant, Jscodeshift, and TSLint. The open source community for your new framework may also be able to offer tips and support, or you could consult with OpenLogic for help building your migration roadmap. OpenLogic also offers AngularJS LTS through 2030 if you need a source for patches while you rewrite or migrate your system.

Back to top

Final Thoughts

Make sure to conduct thorough testing and debugging before implementing the new framework in a production environment, as there may be unforeseen compatibility or integration issues. Also be prepared to offer whatever additional training or upskilling your team needs so they can fully take advantage of the new framework’s capabilities. Finally, after migrating, don’t forget to continually monitor performance via metrics like page load speed, network requests, and rendering, so you can optimize as necessary to keep your application running efficiently.

About Version 2 Digital

Version 2 Digital is one of the most dynamic IT companies in Asia. The company distributes a wide range of IT products across various areas including cyber security, cloud, data protection, end points, infrastructures, system monitoring, storage, networking, business productivity and communication products.

Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, different vertical industries, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.

About Perforce
The best run DevOps teams in the world choose Perforce. Perforce products are purpose-built to develop, build and maintain high-stakes applications. Companies can finally manage complexity, achieve speed without compromise, improve security and compliance, and run their DevOps toolchains with full integrity. With a global footprint spanning more than 80 countries and including over 75% of the Fortune 100, Perforce is trusted by the world’s leading brands to deliver solutions to even the toughest challenges. Accelerate technology delivery, with no shortcuts.

2024 OpenLogic