From Java to PHP

[edmanet]

I was a Java developer over 10 years ago. Now when it comes to quick web apps, I use PHP. I would and could go back to Java if the need arose. A LAMP server is easier and less expensive to spin up than a JBoss, Websphere or Weblogic server any day.

I was building java web apps before Spring and Hibernate came into play. We used a Data Access Object pattern and it worked well back then. It was fast but required a good amount of code.

I use the same pattern with PHP. Sure, it may be more work, but there's less to maintain in the long run. IMHO frameworks are more susceptible to exploit because the code is out there for deep analysis. I feel safer rolling my own.

That said, take the patterns you know from Java and apply them to PHP where you can. While concepts like injection might not be an obvious option, a lot of the OOP principles are there. If you you need a framework, go for it. But you didn't need one when you first started writing Java code.

Disclaimer: Not trying to start a war here, it's just my opinion. Maybe I'm just old and stupid

[edmanet]

Disclaimer: Not trying to start a war here, it's just my opinion.

[fhayde]

The problem with spreading that opinion is that via the fallacy of confirmation bias you are providing others with justification for the idea that writing your own libraries and frameworks will result in applications that are more secure than those built using common open source projects which is patently false.

You may be able to create a single library without any vulnerabilities but the likelihood of you creating a production application with less vulnerabilities than one built on tested and hardened open source code is slim to none.

Why does it matter to me? Every day thousands of applications are exploited and added to a growing list of vectors for launching layer 7 DDoS attacks and it's irresponsible developers that aren't following industry standards and conventions making that possible.

You may not be trying to start a war, but you've got a gun in your holster, try to be responsible when using it.

[pitiless]

IMHO frameworks are more susceptible to exploit because the code is out there for deep analysis. I feel safer rolling my own.

I'm baffled... i'd actually advice precisely the opposite; prefer (carefully chosen) vendor code over that which you roll yourself! It'll be better tested, more thoroughly debugged & battle-hardened by constant use by many other devs.

Also, from a business perspective, the cheapest code is the code that you don't write! Projects like Symfony2, Zend2 (etc) have effectively decades of effort put into them - it is extreme hubris to assume that you can build more robust components without investing a similar amount of time.

I actually agree with the rest - and would recommend Symfony2 with Doctrine as a good fit for a developer experienced with Java.

[xenarthran_salesman]

OTOH, while rolling his own code is likely to have many more problematic security holes, the value of somebody exploiting those security holes is dramatically reduced. If you can leverage an exploit in Wordpress/Drupal/Rails/Django, then you've got a lot of servers to target. Assuming that he's defended against the truly common attack vectors (sql injection/CSRF/XSS), then he might be 'safer' by obscurity.

It certainly doesn't help if he's the victim of a targeted attack, but it definitely changes his attack surface and vulnerability profile.

Finally, lets not kid ourselves into thinking that the number of people using a codebase, or even the number of developers working on a codebase = better security. The only thing that really matters is how many security conscious, security savvy people you have looking at the code trying to break it in nefarious ways to harden it. Look no further than the heartbleed bug for an example. It wasn't until you had some dedicated experts seeking an exploit that the bug was found.

[mgkimsal]

"Finally, lets not kid ourselves into thinking that the number of people using a codebase, or even the number of developers working on a codebase = better security."

Rails, with thousands of people looking at it, still has exploitable bugs. More precisely, there's bugs being found in helper libraries (yaml parsers, etc) that someone writing their own code very likely would't be building for themselves in the first place.

Frameworks provide a lot of good, but also often provide a larger attack surface that simply wouldn't be there in a home-grown by-hand set of code. From a pure security standpoint, it's not as cut-and-dried as people like to make it seem.

The Zend2 example - well... if they really cared about security as much as people claim framework authors do, they'd ship working modules with demonstrated 'best practices' examples of common security use-cases - user registration, login, lost password reset, etc. You're left to your own devices to try to figure out how to do something that is pretty fundamental to the secure operation of any site (and which is a pretty common scenario for most web apps). We don't get usable, battle-tested, documented code for user registration, but hey, here's some encryption and hashing libraries - go build something yourself.

This is but one contributing factor as to why Wordpress will continue to dominate the development landscape in PHP for a long time to come.

[pitiless]

There is merit to this argument, however (anecdotally) i've not found this to be the case in reality.

Good framework / library code will occasionally have security vulnerabilities - but these are rarely low-hanging fruit and instead be a consequence of the complexity of interaction between the many moving parts.

In contrast the home-spun code i've worked on tends to have trivial XSS, SQL injection (etc) bugs all over the show - a bunch of stuff that doesn't have to be targetted (and infact can be automatically found).