Open source web app more prone to hacking?

Question

At a recent interview, I was asked:

Open source web app (say built on Struts/Spring) is more prone to hacking since anyone can access the source code and change it. How do you prevent it?

My response was:

The java source code is not directly accessible. It is compiled into class files, which are then bundled in a war file and deployed within a secure container like Weblogic app server. The app server sits behind a corporate firewall and is not directly accessible.

At that time - I did not mention anything about XSS and SQL injection which can affect a COTS-based web app similar to an open source one.

My questions:

a) Is my response to the question correct?

b) What additional points can I add to the answer?

thanks in advance.

EDIT:

While I digest your replies - let me also point out the question was also meant towards frameworks such as Liferay and Apache OFBiz.

Answer 1

The question is a veiled argument towards Security through obscurity. I suggest you read up the usual arguments for and against and see how that fits:

• Security through obscurity ( Wikipedia )
• Hardening Wordpress
• SSH server security (Putty)

---

My personal opinion is that obscurity is at best the weakest layer of defence against atack. It might help filter out automated attacks by uninformed attackers, but it does not help much against a determined assault.

Answer 2

a) Yes. Open source doesn't mean open binaries :) The sentence "anyone can change the source code" is simply incorrect (you can change your copy of the code, but can't edit Apache Struts code)

b) Maybe the fact that the source code is visible makes it easier to somebody to see the posible flaws it can have and exploit them. But, the same argument functions the other way: as a lot of people review the code the flaws are found faster so the code is more robust at the end.

Answer 3

A popular open-source web framework/CMS/library is less likely to have horrible bugs in it for long, since there are lots of people looking at the code, finding the bugs, and fixing them. (Note, in order for this to matter, you'll need to keep your stuff up to date.)

Now, your friend does have a tiny point -- anyone who can fix the bugs could also introduce them, if the project is run by a bunch of idiots. If they take patches from any random schmuck without looking the patches over, or don't know what they're doing in the first place, it's possible to introduce bugs into the framework. (This doesn't matter unless you update regularly.) So it's important to use one that's decently maintained by people who have a clue.

Note, all of the problems with open-source frameworks/apps apply to COTS ones as well. You just won't know about bugs in the latter til after bugtraq and other such lists publish them, as big companies like to pretend there aren't any bugs in their software til forced to react.

Answer 4

a) Is my response to the question correct?

The part about the source not being accessible (to change it) because it is compiled and deployed where it cannot be touched is not a good answer. The same applies to non-open-source software. The point that was being made against an open source stack is that the source is accessible to read, which would make it easier to find vulnerabilities that can be exploited against the installed app (compiled or not).

The point about the firewall is good (even though it does not concern the open- or closedness of the software, either).

b) What additional points can I add to the answer?

The main counterargument against security through obscurity (which was the argument being made here) is that with open source software, many more people will be looking at the source in order to find and fix these problems.

since anyone can access the source code and change it.

Are you sure that is what they said? Change it? Not "study it"?

I don't see how anyone can just change the source code for Struts...