How to deal with this fundamental problem with the advice: "Don't trust obscure PHP libraries that nobody uses!"?

Question

Frequently, I'd say in virtually every case, there is only one PHP library for any particular problem. (I don't count obsolete, abandoned, trash ones.)

Therefore, it's never a "choice" by me to use it. I have to either use it or nothing.

For this simple reason, the sound-sounding safety advice to "not use obscure libraries not promoted or used by lots of people and major corporations" is rarely applicable, because there just aren't any alternatives to pick from!

And this is for PHP -- one of the most popular/biggest/most used current programming languages on the planet. Imagine if I were using some far less popular language; I'd never find a library to do anything!

It seems like this advice only works in theory. In reality, there's very little, if any, choice between libraries and even languages unless you are going to do everything on your own, from scratch. (Or possibly if you can pay money, which I cannot, and thus I've never even considered any potentially existing paid alternatives.)

The reason I ask this question is that I'm always given it as one of the main tips for how to stay secure and not get malware through compromised/evil PHP libraries. However, when there's just one thing to pick, for example "MailMimeParser", which nearly always seems to be the case (with any "alternatives" having major show-stoppers such as being dead or just not working as advertised), what else can I do?

Answer 1

You say that you don't have a choice, but that's not true. You could write all the code you need yourself. Or you could pay a trusted professional to write the code for you. Or you could could pay a security firm to audit the code before you use it. Or you could accept the risk, and implement other security controls to mitigate the risks. For example, if you are afraid that some code might be vulnerable to SQL injection, you could set up a WAF (Web Application Firewall) in front of it.

Security has a cost: time, resources, expertise, money. There's no free lunch. If you can't afford it, you'd have to either avoid the problem (rethink your project), or delegate it (somebody else will deal with it), or mitigate it (for example with defense in depth) or just accept the risk that you might get hacked.

Personally, in your case, when you have to deal with code that is not widely used, if the library is not too big I'd try to read the code, at least to check if there's any "code smell". Even if you don't check all the logic, it's easy to check if there are enough comments, if they make sense, if the code is clean and understandable, if certain functions are used according to best practices, if there are checks on the input data, etc. The risk of code used by only a few people and maintained by only a few developers is also that it might stop being maintained, or maintenance turns out to be too slow anyway, so at the end of the day you might be forced to read and understand the code anyway, to fix your application.Then if possible I'd also try to implement something for defense in depth, although configuring a WAF correctly might not be easy, if you really want it to be effective and at the same time avoid breaking your application because of false positives.

Answer 2

I will first address the generic part of your question, and then the specific PHP part.

1. Don't trust obscure PHP libraries that nobody uses!

   It is just the usual gain/risk question. If the risk is low, you can do anything and use obscure (or even broken) libraries. That means that neither the platform nor the result of the final application are mission critical. If it fails at a moment, you will just have to produce a fix or find a workaround.

   If you want to include the library in an added value application, you need an evaluation of the risk that the library does not behave exactly as expected. The most common way is (as in Stack Exchange) the reputation. If the library is known to have been extensively tested, and is still maintained, the risk to fall in an untested corner case is low, and you can hope that if you notice a problem it will be fixed. If it is just occasionaly maintained and has few users, you (or your users) might fall later in such a corner case and have no better way than document that your application just cannot do that.

   If the reputation is not well established, you could try to dig a little in the code. If it looks well structured, nicely documented and contains tests, you can at least trust that best practice rules have been observed. As a side point, tests will show on what use case the library focuses.

   If the library really looks like an obscure one, and you want to use it, you will have to test not only your own code, but also test that the library behaves as you expect for all the use cases you intend your application to accept. Because you cannot blindly trust it. But if you do that seriously, it will take time.

2. PHP vs. less used languages

   PHP is probably the most used language for non professional programmers. That means that if you need something, someone else has already produced it. But you cannot be sure of the quality. Java is far less used outside professional grade products. But many libraries are produced by large and well known organizations and heavily tested. When I get something from the Spring projects, I trust it to have followed best practice rules and have been extensively tested.

   Only my opinion but it is one of the reasons I am reluctant to use PHP code: there is plenty of PHP code around, some of it of very nice quality, but the risk to get a poor quality piece of code is high.

Answer 3

The advice is basically a mapping of trust principles one has in the "real" world into the world of software development:

• Don't blindly trust someone but check the reputation. It is better to trust somebody who is also trusted already for a while by many others because in this case it is less likely that the trust gets abused. For software development this means to use libraries which are also used by others and have a good reputation.
• And if you have to deal with somebody who has no established reputation yet be very careful. In case of software development this means to verify that the code is actually doing what it is supposed to do and nothing more (i.e. no backdoors, no critical bugs).

If you don't follow these simple real world rules in software development you can get burned the same way you can get burned in real life: somebody might misuse the (unfounded) trust you have which might for example result in a backdoor or critical bug in your software. And this in turn might damage your own reputation too.

Sure, it is still possible that someone has a good reputation and still misuses the trust. And there are enough example where this is done. But it is much less likely compared to someone with no reputation since it takes lots of efforts to build a good reputation in the first place. Compared to this a good reputation can be easily and quickly lost if misused, so most will not try to abuse their good reputation.

Answer 4

I think you are already following the advice! You say:

I don't count obsolete, abandoned, trash ones.

So, what measure do you use to decide if something is "obsolete, abandoned, trash"? Very few packages are actually marked as "abandoned" on sites like packagist.org, and "trash" is clearly a subjective judgement, so I suspect your actual process is something like this:

1. Search for relevant-looking packages
2. See if they suit your use case
3. Check that they are of a reasonable quality

The fact that you often end up with a single option at the end of this process is very different from there only being one option at the start of this process.

It's also worth noting that if there is a high quality library for solving a particular job, there is often no incentive for someone to write a new one. Again, this doesn't defeat the advice to use well-respected libraries, it reinforces it - if there are lots of people using the same implementation, it's more likely that some of them will spot flaws, or pay for audits. This is basically a reiteration of "Linus's Law":

given enough eyeballs, all bugs are shallow

The only case where I can see the problem actually applying is where there are no decent libraries for a job, because it is a sufficiently uncommon use case that nobody has written one. In that situation, it's up to you to write the library (or pay for it to be written), and up to you to make it secure (or pay for someone to check it's secure).

Answer 5

You don't have to use PHP for your website

There are better alternatives. Look into ocsigen which is designed by computer scientists understanding something about cybersecurity, and into haxe. Of course you'll spend months to learn it, and if you choose to use ocsigen you are taking some commercial risk (the people and companies maintaining it could disappear, so called bus factor). But I personally know the main architect and designer of Ocsigen, and I can ensure you he understands quite a bit about cybersecurity (half of his PhD thesis is on that topic).

I have to either use it or nothing.

No, that is wrong. You don't have to use PHP. For example, read this blog about building your website in C++, and that one about web technologies in Common Lisp. You could use other approaches (e.g. FastCGI servers written in C++ or in Go, your specialized HTTP server written in C++ e.g. with libonion or with pistache or with CppCMS or Wt, in Go, in Common Lisp with SBCL). With Rocket.rs you could write web applications in Rust (and the Rust community cares a lot about cybersecurity). You can program dynamic web servers in SML. And many web servers (Apache, Lighttpd, ...) can be customized or adapted to your needs (e.g. with your plugins written by you for them) without a single bit of PHP related thing.

My biased opinion is that web frameworks above Common Lisp or C++ or Go or Rust are usually designed by educated computer scientists who by profession understand and care about cybersecurity. PHP was designed with a completely different mindset: being able to code dynamic websites quickly. At the time PHP was designed (1995), cybersecurity was not a major concern, but being able to make a nice looking dynamic website in a few days was in practice essential.

But whatever you are using, it does has some cost. Read about externalities. Read J.Tirole's academic work on them (he is a Nobel prize of Economics; his paper on simple economics of open source is worth reading, and the most cited on that topic). Even if it is free software (since free software is about freedom, not budget). At least don't forget the cost of your efforts to learn it and evaluate its cybersecurity aspects.

If you use open source libraries, they still have some cost for you: you need to learn them, to assess them. They usually are given WITHOUT WARRANTY. But you can buy support for these libraries.

If you use proprietary libraries or software components, you are bound by their EULA.

Security is always a matter of trade-offs.

You are able to not fasten your seat belt when driving, but then you take an additional risk and you pay for that (e.g. because your insurance won't cover you if something goes wrong, or because you get some fine). It is the same for software choices.

Be however aware of Rice's theorem. In some ways, it tells that full cybersecurity is impossible. But even living is a risky activity. (You or me could have a heart attack in a few hours).

Your problem is non-technical, but social. If you use open source software, you have the ability to study each source code line and be convinced (or not) that the security is good enough. Of course, that could take decades (or centuries: an entire Linux distribution is now 20 billions lines of source code). But the choice is yours (and you can delegate the security assessment of every software component you are using).