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.