Protecting your company’s data from hackers is not something to be taken lightly. The costs related to recent high-profile data breaches at Sony and Target alone run into the hundreds of millions of dollars. Even if your IBM i-based system is not storing high-security data such as credit card information, social security numbers, etc., consider the ramifications of other sensitive, strategic or competitively valuable customer data falling in the wrong hands!

The unfortunate reality is that a determined hacker can use a variety of devious methods — from sniffing to phishing to bot-based algorithms and numerous other techniques — to gain access to your company’s systems. So it’s critically important to ensure any web application hosted by your company, particularly those accessible from outside your network, are designed in such a way as to limit potential damage that could be caused by users (both internal and external) with nefarious intent. In other words, ask yourself: if an unauthorized person were to successfully log in to your system, what harm could they do? Fortunately, your Valence applications have an automatic leg-up by virtue of using a program-based gatekeeper (VVCALL). Some common sense back-end program design can help further foil data thieves from getting what they’re looking for. Of course, any company with a network should be actively engaged in securing their server(s) as much as possible. Deactivating inactive or terminated users, appropriately limiting user authorities, resetting passwords, setting up SSL, educating users on phishing — these are all routine initiatives you should be vigilantly pursuing on a regular basis.

But that’s not what this post is about. Rather, this post is about your stop-gap, or your fail-safe, as it pertains to Valence. It’s about what happens when, despite your most diligent security efforts, an unauthorized party has successfully managed to gain access to your system with an active user ID and password and has logged in to your Valence instance. Perhaps it’s an ex-employee who slipped through the cracks. Or a corporate spy who persuaded a disgruntled employee to give them access. Or maybe it’s a hacker who used a keystroke-logging device to secretly scoop up one of your user's credentials.  In any event, an unauthorized person is now on your system. What now? Thankfully, if this hypothetical hacker is merely accessing your system through Valence, his potential for damage and access to your company’s data is limited.

Rather than giving direct access to tables or files on your IBM i-based server, Valence applications use a “traffic cop” approach to data access. Specifically, the front-end app sends an AJAX request to VVCALL, which in turn routes the request to a specific RPG program. That RPG program then handles getting a specific piece or set of data and returning it in JSON format to the front-end. At no point does the user get direct access to data outside of the strict confines of your RPG program. So the key to mitigating the hacker’s abilities in this scenario is to be sure you employ best-practices in how your set up your Valence instance and the corresponding back-end programs that go about fulfilling requests.

So without further ado, here are six important points to keep in mind:

(1) Avoid opening up your Apache server instance to additional objects The default Apache configuration for Valence is battened down in such a way that very few IBM i objects can be accessed directly from the browser (see the Valence Guide on Apache Server setup for details). Directories, files and objects listed in the “Alias” and “ScriptAliasMatch” sections can be accessed or streamed through this instance straight to the browser. You should thus add to the alias only the directories that are necessary for the instance to function, such as the IFS folder(s) containing the source code for your custom front-end programs. Don’t grant access to any directories containing data you wouldn’t want falling into the hands of someone with nefarious intentions!

(2) Ensure access to apps with sensitive data are appropriately restricted in the Portal The Valence Portal’s group and app-level authority settings, as set in the Portal Admin app, control not only which apps are visible on the portal launch pad front-end, but also which programs may be called by that app on the back-end. Each AJAX call automatically includes an app ID which is validated against the app itself. If a hacker attempts to spoof a call to a back-end RPG program, he will only be successful if he includes an app ID that is authorized to access that program. So it’s important that apps making calls to RPG programs that return sensitive data are appropriately restricted to a limited set of users.

(3) Be careful about which RPG programs you set up with universal access In the Valence Portal Admin app, under Settings, the “Programs that may be called without checking authority” field is used to specify a list of program objects that can be called from any app, regardless of user authority. These objects are typically “utility” programs that are used to access common data in multiple apps. But because these programs are exempt from the app-level restrictions described in (2), you should avoid including any programs that return data you wouldn’t want falling into the wrong hands. In other words, don’t grant universal access to an RPG program that returns, say, sensitive financial details about your customers or products.

(4) Ensure front-end programs are never sent data that the user should not see When setting up an RPG program to send data to a Valence app, it can be tempting to send much more data than the front-end requires because the RPG code is more simple / less verbose. But writing “Select * from CustMaster” to get a record via SQL (or in the case of RPG programs using native access, saying “chain XXX CustMaster dsCustMast” and using the entire dsCustMast data structure to send data to the front-end), means the JSON data sent to the browser will contain every field in the file. Your form or grid may only be showing a few fields, but anyone can open up the console and look at the raw data coming in the network tab. So you should ensure the back-end is not including fields you don’t want your users to see. From a bandwidth perspective, it’s also a best-practice not to send more data than needed, particularly when loading lists of data into grids.

(5) Be skeptical of any information coming from the front-end In addition to being able to view all data coming from the server, a skilled hacker will be quite familiar with how to use the browser console to manipulate what is being sent to the back-end. So if your front-end program disables a button based on what the user is allowed to do, a hacker could use the console to reenable the button so he can press it. Therefore your back-end RPG programs should always double-check that an action is allowed before proceeding to act on it.

(6) Be wary of potential for “SQL injection” A hacker who knows a thing or two about SQL may try to fool your back-end program into providing more data than intended. For instance, say you have an app available for your customers to use in which they can list data for a specific PO. Your app prompts for a PO number, and the back-end SQL limits the result set to only orders for that customer (based on the user) and the requested PO. Your SQL statement might look something like this: “Select x,y,z from orderDetail where cusno=1001 and po=‘xxxx’ ” (with the user providing the xxxx value through your app). But consider what might happen if for the ‘xxxx’ value the user entered a string like this: 12345’ or ‘1’=‘1 — the resulting SQL string would be “Select x,y,z from orders where cusno=1 and po = ‘12345’ or ‘1’=‘1’“ and the user would be able to see all records in the file! So be sure your RPG programs validate or “cleanse” any user-provided data being concatenated directly into your SQL statements. Simply stripping out any single quotes may be sufficient to address most cases. With these tips vigorously applied on your system, you can rest comfortably at night knowing your Valence instance and applications are as data-safe as possible.

CategoryIBM iTip of the MonthValence