Sometimes I have discussions with developers of a company working mainly with Java. As I myself sometimes do development work with PHP I am regarded more or less as a freak in this community. Typical arguments evolve along the lines:
“PHP does not enforce well structured OO code, no 4-layer-architecture built in, problems with scalability”, etc…. I do not take these points too seriously. I have seen very badly structured Java OO code, one can with proper techniques implement web services in a kind of logical 3rd layer on special servers and Facebook proves PHP scalability (with some effort), etc…
What is much more interesting for me these days is the question how security aspects fit into the use of different programming languages. And here comes the bad news – at least according to statistics published recently by the online magazine Hacker News – see
The statistics on OWASP 10 vulnerability types of the investigated PHP code looks extremely bad there – compared to the investigated Java code examples. I admit that this is an interesting result for hackers and that it is somewhat depressing for security aware PHP developers.
However, is this the bad statistics the fault of the programming language?
I doubt it – despite the fact that the named article recommends to “Choose Your Scripting Language Wisely”. I would rather recommend: Educate your PHP developers properly and regularly, implement a proper quality assurance with special security check steps based on vulnerability scanning tools and invest in regular code reviews. Why?
The investigation revealed especially large deviations in the fields of XSS, SQL-injection, command injection (major elements on the OWASP 10 list). The countermeasures against the named attack vectors for PHP are all described in literature and very well known (see e.g. the books “PHP Sicherheit” of C.Kunz, S.Esser or “Pro PHP Security” of Snyder, Myer, Southwell). One of the primary key elements of securing PHP applications against attacks of the named types is a thorough inspection, analysis and correction treatment of submitted GET/POST-parameters (and avoidance of string parameters wherever possible). Never trust any input and escape all output! Define exceptions wisely and rewrite sensitive string elements according to your rules. Check whether input really comes from the right origin – e.g. your own domain, etc., etc.
Whether all relevant security measures are implemented in the PHP code of a web application has therefore more to do with the mentality, technical ability, the knowledge and on the negative side with the laziness of the programmer than with the programming language itself. As at least the technical capability is a matter of education, I conclude:
Tests regarding type, value range, length and of course tests of the contents of received string variables and e.g. image source references plus sanitizing/elimination/deactivation of problematic contents as well as the proper use of respective available library functions for such tests should be part of regular PHP training programs. In addition the use of web application scanning tools like OWASP’s ZAP scanner or the Burp Suite Pro (if you have money to afford the latter) should be trained. Such tools should become part of the QA chain. As well as educated penetration testers with the perspective of the attacker …. The money a SW-company invests for such educational measures is well invested money.
See for the significant impact of education e.g.:
I would regard the statistical results discussed in the “Hacker News” article much more conclusive if we were provided additional information about
the type of applications analyzed and also the size and type of the companies behind the application development. And whether and what type of QA efforts were used. This would give a much better indication of why the Java code showed more quality regarding the prevention of OWASP 10 attacks. One reason could e.g. be that Java applications very often are developed for enterprise purposes – and bigger companies typically invest more time and effort into QA …
So, another valid interpretation of the presented statistics could be that the QA for typical PHP web application SW is on average worse than for Java SW. I admit that such a finding would also be very interesting – but it does not prove that one cannot write secure Web applications with PHP or that the production of secure code is for whatever reasons easier with Java.
In addition the presented number of bugs per MB itself is questionable: if you only look at 3 bad PHP examples and 1 good Java example you may get the same type statistics – but it would be totally meaningless. The distribution of PHP-, Java-, JS-code etc. among the statistical sample is, however, nowhere discussed in the named article – neither in number of applications nor in MB percentages.
Therefore: Without further information the implied conclusion that already the proper choice of a web scripting language would help to improve security of web applications appears is misleading.
To improve the mood of PHP developers having read the article in “Hacker News”: Have a look at the results of a similar investigation presented at this link
It may help, really !
[But keep in mind: Only trust statistics you have manipulated yourself.]