Why would they have a host with PHP installed on the same server where money is handled?! Totally irresponsible.
I'm being serious. Unless you have Facebook's resources (and probably not even then) DO NOT USE PHP FOR ANYTHING THAT REQUIRES SECURITY! If you are, start a migration process today. Whatever you think it'll cost, it'll be worth it.
If you cannot decide from the billions of choices out there, go with Go. It's hardly perfect, but way better and simple.
It may come as a surprise to many, but on high security services such as banks, servers that handle critical data cannot have any build tools installed or usable.
Having said this, I've found limited proof that a particular language is any safer than another as it comes down to safe coding policies and risk mitigation strategies.
I'm not sure what you mean, so my answer below might be a misfire in which case I apologize.
If an attacker can get a shell they would still need to have access to a exec environment and / or breakout of a "jail" or other protected space. Protecting your data store can prove tricky but there are quite a few products and techniques that basically reduce the amount of data that can be breached by any one attack vector (database firewalling, query filtering, etc).
Tidying up an OS + middleware (and having a decent L7 firewall) is sufficient to deter most attacks which is all you can hope for unless you can afford a good security architect and a response team and even that does not guarantee 100% security.
Obscurity, by itself, is not a solution but is often one of the most effective tools to deter simple attacks.
Once they have a shell they're free to do what they want. Local root exploits, etc are all fair game -- and there are plenty of 0-days out there. In fact, removing the compiler doesn't help; a lot of attackers and bots run a script to detect the system environment and auto-download what they need to move on. Remember: jails can still be broken out of, and there is some really neat work in the research space of attacking hypervisors...
There are numerous things you could remove from an OS install to make their lives a bit harder (dtrace, systemtap anyone? you can sniff passwords easily...), but once they have a shell and a directory with write access it's game over. You're better off leaving the tools there but having your auditing throw a serious fit when a compiler, etc is executed unexpectedly on a production box.
So yes, I think it's bunk to claim that removing a compiler will provide meaningful security benefit. In fact, I believe this has been suggested a few times to FreeBSD by users (don't install compilers, etc by default!) and was dismissed as ineffective for the same reasons.
Work harder to prevent the bad guys from getting that far. Keep your systems well patched. Have a thorough auditing and monitoring system in place. Use containerization and segregation everywhere possible. Limit scope of access. Some points you made apply here as well. Maybe once you've mastered all of those arts you can play with the obscurity angle.
edit: and L7 firewalls... I'm on the fence there. There has been some movement in that area by security researchers equating them to antivirus... they're only as good as their definitions, and a targeted attack will bypass it. They also seem to give a false sense of security and let people be lazy. Security in layers is important, though.
edit2: don't get me wrong, you should be hardening your production boxes (and dev... so the environments match...) but removing a compiler is not high on my list
My experience has been 80% + in Solaris and OVM for SPARC (also some AIX with LPARs) and I am not aware of any exploit that breaks the non-global zone security boundary to the control domains or other NGZs. I'm fairly sure I haven't seen any in FreeBSD either but I could be wrong here.
In Linux, I am aware of privilege escalation exploits involving symlinks and complied objects (out of the top of my head, might be old or inaccurate) but overall the thinking goes that having a compiler available opens up a few extra attack vectors while not having it installed doesn't break anything at all.
I published an entry level article on building a gold image with ubuntu where I try to map some best practices and my experiences here: https://blog.ukigumo.eu/anatomy-of-a-gold-image/ I never got around to publish the rest of the series but still plan to, so feedback is welcomed. Maybe I should point out that I'm not exactly a sysadmin though :-)
Regarding L7 firewalls, I have recommend that they are installed and _used_ in all environments I've worked in (banks, insurance companies, payment services providers, stock exchanges, etc) and I do agree with you that often the feeling is that if they are installed and set to defaults it's good enough which is worrying but that's not to say that they should be abandoned.
Security is all about risk mitigation and all we can do is not to make it too easy for our platforms to be broken into and data to be lost, and I think if you dismiss obscurity you might need to try out something like setting up a couple of honeypots with commonly used services in your network (one with default ports one without for instance) and keep some notes of your experience :-)
I would say it is easier to shoot yourself in the foot with C than with Java or other managed runtimes.
PHP code can be as secure as anything else, in my experience, but the end state solution has to take into account the possible risks and mitigate them accordingly.
Putting it in another way, would you say it's more dangerous to have a DB and java appserver running on the same "server" or having a PHP application in one box in one network segment and a DB server in another box, different network segment and with different privileged credentials?
It's not so much the language itself the issue, as both C and PHP weren't made with safety in mind, it's the kind of programmers that the language encourage.
IMHO, C cell defined semantics makes it simpler to master. PHP is an easy language to get stuff done, but a pretty hard one to master, I would say possibly harder than C. E.g. very few people actually make no mistakes about the behavior of the == operator... (http://habnab.it/php-table.html)
C is safer in the sense that it filters out the incompetent better than most languages, people which don't have a decent understanding of it are unlikely to produce something that doesn't crash fast if it even compiles.
PHP permits anyone to be somewhat productive, that's good in some cases, but in most cases you want someone who understand what he's doing...
C certainly doesn't filter out incompetent developers at all. The fact that it is less popular means it is naturally filtered out these days with most people who work with it being older but there are plenty of incompetent C developers building internal software all over the world even today. I mean if you checked any internal codebase written in C today you're likely to still find multiple places where the developer has shot themselves in the foot over memory management. It wasn't that long ago that people were speaking the same way about C programmers because of all the exploits/simple bugs years after STSFFAP was released.
>PHP permits anyone to be somewhat productive, that's good in some cases, but in most cases you want someone who understand what he's doing...
In most cases you don't have a choice so it doesn't matter which language you give them.
> I mean if you checked any internal codebase written in C today you're likely to still find multiple places where the developer has shot themselves in the foot over memory management.
This is absolutely nothing compared to the incredible stuff you can see auditing the average PHP code base... Most PHP programmers don't understand all the implicit conversions taking place, and that's a source of many bugs. I can't really blame them as many of them make no sense whatsoever. PHP is a really hard language to master, and most people that put the effort actually start to see PHP for what it is and go to a less insane language...
I've seen it. I use to develop php full time between 6-9 or 10 years ago. I developed C full time 12-14 years ago. I'm not trying to say php is a great language here and I avoid it completely these days. I'm saying php the language has nothing to do with this type of security issue and the language itself isn't going to be more insecure than any alternative. The same developer building wordpress in C is still going to allow for uploading any file in an executable way since they want to enable people to upload plugins from the interface.
There are no systems to my knowledge where the server will compile and execute a .c file from a directory when accessed.
Yet that seems to be the default configuration for many PHP installations unless you specifically guard against it it. A common PHP vulnerability is just the user uploading a php file and then accessing it.
So you're saying the issue isn't with the php it is with all interpreted languages? Then compile your php before upload.
>A common PHP vulnerability is just the user uploading a php file and then accessing it.
A common PHP vulnerability is allowing uploads to a folder where code is allowed to be executed. That isn't a fault with the language but with lazy developers and admins.
>Having said this, I've found limited proof that a particular language is any safer than another as it comes down to safe coding policies and risk mitigation strategies.
Proof is right there in the article. To have PHP on the live server is a security risk, period.
Having a general purpose blog system on the same server(and sharing the same database credentials and having the ability to write files) is a security risk it has nothing to do with the availability of php.
I disagree. Having poor security "hygiene" is dangerous, the tools that you select to shoot yourself in the foot are less important than having a hardened server with minimal services and installed software (and host intrusion detection, etc..)
1. That would be an issue of environment configuration not language.
2. This is saying nothing. C is designed as a programming language but it's certainly possible to shoot your foot off with it as well. Go isn't going to protect you from using exec in a dumb way, or from unsanitized data by default, or by screwing up your file outputs.
> DO NOT USE PHP FOR ANYTHING THAT REQUIRES SECURITY!
Using [your favorite scripting language] doesn't magically make things like SQL injection and other bad practices go away. There are ways to mitigate those issues by using frameworks in those languages - but really the issue here isn't "OMG PHP SUCKS" but rather Wordpress sucks for allowing something like this work:
I have seen that numerous times in my logs. There are settings in PHP configuration where you can actually prevent external downloading of scripts.
However, ignoring the scripting language itself - the server itself could have mitigated behind a firewall and not allowing any outbound web browsing (obviously inbound 80 needs to be open - but there is no reason why it should be allowed to "browse" the web). Or even more limited outbound connection.
Go browse some github projects (obviously those not using a framework) by random people in different languages - you will see that given the opportunity people will still do stupid things - even if the language makes it really hard to do it - as the saying goes "life finds a way".
Not necessarily, because there's no objective way to define 'bad' here.
The existence of different frameworks allows for a competitive environment where new ideas can be tested or old paradigms moved away from, and different programming styles or needs can be catered to. If you're working with a language community for which there is only one canonically accepted framework that someone decided was 'the best', well, you're just kind of stuck with that.
Granted, since pretty much anyone can hack together a basic framework in PHP (I have one that will never see the light of day) most of them are likely to be pretty bad. But it also stands to reason that most of the ones that get used aren't, because there are always alternatives.
Though the Symfony2 community hasn't been open to criticism and suggestions for improvement.
And eventually, when they've taken some of the original criticisms on-board (at v2.6) [0], they themselves get shot down by parts of the community for spoiling the architecture.
"If PHP developers are made to feel terrible, they will leave and there will be less and less great developers working with PHP."
I don't quite see how this might be a problem. Does the author think those people would be less great in another environment? Does PHP own these people?
"Often times, people are just complaining about PHP because it’s a popular thing to do."
No. We do not complain about PHP because it's popular. We complain about PHP because it sucks and we are forced to use it.
Many of the so-called 4th generation languages (i.e. business shits derived from Cobol with DB support bolted in) are totally crazy in this sense. Not only are identifiers often case insensitive, they can also be abbreviated!
Yet people make massive amounts of money with them.
PHP seems to fall apart in the seams when trying to reach a higher abstraction level. For instance, Symfony 2 tries very hard to include modern OO techniques in there, but the end result is that its performance is incredibly bad. Also, the OO basis is ripped from Java (which is not a perfect fit in some places, given that Java is a more static language), which I do not enjoy at all.
Python isn't the fastest dog out there, but doesn't fare so badly with the abstractions, and its OO style suits a dynamic language better. It doesn't try to be a Java.
Neither language will give you much protection against programming errors, nor optimize your code very well like many of the new hip languages (Rust, Go, Nim) do.
"Poor people today have it easy because they can get government benefits without doing anything in return" vs "Poor people today have hard lives because government benefits don't go far enough to help them live decently".
If you focus on the latter part of the sentences, I can see how it's easy to be a bit confused about which is the correct answer.
It bothers me that the entire premise of this poll seems to be that someone ought to be able to live comfortably on government benefits. Living at somebody else's expense* should be uncomfortable.
* Note - in the case of private charities, where the funds to provide benefits are not collected by force/with threat of imprisonment, I'm perfectly OK with providing higher levels of support.
I think that the proliferation of the service industry is a natural response to (and possibly a solution to) the increased automation of manual labor. If I thought it were possible I'd say that the solution was for an increase in knowledge workers (since the automated factories still need them), but many people do not want and/or can't do that type of work.
>I wonder if keeping CVS is not one of the smartest things the OpenBSD project does now.
Given that OpenBSD is supposed to be a security-oriented OS, it's slightly weird that they are using a version control system that does not guarantee that what you put in the repo actually stays there, unchanged. Git guarantees that.
> They are arguably one of the best projects at doing it.
1) Repo security is a hard proposition. Using git with an ostensibly(SHA-1) immutable history doesn't imply security. git repo integrity is cool, and I'll just point to interesting discussion of attacks and mitigation in http://mikegerwitz.com/papers/git-horror-story.
I'll end my debating with the fact that there is room for improvement.
2) Releasing on time, of high quality, for nearly two decades. Development process.. not that it is some ultimate code or product.
Even though I fully know that I'm being superficial and silly, I cannot help but find it hard to take seriously projects that do not use either git or mercurial for the sources in 2015.
What will git or mercurial gain them? There is no feature they want from git or mercurial. None. Zero. Zip.
DVCS? Easy branching and merging? No. No. No.
Why not? Because that's not how they code. It would actually promote bad behavior.
The OpenBSD way is to write your code correct the first time. Commit often, incrementally. Do not introduce large, sweeping changes that leaves things half broken. Be mindful that everyone else is going to compile and run your next commit. The result is that their HEAD/trunk nearly always compiles and works. They don't have to deal with huge code drops that now make it questionable whether or not they can safely cut a release every 6 months because the code hasn't been tested or reviewed well enough.
Their code practices are better than probably any other project and the lack of features in CVS are the reason.
Pretty much as I described -- developers making too many changes without anyone else seeing them and then later doing a big push and now lots of stuff that has changed since is broken.
The devil you know...
Clearly their current process is working for them though. On a big infrastructure project like that, is it really worth it for them to switch? They like what they've got.
Imagine the linux kernel development process pre-bitkeeper, mailing lists and patches. That's close to the openbsd process. CVS is mostly used as a record of changes.
I'm being serious. Unless you have Facebook's resources (and probably not even then) DO NOT USE PHP FOR ANYTHING THAT REQUIRES SECURITY! If you are, start a migration process today. Whatever you think it'll cost, it'll be worth it.
If you cannot decide from the billions of choices out there, go with Go. It's hardly perfect, but way better and simple.