Secure our data: move the data connection string to the server

For Today’s Businesses, Data is as Important as Ever

People often say that data is more important than ever for modern businesses. But I’d argue it’s always been businesses’ most valuable asset and always will be. What has changed, though, is today’s dynamic IT landscape, which is constantly evolving and deeply reliant on innovation. This dependence on technology leads to explosive data growth, alongside a sharp increase in attacks on that data. It’s time to secure our data.

Can these risks be turned into opportunities? That was the question we tackled in our second workshop, or “pizza session,” of 2019. Before we dive into the answer, let’s look at what’s driving the growth in security concerns. While many of us feel security breaches won’t happen to us, investment in security is at an all-time high. In fact, return on security investment has become a critical metric for management decision-making.

Client/Server: The Good Old Fortress

There’s a certain comfort in traditional client/server setups, where security measures are visible and feel reassuring—like a gate at the carpark, a guard by the entrance, and a friendly but firm receptionist. Non-disclosure agreements and conduct certificates are often required, and passwords are mandatory for access. We, as developers, then add layers of robust authentication and authorization algorithms to top it off.

Within these “fortress walls,” data might seem secure. But the truth is, it’s not. According to IBM’s 2016 Cyber Security Intelligence Index, over 60% of data breaches come from within. And no, it’s not all spies or hackers; often, it’s well-meaning employees who simply opened a suspicious attachment.

All the meticulous security efforts surrounding the building, network, workstations, databases, and applications lose value because of one small detail: the connection to the data itself. Like a defensive wall full of gaps, once someone finds a way through, it’s as if they’re looking straight at a vault of shining gold at the other end.

The problem isn’t the technology used by clients—every tech has its weaknesses. Criminals look for that single vulnerability, whether it’s an SQL injection, exposed connection strings, or data source names in ODBC or SQLNet. Allowing direct access to data is risky. Somewhere, somehow, the connection to the database must exist in your app. The second a connection string is visible on a device, all other security becomes moot.

Even the size of the application doesn’t matter. Take a web app with hundreds of DSPs. Users might think there’s no direct link to the database. But if there’s even one or two forms for maintaining a table, that’s the rabbit hole to the data. As we explored in the pizza session, prevention is better than cure—so how do we plug these gaps?

Multi-layer vs. Multi-tier Architecture

It’s not client/server itself that’s the problem; it’s how it’s implemented. Traditionally, client/server models are two-tiered: a client for presentation and a server for data storage. But an application needs more than just presentation and data. The true value lies in business rules and logic, which, by the way, aren’t the same thing.

Too often, “multi-tier” setups are actually “multi-layer” in disguise. Layers, like services for data reading, business rules, reports, forms, etc., organize logic within the application. And while layering is great for structure, it doesn’t inherently enhance security.

Multi-tier architecture, on the other hand, is a technical division that places the presentation on the client, business logic on an application server, and business rules on a database server, spreading processing across multiple machines.

The beauty of Uniface is that it lets us move layers into tiers—without changing our code (assuming, of course, layers are used consistently). This concept was the focus of our pizza session, and it’s one we continue to explore.

Moving data access to a server

The starting point of the pizza session was a typical client/server application: all the processing on the client and all the data on a server. Take a look at Figure 1: you’ll see a Uniface application on the client with two form components and one service. Reading and writing is done in the components.

In the worst case, the assignment file has one of the following path settings:

• $DATA_DBMS_MQL = MQL:server:database|username|password
• $DATA_DBMS_TLS = TLS:server+port|username|password|database
• $DATA_DBMS_MSS = MSS:DataSource:database|username|password
• $DATA_DBMS_ORA = ORA:t:host:database|username|password

You might have secured everything, but the connection string to the data is readable in the assignment file. This means your data is as open as it can be! The technology that is used to connect to the data is not relevant, nor is the security of the connection, application or network.

A setup like this is only fine for development purposes, with test data.

In my Uniface career I have seen hundreds of applications, and a lot of them had the database details in assignment files on the client, even in production environments. Having the connection string data in a readable format in the assignment file makes it pretty obvious. Using the Uniface PathScrambler makes the connection strings unreadable. That feels a bit safer. But remember that somewhere in the process, the connection string must be unscrambled. That information is stored in memory and so it can be found with the right tools.

It’s a good habit to use a service for reading and writing to the database. In the pizza session, we changed the application in Figure 1 to something like Figure 2.

The normal behavior of the Uniface read process is, as we all know, activating the retrieve trigger. Uniface then invokes the read trigger to read and fetch the data from the database. To change this so a service can be used to read the data, an operation on a service must be called. On the form for the entity, the ‘Data access’ property is set to ‘non-database’.

Advice: create subtypes for all modeled entities. Have one subtype that allows database access and another subtype that is non-database. The first can be used on a service that does the reading and writing. The other can be used on the client to display the data.

At this point, two things are achieved:

1. The application uses a service to read and write. Officially, the application has a Service Oriented Architecture.
2. The application is multi-layer.

So, we’ve scored points! However, from a security perspective nothing has changed. As shown in Figure 2, there is still a direct connection from the client to the database.

But now take a look at Figure 3. The only thing that’s changed is the execution of the service. For a Uniface developer, this is just a small step:

1. In the assignment file on the client:
   1. All connections to the database can and must be removed;
   2. Replace them with a path to the server: $TCP_EXEC = TCP:servername+port|username|password|pizza_2_exec
   3. Add: [SERVICES_EXEC] * = $TCP_EXEC:*
2. Install URouter on the server. In the URouter’s assignment file: pizza_2_exec = userver -asn=pizza.asn -dir=path?-adm=path
3. In the assignment file (in this example pizza.asn), add the connection string to the data.

Now, when the service is activated from the form, the processing is executed on the server, without any modification to the application! Suddenly the application is multi-tier.

Why is this more secure? From now on, when someone tries to look into the metaphorical tunnel between client and server, there is no shining gold data but just a Uniface UServer-process. There is no direct access to the database. It is impossible to send SQL requests to the database on the server, because there is no direct access to the database.

From here on, it is up to developers like you and me. The only way to access the data on the server is by requesting data or submitting a change to a Uniface service. With our development skills, we can secure this data: it’s just a matter of authentication and authorization.

But there is more!

In the workshop we played with the configuration. The data is safely hidden behind a service. The only possible way to read the data is by calling the service from the Uniface form components. But what if you want to be able to read the data with other tools?

It’s highly advisable to implement all your business rules in services and execute these on a server. So, now you have your data and the business rules on the server. Let’s suppose that, although you’re happy with your Uniface desktop application, you also want to be able to make the data available to an external system, or you want your data to be part of a mobile solution.

As soon as you have your most valuable assets (business rules and data) executing on the server, you can access them with any technology you want. Look at Figure 4. By adding a webservice to the configuration, all of a sudden, the Uniface service can be used by and/or in any other technology!

Conclusion

With just a few adjustments, what seemed like a security risk can become a powerful business advantage.

At the start of this article, you might have felt your data was secure, but the reality was more complex. By making a few smart changes in your Uniface configuration, your data can be well-protected, while simultaneously opening up new business potential. Now, your data can be securely accessible to third parties—on your terms.

To summarize, here are the key steps:

1. Avoid reading and writing directly from the presentation layer.
2. Implement services to handle all data reading and writing.
3. Shift the execution of these services to the server.
4. Add web service functionality to these services for secure external access.

If you’re interested in assessing the security of your application or need assistance configuring your deployment environment, feel free to reach out. In upcoming blogs and pizza sessions, we’ll dive deeper into step four and beyond. Trust me, with Uniface, the possibilities are endless.

This article is also published on the Uniface website: https://community.uniface.com