Geoprise Technologies - PHP

Geoprise R&D Director Tony Marston Receives Multi Corporate LiveWire Global Award 2024/25

admin — Sat, 01 Mar 2025 09:38:04 +0000

LONDON, March 1, 2025 – Geoprise, maker of the GM-X Application Suite, is proud to announce that Corporate LiveWire, a platform which informs business professionals and individuals in the corporate sector around the globe, has awarded its Software Design Service of the Year in the Corporate LiveWire Global Awards to Geoprise R&D Director Tony Marston for the second year in a row.

These accolades build upon the Best Open-Source Rapid Application Development award which Tony received in September 2024 from Innovation in Business, The Developer Awards 2024.

The GM-X Application Suite is an Enterprise Resources Planning (ERP) application that was designed from the ground up as a Web application deployable on public cloud, private cloud, and hybrid infrastructure, or on premises. It comprises 21 integrated subsystems, each with its own database and transactions. This allows customers to economize by paying only for the subsystems they require.

At the heart of the GM-X Application Suite is an award-winning framework called RADICORE which was designed and built by Tony Marston as an Internet application using the PHP language. First released in 2006, RADICORE is supported and published by Radicore Software Limited, a British company founded by Tony Marston in 2005 which joined forces with Geoprise in 2014 to build and market GM-X.

RADICORE is not a clone of any other framework, nor does it use any third-party framework components. Other than including various proven and popular open-source libraries for utility purposes (such as generating PDF documents, emailing, and generating or processing spreadsheets), it is totally 100% unique. Building upon his decades of experience with earlier frameworks and programming languages, Tony specifically engineered RADICORE with Rapid Application Development (RAD) ― low-code methods and no-code tools that allow development cycle times to be measured with a stopwatch instead of a calendar ― in mind. His award-winning approach abstracts all the functionality which is independent of any application so that it runs a Template Method Pattern as the base class software for any application without any modifications. RADICORE also has additional software components which provide a user interface comprising 45 different reusable transaction patterns ― far more than basic Create, Read, Update, and Delete (CRUD) operations ― each implementing its own structure (view), behavior (controller), and content (model).

Business transformation through RAD enables organizations to adapt quickly in response to rapidly evolving market needs, improve customer satisfaction, and gain a competitive edge by driving immediate and significant changes to operations and capabilities. RAD comprises methodologies and tools that enable the cycle time between idea and implementation (sometimes known as “Time to Market” or “TTM”) to be substantially shorter compared to traditional methods. Because the expense of software development is directly proportional to the amount of time taken to design, develop, and test it, then shorter TTM equals lower cost.

RADICORE achieves this objective through its library of transaction patterns, automatic forms navigation, and dynamic generation and re-use of program code including PHP scripts, Web pages in hypertext markup language (HTML), and structured query language (SQL) statements. The RADICORE framework also supplies a Role Based Access Control (RBAC) subsystem which controls access to the entire application by means of a collection of dynamic menus, an Audit Logging subsystem, and an Activity Based Workflow subsystem. As well as being able to run all the application subsystems it also has a Data Dictionary subsystem which can generate the necessary components for new subsystems. These capabilities make it possible for software development and information technology operations (DevOps) productivity to rival or exceed that of the fastest artificial intelligence (AI) using large language models (LLM) without introducing any hallucination risks and the appurtenant need for productivity-eroding code reviews to mitigate hallucination risks.

The roots of RADICORE go back 20 years prior to its first release:

COBOL ― initially running on a Univac mainframe but then on a Data General Eclipse, followed by the HP3000. This is when Tony began creating a personal library of reusable code because no central library was available. He converted this library into a framework in the mid-1980s by adding an RBAC capability to control the running of application components.
UNIFACE running on Microsoft® Windows® connected to a relational database. The aforementioned RBAC system was redeveloped in this language, and it provided more facilities and shorter development times than the original COBOL version.

Before creating the entire RADICORE framework, Tony first built a small prototype application to familiarize himself with the principles of encapsulation, inheritance and polymorphism which are the core tenets of object-oriented programming. Just as UNIFACE treated each table in the database as a separate entity, Tony encapsulated the data and the processing rules for each database table in its own class and moved code segments that were repeated for different tables into an abstract class so that they could be shared by inheritance instead of being duplicated. Because every concrete table class inherits its methods from the same abstract class it means that the code which calls those methods can be used, thanks to polymorphism, with any concrete table class using a unique implementation of dependency injection. Using an abstract class also allows the use of the Template Method Pattern which permits each concrete class to contain its own implementation of various “hook” methods.

Although UNIFACE employs eXtensible Markup Language (XML) and eXtensible Stylesheet Language (XSL), it does not use them to create Web pages. Instead, it follows its legacy procedure which compiles static forms that run on desktop personal computers (PCs). Believing this approach to be unnecessarily complex, inflexible, and incompatible with modern principles of mobile-first adaptive Web application development, Tony introduced a major improvement in his first release of RADICORE which constructs all Web pages as HTML documents on the fly using a series of XSL stylesheets. This requires just one software component to convert the application data into XML, then transform it into HTML using an XSL stylesheet. Instead of requiring separate stylesheets to deal with the different columns on each database table, the RADICORE framework uses just 12 reusable stylesheets which can handle the columns from any database table.

Because building each component in a subsystem follows exactly the same steps, the RADICORE framework automates this procedure through its Data Dictionary subsystem. This follows the UNIFACE Application Model but reverses the procedure by first building the database so that table’s structure can be quickly imported into the Dictionary, then exported into a PHP script which is then loaded into that table’s object when it is instantiated. This means that after creating a database table, the scripts to maintain the contents of that table can be generated without having to write any program code whatsoever ― no PHP, no HTML and no SQL. While the generated code provides all the basic processing to move data from the user interface (UI) to the database and back again, the only thing left for the developer to do is to update the relevant “hook” methods in each concrete table class to provide the custom business logic.

About Geoprise

Geoprise Technologies Corporation was formed in 1999 by a group of software executives with over a century of previous cumulative experience building enterprise resources planning (ERP) and manufacturing operations management systems and implementing them worldwide. The privately held company's mission, then and now, is to create exceptional value for its customers by harnessing the power and economy of information technology to enable lean, world-class industrial operations on a global scale. Today, Geoprise focuses exclusively on delivering its state-of-the-art GM-X ERP solution, which it markets through Geoprise Technologies Licensing, a joint venture with Radicore Software Limited, to businesses operating in North America, Europe, Asia, and the Pacific Rim. Geoprise values integrity by maintaining strict independence, intense commitment to business ethics and profound respect for intellectual property rights. For further information, visit the company's Web site at geoprise.com.

About Radicore

Radicore Software Limited, established in 2005, markets and supports the RADICORE Rapid Application Development (RAD) Toolkit for building enterprise applications which are platform independent, browser independent and database independent. RADICORE is based on a combination of the 3 Tier Architecture and model-view-controller (MVC) Design Pattern and comes with pre-built and reusable components in the data access and presentation layers. The GM-X ERP application is built using the RADICORE framework. For further information, visit the company's Web site at radicore.org.

How Secure Is PHP?

admin — Mon, 18 Sep 2017 00:00:00 +0000

By: Nelson M. Nones CPIM, Founder, Chairman and President, Geoprise Technologies Corporation

At Geoprise Technologies, we chose the PHP: Hypertext Preprocessor (PHP) as the server-side programming language for our GM-X ERP application years ago. The reason was simple: then as now, PHP offered all the capabilities we needed, is supported and used by a very large community of developers worldwide, and didn't introduce any particular security risks in comparison to Java, .NET or ASP. Our experience with PHP since then has repeatedly confirmed that we made the wisest choice.

Yet because Geoprise operates in the enterprise software market, time and again I confront what seems to be a persistent bias among Chief Information Officers (CIOs) that PHP isn't as secure as Java. I confront that bias head-on in this post.

The Data

Because I prefer fact-based discussions over those based on "gut-level feel" or hunches, my first step was to find an impartial data source. I found the 2014 Website Security Statistics Report (April, 2014) from WhiteHat Security, a provider of application security testing (AST) services which industry analyst Gartner recently named a "Leader" in the field for the fourth time in a row. WhiteHat publishes this report every year, but their 2014 report is the latest to specifically evaluate different Web programming languages. Its introduction states:

In this report, we put this area of application security understanding to the test by measuring how various web programming languages and development frameworks actually perform in the field. To which classes of attack are they most prone, how often and for how long; and, how do they fare against popular alternatives? Is it really true that the most popular modern languages and frameworks yield similar results in production websites?

By analyzing the vulnerability assessment results of more than 30,000 websites under management with WhiteHat Sentinel, we begin to answer these questions.

The WhiteHat study found that the most widely used languages are Java (28%), .NET (25%), PHP (16%) and ASP (11%). Here are the report's key findings:

There was no significant difference between languages in examining the highest averages of vulnerabilities per slot. Java had an average of 11.36 vulnerabilities per slot. .Net was found to have an average of 11.32 and PHP came in at 10.98.

Risk exposure does not vary widely between languages, as language choice does not affect the number of vulnerabilities. A one-way analysis of the variance showed that there was no statistically significant difference between these languages. In fact, there was no statistical difference, in terms of the average number of vulnerabilities per slot, between any of the languages in this study.

Vulnerability classes analyzed, in descending order of occurrence, include cross-site scripting (XSS), information leakage, content spoofing, SQL injection, cross-site request forgery (XSRF), insufficient transport layer protection, abuse of functionality, HTTP response splitting, predictable resource location, brute force, URL redirector abuse, insufficient authorization, fingerprinting, session fixation and directory indexing vulnerabilities.

XSS and information leakage vulnerabilities were the top two classes by far. XSS accounted for 58% of all PHP vulnerabilities, followed by information leakage at 18%. For Java, XSS accounted for 61% of vulnerabilities, followed by information leakage at 16%.

What These Data Say About PHP Security

These data clearly show that there is no factual basis whatsoever for believing that PHP is less secure than Java, or for that matter any other popular Web application programming language.

I very much doubt that WhiteHat has any particular axe to grind when it comes to evaluating the security of various programming languages. After all, they are a leader in the AST business and presumably will take all comers. They and their customers have nothing to gain from bias, and everything to lose in the event a bias causes them to overlook a vulnerability that leads to an actual security breach.

Moreover, I've seen no evidence to suggest that the usage and patterns of security vulnerabilities among the top programming languages have changed very much since 2014.

What Geoprise Is Doing About Security

Geoprise counts prominent aerospace and defense (A&D) firms among its clients. Military-grade security is a top A&D industry priority.

For this reason, the GM-X ERP application embodies best information security practices and methods. Key GM-X security features include:

Authentication by user ID and password, or by two-factor authentication (TFA);
Ability to temporarily disable user accounts, or restrict account validity to a date range;
Enforces an organization’s security policy through configurable account lockout after failed logon attempts; configurable password rotation, length and format rules; password strength meter; password change confirmation; encryption of stored passwords and secure HTTP (HTTPS) password transmission;
Ability to restrict user access to authorized devices, based on static Internet protocol (IP) address;
Ability to restrict user access to authorized time periods;
Fully configurable role-based access controls at both task and field levels;
Row-level security option;
Database access credentials can be encrypted and stored outside the GM-X Application’s Web server root;
Options to use HTTPS requests and responses for designated pages within the GM-X application, or all pages;
The GM-X application remains fully functional even when scripts are disabled as a security precaution through individual browser settings or an organization’s group policy objects (GPO);
All GM-X program code is encoded to prevent code injection attacks on the GM-X application server;
All GM-X program code is hardened to incorporate best practices and methods for preventing session fixation, session hijacking, cross-site request forgery (CSRF), code injection, SQL injection and cross-site scripting (XSS) attacks;
To prevent data leakage, data is never passed between browsers and the GM-X application server by way of the application’s uniform resource locator (URL); and
The GM-X application can run on the latest versions of operating systems, system software and relational database management systems (RDBMS), to incorporate the latest available security updates and enhancements.

To illustrate, consider session management. The moment a user successfully logs on to the GM-X application, GM-X assigns a token which allows the user to navigate between GM-X screens without having to log on again at each screen. The token is destroyed the moment the user logs off, or automatically after the maximum session lifetime (a PHP configuration option), whichever occurs first.

The key vulnerability is that different client devices which quote the same session ID will share the same session data. It is therefore possible for someone with questionable morals to ‘highjack’ somebody else’s session by submitting a request which supplies their session ID. A session token could be compromised in different ways. The most common are:

Predictable session token;
Session sniffing;
XSS attack;
CSRF attack;
Man-in-the-middle (MITM) attack; and
Man-in-the-browser attack.

Predictable Session Token

GM-X mitigates this risk by having PHP generate new session ID values. PHP’s session configuration settings determine how the GM-X application server generates session IDs. The GM-X security architecture supports session ID values up to 256 characters long, which is the maximum supported by PHP. PHP version 7.1.0, released in December 2016, expanded the maximum session ID length from 32 to 256 characters. Longer session ID values are more secure than shorter ones because they are much harder to guess by brute force.

Session Sniffing

This form of attack utilizes freely-available password recovery and network protocol analyzer tools to extract the data for session cookies that are currently being used by the devices connected to a wired or wireless local area network (LAN), even when Wired Equivalent Policy (WEP) or Wi-Fi Protected Access (WPA or WPA2) security is in place. These data include session names and their corresponding session IDs which could allow an attacker to impersonate a legitimate user who is currently logged on to the GM-X application server.

The best defense against this form of attack is to use SSL (Secure Socket Layer) via the Secure Hypertext Transfer Protocol (HTTPS) when transmitting every GM-X page. This is a standard GM-X configuration option which encrypts all data transmitted between a device and the GM-X application server, including session cookie data. In addition, when the GM-X application server is configured to use HTTPS for all pages, it automatically issues an HTTP Strict Transport Security (HSTS) Policy which enforces secure communication for HSTS-compliant browsers.

GM-X further mitigates session sniffing risks by automatically deleting expired sessions whenever a session closes and also by determining the session ID from the session name supplied by the browser whenever a GM-X page is requested. If no session ID exists for the session name, then the Logon page is displayed instead, where legitimate users must authenticate themselves again. A would-be impersonator would be unable to decipher these credentials using sniffing techniques when the GM-X application server is configured to use HTTPS.

Another defense against this form of attack is to deploy the GM-X application server so it is accessible only via a virtual private network (VPN) connection.

Cross-site Scripting Attack

Cross-site scripting (XSS) attacks can either be reflected (non-persistent) or persistent.

To launch a reflected XSS attack, a would-be impersonator injects malicious code, such as JavaScript, into a uniform resource locator (URL). When run in a browser, this code attempts to extract any session cookie linked to the URL in that browser, and send it to the attacker’s computer. To lure prospective victims into running the code, the attacker then posts the URL publicly or sends it as a link within an email message. Email is the main delivery mechanism for phishing attacks.

In a persistent attack, the attacker gains legitimate access to a Web application and then injects similar malicious code into a comment or message which is saved in the Web application’s database. The malicious code attempts to run in other users’ browsers after the Web application retrieves and displays the corrupted content.

The GM-X application utilizes numerous techniques to ignore or reject malicious code required for reflected XSS attacks, and to strip out the scripting tags required for persistent XSS attacks. As a further defense against reflected XSS attacks, the GM-X application never receives data from forms via the URL, thereby preventing anyone from manipulating the data. These defenses are deployed exclusively by the GM-X application server, regardless of users’ browser choices or security settings. They have been proven effective through years of extensive testing and ethical hacks.

In addition, the GM-X application can be configured to issue HttpOnly cookies which scripts cannot access. This measure will not eliminate all XSS risks, however, because older browsers may not support the HttpOnly flag.

Adjusting browser security settings to disable scripting provides an absolute defense against XSS attacks. Security-conscious organizations often disable scripting on their computers through Group Policy objects (GPO). This approach, however, renders useless any Web applications which require scripting. Any Single-Page Application (SPA), or Web application built on a full stack JavaScript framework, will not work at all on a disabled browser. The performance of other Web applications will degrade to whatever extent they rely on client-side scripting to deliver a dynamic, responsive user interface.

Although the GM-X application uses JavaScript, it does so very sparingly and in ways that cause performance of the user interface to degrade minimally when scripting is disabled.

For example, as an alternative to entering dates from the keyboard, GM-X uses JavaScript to display an optional popup calendar control for selecting dates. When scripting is enabled, this feature is activated automatically whenever a form field containing a date is in focus. It allows users to browse the calendar by year and month, and select a date, by pointing and clicking their mouse or touching the screen.

When scripting is disabled, the identical GM-X screen is displayed but the calendar control is never activated or visible. The GM-X screen remains fully useable and allows people to enter dates from the keyboard. In this way, the GM-X application allows organizations and individual users to make the requisite tradeoffs between convenience and user-friendliness on the one hand, and enhanced security on the other.

Cross-site Request Forgery Attack

Cross-site request forgery (CSRF) attacks attempt to cause end users to perform unintended actions when they are currently authenticated and logged on to a Web application. The attacker constructs a malicious URL and sends it to the victim who then activates the hyperlink. This causes the victim to initiate an action of the attacker's choosing in the victim's browser, without the victim realizing it. The malicious URL could be sent to the victim by email or chat. A successful CSRF attack can force an end user to perform state changing requests like resetting the end user's password. If the victim is a system administrator, a CSRF attack could compromise the entire Web application.

To prevent CSRF attacks, GM-X adds anti-CSRF tokens to each request. This token is not per-session, it is per-request, so even if an attacker could sniff the network traffic and extract a token from a valid request this token could never be used more than once. GM-X generates all tokens in a random sequence and builds them into Web pages before the pages are displayed in the end user's browser. It also stores the tokens in the end user's session data. As each new Web page is displayed all stored tokens which were generated by previous pages are destroyed, thus making any links which use those tokens invalid. When each script is activated the token included in the URL is compared against the token for that script in the session data, and the script is allowed to continue only if the two match. Otherwise the Logon page is displayed instead, where legitimate users must authenticate themselves again.

Man-in-the-middle Attack

Man-in-the-middle (MITM) attacks use free or commercially-available threat management tools to intercept communications between a user and a Web application. Instead of sniffing sessions without disturbing any connections, an MITM attack diverts the user’s connection to a proxy server on the same LAN, which then establishes a second connection to the Web application. This enables the proxy to surreptitiously capture a legitimate user’s session cookies, and could even allow the proxy to alter data passing between the legitimate user and the Web application without detection. That’s because the proxy server masquerades as the standard LAN gateway and never alters any URLs. As a result, the Web application cannot tell the difference between the legitimate user and the proxy, nor can the legitimate user tell the difference between the Web application and the proxy.

Generally, the same defenses for preventing session sniffing attacks can also be deployed to prevent MITM attacks. However, even when using SSL via HTTPS, it’s more difficult but not impossible for MITM attackers to trick diligent users into believing that they are communicating directly and securely with the Web application.

One way is to obtain and install a security certificate on the proxy server that has the same Common Name (CN) as the Web application server’s certificate, but is signed by a different Certificate Authority (CA) having the same trust level as the Web application server’s CA. Although the two SSL connections are actually independent, they appear to be the same because they bear the same CN and are equally trusted. Consequently, the legitimate user receives no warning from the browser that the connection has been compromised (see my previous blog post on this topic). Organizations which utilize self-signed certificates are particularly vulnerable to this kind of attack.

Man-in-the-browser Attack

This threat is similar to an MITM attack, but instead of a proxy server it relies on a Trojan Horse running in the legitimate user’s computer to intercept traffic between the browser’s user interface and its security mechanisms. The Trojan Horse is typically a browser helper object, browser extension, or malicious Ajax worm written in a scripting language such as JavaScript.

Because the Trojan Horse is a form of malware, the most effective defense is to use an up-to-date client operating system together with robust, updated security software to prevent the installation of Trojan Horses in the first place.

Disabling scripting will also prevent any Ajax worm from running. Here again, the GM-X application’s sparing use of JavaScript, and its ability to remain fully useable when scripting is disabled, provides protection that Single-Page Applications and Web application built on a full stack JavaScript framework cannot.

Conclusion

In reality, the choice of language for Web application development is irrelevant when it comes to security. As I've clearly demonstrated, security is only as good as an application's built-in security features as well as its host organization's cybersecurity management program.

Hard evidence, therefore, proves that PHP is just as secure as Java and other Web programming languages, and that the GM-X ERP application's built-in security features are state of the art.

Geoprise Technologies - PHP

Geoprise R&D Director Tony Marston Receives Multi Corporate LiveWire Global Award 2024/25

Tags:

How Secure Is PHP?

Tags: