Choice of Programming Language Doesn't Matter For Security

An anonymous reader writes "The Security Ninja has written a blog post which discusses web programming languages and the fact that they are all insecure. It's based on a report from WhiteHat Security and aims to dispel the myth that some languages will guarantee that an application will be more or less secure than other languages. '... secure code is the product of a secure development process and real business commitment to deliver secure applications which includes developer education. The absence of these processes and business commitments will lead to web applications being developed insecurely regardless of the language being used.'"

Comments

It's a good point but...

[SuperKendall]

It's a great point that security awareness is paramount in any web programming...

But I dare you to write a more secure web service in , than in Java. Sure you have to be security aware, but it's still the case that some languages make acting on that awareness easier than others.

Re:It's a good point but...

[Anonymous Coward]

But I dare you to write a more secure web service in , than in Java.

I didn't know Whitespace supported web services.

Re:It's a good point but...

[Anonymous Coward]

That was one of the funniest things I've read on this site in a long time.

Re:It's a good point but...

[phantomfive]

I've been thinking about this. Is Java really more secure than C? It is a harder question than it seems at first sight.

Usually when you see claims that Java is more secure than C, it is based on people finding more security bugs in C than in Java, but I am not sure that is a good measurement because C and Java are used in different places, and that makes a huge difference. For example, a buffer overrun in a desktop app (excel, photoshop, whatever) is not a security breach, it's just annoying. C is used in a lot of system level code where errors do become vulnerabilities. So, I'm not sure that statistic is a very useful true measurement.

Looking at it from a practical point of view, almost every buffer overflow that you find in C is a string. Java has much better string libraries than C does, and they prevent overflows (they don't even give you access to the level where you could make overflows). So, if I were going to write webservices in C, I would create/find a decent string library that encapsulates all that, so I don't have to worry about string buffer overflows either. This would not be hard (you'd still have to worry about array overflows, but I can't think of a time that I've ever used an array in a webservice).

So really, I'm not sure there's a reason you couldn't write a webservice as securely in C as in Java. It's just a matter of setting it up right. BTW if you say C is insecure because of pointers, don't because they really are not a problem if you have the remotest idea of what you are doing.

Re:It's a good point but...

[binarylarry]

You fail it.

If you're worried about security, you don't assume a best case scenario. "lalala, ladee dah, I'll just make sure my C code is perfect with no exploits and it'll be just as secure as Java."

The reality is it only takes one simple, hard to find and debug fuck up and your application will be owned. In the same scenario using Java, the app would still be secure.

In a perfect world, C and Java are just as secure as one another. In reality, it's not even comparable, Java wins hands down.

Re:It's a good point but...

[dotgain]

For example, a buffer overrun in a desktop app (excel, photoshop, whatever) is not a security breach, it's just annoying.

Bad choice of examples. That's what we were saying and thinking in 1998: IT to PHB: "Don't open any EXE files mailed to you, however Excel spreadsheets, Word docs etc, are fine".

A exploitable buffer overrun in any application where malicious inputs exist is a security hole.

Re:It's a good point but...

[Anonymous Coward]

I think you should write some Java, then come back and review your comment.

You silly oaf.

Re:It's a good point but...

[phantomfive]

That is your argument? Really? It sounds more like talking points from the Java faction. Your argument implies that you think it is impossible to make one simple, hard to find and debug fuck-up in Java. If you really believe that, you will be a lousy coder in any language.

Re:It's a good point but...

[FormOfActionBanana]

Secure programming is not as simple as a 200 word Slashdot comment, but it's not impractical to learn.

Yes, there are buffer protections in managed languages like Java and .NET. But every language suffers from programmers failing to validate data, or validating incompletely, or missing some assumption about the environment. Both C and Java suffer from format string vulnerabilities, although they're not popularly used in Java.

Architectural problems like a hard coded password, a sloppy insecure default configuration, making a session key too easy to guess, goofing up exception handling during a security sensitive operation... have almost nothing to do with the source language.

And please don't repeat that WRONG information about pointer and buffer management just being a matter of cluefulness. My research and that of others has shown that even smart people make mistakes, and smart programmers who know better continue to write buffer overflows even though we've had 30 YEARS of buffer overflows to get a handle on the problem. Beginners and old timers tend to make different sorts of oversights; that's all.

Re:It's a good point but...

[Anonymous Brave Guy]

Your argument implies that you think it is impossible to make one simple, hard to find and debug fuck-up in Java.

But this is exactly the point: for certain types of f-ups, it is impossible to make them in some languages. You cannot overflow a string in Java. You can in C. Java is unambiguously safer in this respect.

This is not a black and white issue. It is safer to use a language where there are fewer opportunities for human error, even if there are still some such opportunities.

Re:It's a good point but...

[phantomfive]

Seriously, when was the last time you made a serious pointer error (I mean, you can always get NPEs but those are in Java as well)? I'll bet it's been a long time.

Re:It's a good point but...

[SnEptUne]

You people are comparing apple with orange. C and C++ are used where memory management and performance is critical; whereas Java is usually used in a enterprise system that focus more on business logic then about when a 1 should shows up in a CPU register etc... Of course, you can write a context switch in Java, but I would doubt its usefulness.

In practice, it is best to use the highest level language available for a given problem. You can't just compare language itself, it is just a tool to do its job. How you do the job is what determines security.

Re:It's a good point but...

[Anonymous Coward]

You can't overflow a string in C either. All you can do is overflow a buffer used to hold char values. That is if you don't know about all the development done in that area and the damn library functions that are as secure as using strings only that faster.

All buffer overflows are introduced by people using bad library functions or just not knowing a goddamn shit about C. They happen to be writing Flash or the Java runtime for big cash, but they are just dumb.

The most common errors I find in my code are infinite loops. I have also had security bugs such as race conditions and loopy permission settings. All of them are an issue in all languages and OSes.

Buffer overflows? You either are too stupid to breathe and type at the same time, or you are aiming to introduce a bug on purpose.

I mean whether you checked for overflow conditions or not is something you know, like whether you used a condom with that Thai prostitute.

The other issues I mentioned are more like knowing if your wife secretly cheated on you with your best friend before or after he had possibly unprotected sex with a Thai prostitute.

Re:It's a good point but...

[zuperduperman]

The problem is that *because* people are protected from certain very basic screw ups in Java companies automatically downgrade the quality of programmer and the level of oversight they use. The result, I believe, is that the end product is *even worse* than it would have been for the "more vulnerable" language.

So - if you are talking academically about languages - Java is more secure by a long way. C has all the vulnerabilities that Java has plus a lot more. If you are talking about actual outcomes in the real world - C is probably more secure. But this in no way means you can take the same sloppy programmers and methodologies that you used for your Java app, tell them to write in C and get a more secure product. Quite the opposite.

Re:It's a good point but...

[Z00L00K]

I may want to select Erlang as a competitor for writing a more secure web service, but it still depends on the overall design.

Security is on so many levels, one is buffer overflow, but another is verification that the data in a request is valid for the calling user.

Imagine a simple situation where you have a single database accessed by two departments. They may not see each others data but what's done is that the department is provided as a hidden input field that isn't validated against the user when the form is posted. So anyone with some skill may generate a faked request with the data for the other department. It may be sufficient to just hack the URL field in a web browser. And that is a pure design flaw that doesn't depend on the programming language used.

Assume that users will abuse the system in every conceivable fashion.

Re:It's a good point but...

[gbjbaanb]

so your argument is that Java is secure and C isn't becuase you might write an app with a security bug in it in C without realising its there; but you could never, ever write a Java app with a security bug in it.

It might be more difficult to write security bugs in Java (though I doubt that, as you say "it only takes one simple, hard to find and debug fuck up") and we know you can write bugs in Java apps.

So really, you fail it. Security through 'crossing your fingers and hoping your language fixes everything for you' is why people like you create more insecure apps than any number of C apps.

Re:It's a good point but...

[gbjbaanb]

most beginners (and some old timers) use analysis tools or 'secure' buffer manipulation functions. Its easy to write strcpy(buf, input). Its not that much more difficult to write strncpy(buf, input, max_buf_size) or in Microsoft strcpy_s(buf, max_buf_size, input) (and MS even added a macro so strcpy turns into strcpy_s with the sizeof(buf) automatically added for you).

And most people I know use CString or std::string anyway.

Given those, I'm not sure why we still have buffer overflows today.... unless its old code or copying data into an buffer only referenced by an input pointer.

Plenty of other opportunities to cock things up though :)

Re:It's a good point but...

[dzfoo]

Once upon a time, I used to skydive for fun. I remember being asked constantly by my friends about the risk and the dangers of it, and I always answered in the same way: yes, it is very dangerous and has a high potential for death, but the risk of dying are statistically minimal, compared to other more common activities like, say, driving a car on the highway. It is, thus, safer than most people think.

The reasons for this, I imagine, is because the risk of death is so high and so obvious, that everybody involved in the activity takes every single facet of it very seriously, and every single potential point of failure is checked and double-checked, with various redundant mechanisms and procedures. In essence, precisely because it is so dangerous, extreme care is taken at every step, with the overall result of a reduced incidence of mortality. Conversely, driving a car is such a humdrum, common occurrence that a lot of people take it for granted, which invariably results in careless or even negligent behaviour, ultimately resulting in a rather high incidence of death or injury.

So it is with programming languages--and any other human activity. A language such as C, with facilities to manipulate memory directly and other such volatile features, induces experienced programmers to take greater care in making sure that all code paths are considered and that vulnerabilities are not introduced; while a more forgiving language will often result in a more relaxed attitude towards security.

        -dZ.

Re:It's a good point but...

[Anonymous Brave Guy]

I think the point is that C and C++ are not just used where low-level control and performance are critical. Today, they probably should be (at least for new projects) and even the performance argument is weakening as time goes on and other technologies improve.

Re:It's a good point but...

[Anonymous Coward]

You're a perfect example for the kind of subtle problems that cause buffer overflows in C. strncpy does check whether it'll overflow the target buffer, but it won't make sure that the resulting string is nul-terminated, which may lead to other errors later on.

Re:It's a good point but...

[binarylarry]

Riiight, which is why you almost never read about high profile sites running Java web apps getting taken down.

But there are MONTHLY security exploits for mature web apps written in C or C++ (see Apache, BIND, and every other C/C++ networked application that ever existed).

Where do stupid fucking morons like you come from?

Re:It's a good point but...

[gbjbaanb]

that's because there aren't any high profile web sites written in Java - they're too slow, buggy and useless. Even assuming what you say is 100% true, how come vendors patch security flaws in Java itself and they never get exploited?

We had our corporate system breached due to a flaw in a very big, expensive 'Enterprise' java web system so I know it from experience.

How about a quick google for information. This one has a table of java web framework security features. This one (pdf) describes "Our static analysis found 29 security vulnerabilities in nine large, popular open-source applications, with two of the vulnerabilities residing in widely-used Java libraries. In fact, all but one application inour benchmark suite had at least one vulnerability."

as well as "A recent penetration testing study performed by the Imperva Application Defense Center included more than 250 Web applications from e-commerce, online banking, enterprise collaboration, and supply chain management sites [54]. Their vulnerability assessment concluded that at least 92% of Web applications are vulnerable to some form of hacker attacks"

Ho hum. I guess you think Java is completely secure. What a fool. Hope no-one hires you to write any of them, well, not until you go to java.net and look up all the 'how to make your java app secure' tutorials. Sounds like "fucking morons" like you need them more than most.

Re:Duh

[K. S. Kyosuke]

I'm afraid it's you who is insecure, not C...

Obviously...

[Meshach]

That seems like a no brain statement. It doesn't matter what language I use if I write insecure code the application will be insecure.

More at 11

Re:Obviously...

[shutdown -p now]

That seems like a no brain statement. It doesn't matter what language I use if I write insecure code the application will be insecure.

The point is that it's easier to write insecure code in some languages than in others. In fact, in some of them, it practically writes itself.

That said, TFA is pointless. Let's see what the guy is comparing:

- ASP (languages: VBScript, JScript)
- ASP.NET (languages: C#, VB)
- ColdFusion
- JSP & Struts (language: Java)
- PHP
- Perl

Now, one thing that stands out: there's no C or C++ here. In fact, there's no memory-unsafe language here at all. You know, the kind where you can actually get things such as buffer overruns and dangling pointers. Which is usually precisely what people mean when they say that some languages are more safe then others.

So TFA has a nice strawman, but that's about it.

I have an hypotheses

[aBaldrich]

I think that in average programs written in haskell (exempli gratia) tend to be more secure because it takes a better programmer to write them than a quick and dirty VB application.

Re:I have an hypotheses

[ClosedSource]

The problem is that the set of all haskell applications is too small to be statistically significant. OK, I'm just kidding.

Re:I have an hypotheses

[blair1q]

I think the opposite because the better programmer will be rendered an average programmer by the difficulties of the language.

Re:I have an hypotheses

[Anonymous Coward]

Code monkeys avoid it because you can't write a website in it and upload it to GoDaddy. That doesn't make it more difficult.

Re:I have an hypotheses

[perlchild]

If that were true, we could prove evolution wrong.

That which does not kill us makes us stronger, not weaker.

The difficulties of the language are negligeable compared to the difficulty of writing a secure, complex app, simply because the language's complexity is negligeable compared to the sum complexity of all the apps that can be written in it.

Easy-to-use, "simple" languages, ought to be more secure than C, but in the real world, only logo is really safer than anything else, just because you can do almost nothing with it.

Re:I have an hypotheses

[blair1q]

>If that were true, we could prove evolution wrong.

>That which does not kill us makes us stronger, not weaker.

You're mistaking adaptation for evolution. (Ironically, We had to evolve the ability to adapt in the way Nietzsche described.)

The only relationship between killing and evolution is: that which does not kill me lets me live long enough to produce an(other) offspring with new mutations of some sort.

In most cases, as you can observe by the extremely small number of species that aren't even as strong as you are, it's a change for the weaker that allows a species to remain in a delicate niche.

Perl most secure

[by (1706743)]

'Cause even if the source is available, the would-be attacker won't be able to understand it!

Re:Perl most secure

[crow_t_robot]

Perl is terrible but Malebolge takes the cake: http://en.wikipedia.org/wiki/Malboge_(programming_language) Enjoy your brain exploding.

Re:Perl most secure

[milonssecretsn]

http://en.wikipedia.org/wiki/LOLCODE

CAN HAS SQL?
DBASE IZ GETDB('db/lcsn.db')
FUNNAHS IZ DBUCKET(&DBASE&,"CAN I PLZ GET * ALL UP IN lollit")
IM IN UR FUNNAHS ITZA TITLE
        VOTEZ IZ &TITLE#ups& - &TITLE#downs& ...

Re:Perl most secure

[Monkeedude1212]

Security through Obscurity has always worked for Linux Distros.

(before you hit flamebait, I cast Mana shield! Only my Kharma points take damage)

Re:Perl most secure

[Anonymous Coward]

Whitespace is pretty good,too.

Re:Perl most secure

[oldhack]

You under-mis-estimate Perl.

There once was a theory that undecidable problems are, well, undecidable and assumed to be unsolvable.

With the advent of Perl, not so. Undecidable, decidable, it's all just meaningless semantic bullshit before the mighty Perl interpreter - it is whatever she decides it to be, and she makes it so.

Re:Perl most secure

[jd]

IFFEN(Nawt Sek Ewer) DEN Apply(Bite) ADN Apply(PoynteeEnds)

Re:Perl most secure

[izomiac]

Well, Perl does have taint checking, which I always liked. It refuses to perform an "unsafe" operation (e.g. open() or exec()) with data derived from unsanitized input. It certainly won't stop you from writing insecure programs, but it will catch an occasional oversight.

Its not black & white

[Anonymous Coward]

Anyone who says all programming languages are equally exploitable is a fool. Sure, secure coding practices and standards are the way to approach the issue- not language selection, but it is, for instance, impossible to overrun a buffer in interpreted byte code and executed native code. The fact that stack crashing doesn't exist in interpreted code alone demonstrates that languages (or their runtime environments that are inherent to a language) are not all equal in exploit-ability levels. To say they are all the same is simplifying things too much. Yes, all languages have their exploitable bad practices, but some have more than others.

Re:Its not black & white

[phantomfive]

Wow, way to let your pre-existing ideas blind you to the truth. Do you realize these guys are doing the scientific thing here, and testing assumptions like the one you just made? They made a statistical analysis of 1,700 websites in different languages. Do you think you could at least read their assessment before spouting off your rage? If you have a problem with their study, you should point it out. If you disagree with them because of what you 'think', you might as well start a church and call it a religion, because that is what you are practicing.

Re:Its not black & white

[BitZtream]

Please show me the interpreted byte code langauge/runtime that has never had a buffer overflow exploit.

I promise you that I can count one one finger higher than you can show me systems without a buffer overflow exploit.

The fact that your saying what you're saying tells me you really have no understanding of how exploits happen at all, let alone any reason you should be talking about secure code.

Re:Its not black & white

[Anonymous Coward]

Not true.

You list off the exploits from C then ignore all the other exploits of code out there.

For example is SQL exploitable? Many implementations are prone to exploits. Yet that is not a 'static' language by any means. In fact many would say it is entirely interpreted.

There are languages out there that 'hide' the details from you but all the things you list still exist. Can you tweak them or not depends on how good you are at it...

With a '4gl' language you have 2 things to attack instead of one. You have the runtime itself THEN the system it is running on. To say that it is impossible for say java to not be exploitable is short sighted. If it wasnt exploitable then there wouldnt be zillions of patches now would there?

Re:Its not black & white

[Fnkmaster]

Yeah, except this isn't a comparison by language. It's a comparison by platform technology. For example, JSP shows as one of the highest vulnerability ratios, whereas Struts (Apache's Java MVC framework) has just about the lowest vulnerability ratio (on par with ASPX).

Clearly they are measuring *something* but it seems to have relatively little to do with languages themselves.

If anything, it seems like web apps written in frameworks that don't actively discourage mixing code and presentation are more likely to have vulnerabilities, whereas frameworks that encourage separation more actively (and perhaps are newer frameworks) are less likely to have vulnerabilities. The worst two measured, Perl and JSP, are older technologies that date from the era before frameworks that enforced more MVC separation were common and before web app best practices really existed.

Re:Its not black & white

[hibiki_r]

The test itself already has bias, precisely because it works on a family of programs that happen to have a very limited set of inputs, and where the avenues of attack are relatively limited in some very important ways. The core vulnerabilities of websites have been done to death, so at this point, barring utter stupidity, I'd have been surprised if the security problems were noticeably different depending on the language.

Re:Its not black & white

[alan_dershowitz]

I think you're right to say that it's better to trust empirical evidence than go on seemingly logical assumptions. However, to me it looks like the study is making a _business case_ that all the tested languages are likely to produce roughly the same number of flaws. That is to say, as a business decision the programming language viewed by itself is not a significant factor. However I don't think it can be extended out to saying the language doesn't matter. It's not accounting for quality of programmer, design process, etc, those differences might be getting lost in averaging.

Like OP said, it seems logical that a language that simply has more exploitable metaphors and less secure alternatives should create more error prone software. I would like to see a study that compared say, JSP and C.

Re:Its not black & white

[Delusion_]

"All languages are exploitable" != "all languages are equally exploitable".

You're the first person to bring the word "equally" into the conversation, and have missed the point.

Re:Its not black & white

[gangien]

I read the link, and since it requires registration of sorts to dl the pdf, I won't do that.

But it seems like a very macro level type of study, and that seems to gloss over technical details that you need when judging a language.

To use a car analogy, if you're measuring accident avoidance, and you note that the prius has the least amount of accidents, therefor it's the best for avoiding accidents. Ignoring the fact that what you're doing if your driving a prius, or the type of person that typically would use a prius. In otherwords the fact that it's a prius is probably fairly irrelevant.

Not that this type of study shouldn't be done, but just that it's hardly conclusive.

Re:Its not black & white

[dgatwood]

They made a statistical analysis of web languages. That's not generalizable to all programming languages as the Slashdot headline implies. All of these languages have several things in common:

• Variable-length strings.
• No truly fixed-size data structures or buffers.
• No direct access to pointers.

In short, all of these programming languages eliminate entire classes of potential exploits that other programming languages allow. Therefore, although these programming languages happen to be similar, that does not mean that programming language choice has no bearing on security. It just means that choice of programming language within a very narrow range of languages that are not a representative sample of programming languages as a whole has no bearing on security.

Re:Its not black & white

[K. S. Kyosuke]

Please show me the interpreted byte code langauge/runtime that has never had a buffer overflow exploit.

What about this one?

Re:Its not black & white

[dgatwood]

The difference is that flaws in the Java runtime (or any runtime) are A. infrequent, B. somebody else's fault, C. quickly fixed once discovered, and D. not specific to your individual installation. Thus, as long as you pay attention to the security notices, you're probably fine.

Put another way, there are thousands of people looking for flaws in the Java runtime. When you're talking about flaws in your code, the only people looking for bugs in it are you and the bad guys. This means that it is much more problematic to have 1,000 bugs in your code than to have 1,000 bugs in the Java runtime. With the latter, the odds are in your favor that the flaws will be first discovered against somebody else's website. WIth the former, the only place those flaws can be discovered is on your website.

Re:Its not black & white

[bmajik]

Well, the full paper is behind nag-ware, but here are the "top 3 findings"

Empirically, programming languages / frameworks do not have similar security postures when deployed in the field. They are shown to have moderately different vulnerabilities, with different frequency of occurrence, which are fixed in different amounts of time.

The size of a Web application's attack surface alone does not necessarily correlate to the volume and type of issues identified. For example Microsoft's .NET (ASPX) and Struts (DO), with near-average attack surfaces, turned in the two lowest historical vulnerability averages. ASPX and DO websites have had an average of 18.7 and 19.9 serious vulnerabilities respectively.

Perl (PL) had the highest average number of vulnerabilities found historically by a wide margin, at 44.8 per website and also the largest number currently at 11.8.ties have taken over 50 days to fix.

Gosh. To me that says that they found significant differences between the languages and platforms.

However, I am not ready to make any claims based on this, other than, they sampled a bunch of websites and then recorded information about vulnerabilities, and did "group by" on language/framework.

Isn't it likely that there is some selection bias here?

Rather than making claims about the intrinsic nature of some language or framework [like all of them are equal, or one is better than the others], don't you need to correct for the lack of control.. like same coders in the same organization trying to implement the same _type_ of application?

If I gave the same group of developers equal traning time, equal implementation time, and equal specs... and then said "do this in ASP.NET", and then "do it in Perl". And i did this with 10 groups of developers, and i changed the order of which application came first (i.e. some groups did perl first, some did asp.net first).

__then__ I would feel comfortable saying something about the relationship between language/framework and security vulnerabilities. What we really want to know is, given developers _like yours_, who've had equal training, expertise, and time, when trying to produce equivalent functionality.. how is _their_ production of security defects, and is there a difference between toolchains?

Now, I didn't read the PDF because if the nag-wall infront of it. But that doesn't sound like what they did here.

The goal out here in the real world is this: make an application that is secure-enough, cheaply-enough. "Cheaply-enough" means what caliber of people you need to hire, and how long it takes them to produce value-adding output. Secure enough means that the cost of fixing your bugs is higher than the cost of (risk of penetration * financial impact of penetration).

Re:Its not black & white

[phantomfive]

Good. You are criticizing the study. That is reasonable. The OP was not. The OP was spouting off his opinion without anything to back it up. If you can't see the difference, you're in trouble.

Re:Its not black & white

[eulernet]

The fact that stack crashing doesn't exist in interpreted code alone demonstrates that languages (or their runtime environments that are inherent to a language) are not all equal in exploit-ability levels.

You are totally wrong, since Javascript, which is interpreted, has numerous exploits involving stack crashing.
http://en.wikipedia.org/wiki/Heap_spraying
with an example here:
http://stackoverflow.com/questions/381171/help-me-understand-this-javascript-exploit

ActionScript (from Flash) is also an interpreted language, and full of security bugs !

Re:Its not black & white

[Anonymous Coward]

Your logic is system focused, in that you are worried about protected the host, not protecting what is hosted on it.

You don't need a buffer overflow to steal customer information if there is a simple logic flaw in the application.

Re:Its not black & white

[Anonymous Coward]

Uh, the first person? Maybe if you don't count the /. headline and blurb.

Re:Its not black & white

[jellomizer]

it does if you language is caps insensitive and can handle a maximum string length of 19.

Re:Its not black & white

[FormOfActionBanana]

I don't know what you mean by "done to death", but if you are trying to say developers have stopped publishing websites with:
  - XSS
  - SQL Injection
  - Javascript hijacking
  - HTTP response splitting
  - Guessable session keys
  - Path injections
  - Dumb insecure default configurations
  - Hard coded passwords
  - Remotely viewable stack traces
  - Out of date frameworks
  - Weak upload algorithms
  - exposed direct object references
  - attacker controlled primary keys
then I think you would be wrong.

Re:Its not black & white

[Anonymous Coward]

You're missing the point. Holes in the language aren't important, they're few and far between — and fixed quickly.

Security holes in code written in that language are important. I'm fairly sure I've never written a buffer overrun in my own code, simply because i use languages where it's impossible.

Beat up any straw men lately?

[Seor Jojoba]

"That aims to dispel the myth that some languages will guarantee that an application will be more or less secure than other languages."

Whoever said, besides your 16-year-old cousin that just figured out how to add a flaming skull animation to his MySpace page, that there is any web application programming language that will guarantee security. Sheesh.

PHP and Visual Basic vs. Ruby, Python, etc.

[Weezul]

I don't buy their argument, PHP and Visual Basic are famously bad at security, while most other languages require real work to achieve their innate level of insecurity.

sdfds sfgdfs dfg dsfg sdfg dfgdfg dfg sfg dfgfd dfgdg fdg dfsgljhf sdfgsdf gdflj sdfgdfg dgdf fglb4tsfgf

All garbage text posted towards the end of this message exists to compensate for how slashdot breaks safari's contextual menu for spelling correction.

Bloody hell...

[Anonymous Coward]

You mean I am actually supposed to know what I'm doing?!

Yes...but

[ArhcAngel]

If you know what programming language a programmer uses you can tell if they know what they are doing or not.

Re:Yes...but

[ClosedSource]

Sure, as long as you have the language spec.

Re:Duh

[tool462]

Careful. You might get him so mad that he'll have a buffer overflow and then core dump.

Re:Duh

[Anonymous Coward]

True.

A system without any users is secure.

Re:Duh

[balbus000]

C...

Oh cool, is C ellipses the new C sharp?

The Python Paradox

[calmofthestorm]

If you haven't heard of it, the python paradox is an interesting read: http://www.paulgraham.com/pypar.html

Simply put, the kind of people who learn a language out of interest than out of wanting to get a job tend to be better programmers on average. (This was written awhile ago, when Python had little use outside the FOSS community. Now that Python is looking like it may someday replace Java, perhaps the Haskell Paradox is a better term).

Anyway, perhaps the same issue is at play here. Perhaps the people who use PHP tend to be less aware of security or more apathetic toward it, and thus there is a two way feedback between language and programmer (the last time I used Visual Basic the compiler was as full of holes as a piece of swiss cheese and Microsoft wanted me to pay $100 each to report counterexample bugs, but that was 6.0, back in middle school)

Re:The Python Paradox

[barzok]

Simply put, the kind of people who learn a language out of interest than out of wanting to get a job tend to be better programmers on average.

People who do anything because it interests & fascinates them on a personal level do better than those who are only in it for the paycheck. Doesn't matter whether it's programming, auto repair, landscaping, or anything else.

Re:The Python Paradox

[tsalmark]

I think php is rather an interesting case. Looking at SQL injection: the language is strong enough and easy enough to protect against attack. Yet if you look at programming documentation, examples and free applets available on the web. Many of them have no protection at all. Also the forums providing answers to novice questions are often being answered by other novices. Best practices do not yet seem agreed on and pointed to in PHP as in other languages. So the bad practices are almost self perpetuating.

Re:The Python Paradox

[Arthur Grumbine]

People who do anything because it interests & fascinates them on a personal level do better than those who are only in it for the paycheck. Doesn't matter whether it's programming, auto repair, landscaping, or anything else.

Except gambling/poker.

Re:The Python Paradox

[calmofthestorm]

Exactly. The culture of a language is as or more important than the language itself. Indeed, the culture shapes the language (but of course, to a degree, the language shapes the culture).

Java itself isn't a very good language, but it's the hordes of incompetent Java programmers who make it such a terrible choice for everything. This goes back to the Python paradox: companies want Python programmers to write Java for them.

I will say this in Java's favor, however: It's a language where the smartest can't write code that confuses the dumbest, and where the dumbest can't write code that does too much damage.

Re:The Python Paradox

[swanzilla]

People who do anything because it interests & fascinates them on a personal level do better than those who are only in it for the paycheck. Doesn't matter whether it's programming, auto repair, landscaping, or anything else.

I paid for my undergrad degree by landscaping, and I can say with some certainty that it is neither an interesting nor a fascinating subject.

Re:The Python Paradox

[ClosedSource]

It's an interesting essay, but it's just speculation. Not any more insightful than the serious posts on Slashdot.

Re:The Python Paradox

[CondeZer0]

This a very good point. It is the programmers that are important, not so much the languages, but languages do bias what kinds of programmers will use them.

See also why Linus' Torvalds prefers C to C++, it has not so much to do with the language itself but with the kind of programmers that use the language.

Re:The Python Paradox

[shutdown -p now]

I will say this in Java's favor, however: It's a language where the smartest can't write code that confuses the dumbest

Not really. They dug the grave for the dumb in 1.1 already, with inner classes; and nailed the coffin shut in 5, with generics. In 7, they are going to finally bury it with lambdas.

Me, I'm waiting eagerly to see what the next incarnation of COBOL turns out to be...

Re:The Python Paradox

[tsotha]

I will say this in Java's favor, however: It's a language where the smartest can't write code that confuses the dumbest, and where the dumbest can't write code that does too much damage.

That alone makes it the best language for large business projects. Your coworkers will be a mix of good and bad, and pretending the bad programmers is a more damaging mistake than anything you can do to the code.

Re:The Python Paradox

[Thinboy00]

I will say this in Java's favor, however: It's a language where the smartest can't write code that confuses the dumbest, [...].

In my AP computer science class, some of my classmates don't seem to grok the whole OO concept (i.e. if I create multiple interacting classes, it confuses them. They do however understand "[Type] foo=new [Type]();", but only for predefined types).

Re:The Python Paradox

[Anonymous Coward]

yes look up the candlestick experiment. It offers a scientific proof of the fact.

Re:The Python Paradox

[tepples]

I think php is rather an interesting case. Looking at SQL injection: the language is strong enough and easy enough to protect against attack.

Not necessarily. PHP database interfaces are capable of escaping scalars like numbers and strings. But they generally leave a couple major features (operator IN and query by example) unimplemented, and in these cases, the programmer has to resort to manually escaping each parameter. I've written more about it here.

Re:The Python Paradox

[MillerHighLife21]

The dumbest can write code that does a wealth of damage regardless of language and Java is no different.

Reasonable quality control measures can remove the issues pretty quickly. Code reviews for new team members until you can ensure a programmer is providing you at least "passable" code consistently will make sure that "the dumbest can't do do much damage."

It's all about the process.

Re:The Python Paradox

[tehcyder]

People who do anything because it interests & fascinates them on a personal level do better than those who are only in it for the paycheck. Doesn't matter whether it's programming, auto repair, landscaping, or anything else.

But if you are interested and fascinated in something on a personal level, you are likely to want to do that to earn a living if it is possible, so I don't see how you can make a sensible split between "gifted amateurs" and "professional drudges".

If I were a qualified and gifted chef, and would be cooking anyway for the fun of it, I doubt I'd go and get a job working in a call centre.

Re:The Python Paradox

[bar-agent]

People who do anything because it interests & fascinates them on a personal level do better than those who are only in it for the paycheck. Doesn't matter whether it's programming, auto repair, landscaping, or anything else.

Sure, but the trick is distinguishing those who do it out of fascination from those who do it for the monies. Luckily, programming has esoteric and academic languages that we can as an indication of the former. Not every field is so lucky. :)

Turing-completeness isn't the point.

[SanityInAnarchy]

Any language that lacks an inherent insecurity can be used to write secure apps, just as any language (Brainfuck, anyone?) can be used to write any program.*

You choose a language not because it makes it possible for you to do anything, but because it makes it easier than another language.

*I realize that there are cases where performance-per-core is critical, and that narrows your choices considerably. Still, in that situation, some use C, others use C++, and still others use Lisp.

Re:Duh

[Anonymous Coward]

Yeah cause a language that makes it trivially easy to overrun a buffer, dereference null pointers and smash the stack is clearly a highly secure language. Oh wait...

Only web applications

[CastrTroy]

I see the big problem here is that they are specifically talking about web applications. When you're doing web applications, the major security holes are SQL Injection, XSS attacks, HTML/Javascript Injection, and other such things. Nobody (almost) uses C for programming on the web. Of all the popular web languages PHP, .Net, Java, Python, and all the others, none of them use pointers, none of them require you to manage your own memory. This cuts out a lot of security exploits found in languages like C, in which the only thing left is other bugs like SQL injection. SQL injection is not something you can solve with a programming language. Unless your programming language didn't provide a way to run strings against the database, and only gave you access to the database through some object layer, like Hibernate or Linq, then there's nothing the language could do to stop stupid programmers from doing stupid things. There are constucts like prepared statements in all web programming languages, and there's no reason to have an insecure website, but the problem is, is that everyone wants a website, and doesn't want to pay qualified people to do the job. So they end up with insecure web sites.

Re:Only web applications

[Anonymous Coward]

I have to agree.

http://www.wickedfire.com/design-development-programming/90269-dear-php.html = a little gem I found while researching a problem

There you'll find gems from people like

dchuk who things mvc is some how source control

rage9 who is either a troll or an idiot

If the people in the thread are serious I couldn't tell, because half the shit they were saying was plain funny.

Re:Only web applications

[tepples]

There are constucts like prepared statements in all web programming languages

Prepared statements have their limitations, especially in cases where the number of placeholders varies from run to run.

Second idiotic article from 'WhiteHat Security'

[BitZtream]

Seriously ... spamvertise/slashvertise much?

This is the second retarded WhiteHat story posted in the last hour and a half, how much are they paying you guys and how do I sign up? I have at least 2/3rds of a clue and I'm willing to pay for slashvertisements, that puts me well above any offer they could possibly make short of owning you outright.

Re:Duh

[blair1q]

>Oh cool, is C ellipsis the new C sharp?

No, C... is secure and C# is not.

Re:Duh

[WrongSizeGlass]

C...

Oh cool, is C ellipses the new C sharp?

No, it's just another form of object notation in the next version of Objective-C. sigh ...

OVERSOLD/HYPED: 'Web programming language'

[david.emery]

1. The languages being considered/charted are ASP, ASPX, CFM, DO, JSP, PHP and PL (I can guess at most of these acronyms).

What's missing, obviously, are 'real' programming languages such as C, Java, FORTRAN, Ada, C++, Eiffel, etc.

2. A lot of these languages share a common (C) heritage, and I'd assert "inherit" a lot of the security weaknesses of C. That's particularly true of weak typing for scalars, including array bounds.

The conclusion I think can be drawn from this is that we need a substantial increase in Web Programming practices, including languages. Any other conclusion is overreach.

I'm secure

[SnarfQuest]

I've been using intercal, and so far noone has comprimised my code.

Re:I'm secure

[dwinks616]

I'm afraid you are mistaken. Someone obviously hacked your code and caused your computer to remove the space between "no" and "one." Either that, or you know someone whose name is "Noone" which is an odd name indeed.

Re:Duh

[Anonymous Coward]

joke, fail. you can pretend that you made a joke in response, but its just not funny

Steve Ciarcia on programming languages:

[ctrl-alt-canc]

"My favourite programming language is a soldering iron".

Re:Steve Ciarcia on programming languages:

[micheas]

Reminds me of one of my roommates in college.

He had a poster of the saying (IIRC) "real programmers don't use operating systems they write directly on the hardware as god intended."

Some truths are eternal

[overshoot]

"You can write a FORTRAN program in any language."

If anyone knows who deserves the credit for that one, BTW ...

Re:Some truths are eternal

[Anonymous Coward]

The exact quote is: "Besides, the determined Real Programmer can write Fortran programs in any language." It comes from a letter to the editor titled "Real Programmers Don't Use Pascal," attributed to an Ed Post.

Link.

Re:Some truths are eternal

[shutdown -p now]

Java designers made a cunning workaround for that by removing "goto" from the language, though.

Everybody hatin' on PHP

[jwietelmann]

PHP really is not that bad. Years ago it had a really horrible default configuration. But PHP, in my opinion, is viewed as worse at security than other scripting languages because it is more frequently used by people who have no business writing server-side code.

Re:Everybody hatin' on PHP

[CastrTroy]

PHP really is that bad. Because they still haven't removed the cruft. If they were really serious about any kind of security, they would have gotten rid of magic quotes completely, as well as things like mysql_escape_string. Instead they left these gaping security holes in there, for the sake of compatibility. Meanwhile you have a bunch of cheap web hosts who turn things like magic quotes on by default, thinking it will solve all their customers' security problems, when really it just extends the problem by leading them down the wrong path. While they've added things (MySQLi/PDO for prepared statements, mysql_real_escape_string, and others) the amount of legacy stuff they left in there is amazing, and for a language with so many novices working with it, ends up being a real disaster.

Re:Everybody hatin' on PHP

[binarylarry]

A more secure PHP option, Quercus.

Re:Everybody hatin' on PHP

[wmbetts]

Changes in PHP 6
Issue: Register globals are the source of many application's security problems and cause a constant grief.

Discussion: We shortly discussed how we want to attend users on the disappearance of this functionality. We decided that if we find the setting during the startup of PHP we raise an E_CORE_ERROR which will prevent the server from starting with a message that points to the documentation. The documentation should explain why this functionality was removed, and some introduction on safe programming.

Conclusions:

We are going to remove the functionality.
We throw an E_CORE_ERROR when starting PHP and when we detect the register_globals setting

http://www.php.net/~derick/meeting-notes.html#id12

Issue: Magic_quotes can be cumbersome for application developers as it is a setting that can be set to on or off without any influence from within the script itself as input parameters are escaped before the script starts.

Discussion: In the same way as with the remove of the register_globals functionality, we decided that if we find the setting during the startup of PHP we raise an E_CORE_ERROR which will prevent the server from starting with a message that points to the documentation. The documentation should explain why this functionality was removed, and point the users at the input_filter extension as replacement.

Conclusions:

We remove the magic_quotes feature from PHP.
We throw an E_CORE_ERROR when starting PHP and when we detect the magic_quotes, magic_quotes_sybase or magic_quotes_gpc setting.

http://www.php.net/~derick/meeting-notes.html#id13

They are also planning on getting rid of the non-PDO db stuff at a future date.

Re:Everybody hatin' on PHP

[abhi_beckert]

That doesn't mean an experienced PHP programmer can't write secure code. I write database driven websites 6 days a week in PHP, and never use any of the dangerous methods in PHP.

We have our own API for escaping SQL strings, our own API for pulling data out of the HTTP request, our own API for converting a string into html.

Yes, PHP has a bunch of crap, but no-one forced you to use them. It's perfectly feasible to treat PHP like a lower level language, such as C, where you're forced to write all those little utility functions, because they aren't built in.

Re:Everybody hatin' on PHP

[Anonymous Coward]

So we should look at PHP again when version 6 comes out, that's fine. Until then, "PHP really is that bad".

Oh say can you C

[SuperKendall]

Don't know where it went, but there was supposed to be a "C" in there and I swear there was one when I hit submit...

As it is though, I guess you can fill in your least favorite language!

Re:Oh say can you C

[K. S. Kyosuke]

Don't know where it went, but there was supposed to be a "C" in there and I swear there was one when I hit submit...

Between pressing 'S-c' and 'Enter', you had a race condition.

Re:Oh say can you C

[gbjbaanb]

he entered it, but the garbage collector ran before he had stored it in the slashdot comment list.

Re:Duh

[aBaldrich]

You can overflow your buffers, dereference null pointers and anything you want. But, hey, if you are a good programmer you know how to avoid them. And if you are not a good programmer then it does not matter what language you use.

Of course it does

[SuperKendall]

I didn't know Whitespace supported web services.

Sure it does, I had a full shopping cart system at the end of my post by way of example.

Prove me wrong... :-)

Re:Of course it does

[natehoy]

I tried to compile it, but I think you had a misplaced tab.

Re:Duh

[Anonymous Coward]

Well; perhaps if you NEVER make a mistake. NEVER modify other peoples code.
NEVER get any work done...

Java

[caluml]

I'm confused. When I was thinking of learning a new language a few years ago, I took a good look at them all (well, the top 5 to 10), and picked one based on how many jobs there were, pay levels, non-proprietary-ness, etc.

One of the things I liked about Java was that there aren't any buffer overflows to worry about. Well, apart from ones in the JVM, but they are few and far between.
I don't understand when people say that all languages are as insecure as each other. Sure, people can do stupid things like not check input, etc - but when it comes to finding some sort of buffer overflow in a function/library?
If I had to write a website that would be deployed onto a box which was not touched for 5 years, I imagine that a Java-based site would have a better chance of faring than a PHP one.

Re:Java

[Anonymous Coward]

I'm confused. When I was thinking of learning a new language a few years ago, I took a good look at them all (well, the top 5 to 10), and picked one based on how many jobs there were, pay levels, non-proprietary-ness, etc. ...

Wow. When I pick a language, I pick one based on how much I might enjoy learning it. I looked at .NET and Java and decided "You can't pay me enough...". And before someone says "How about for a million dollars...", well yes, then I'd learn'em. But you can't pay me a million dollars, so my statement still stands.

Re:Duh

[balbus000]

but its just not funny

No it's not. By now it's just sad.

dictionary.com?

[Anonymous Coward]

Wah, I am the worst programming language in the world, I am so insecure! Nobody loves me. Nobody cares about me. I can't do anything right. If only I were nonsecure instead.

So...

[Anonymous Coward]

In other words, for it to be non-secure you have to use deprecated features and be a novice. Which kind of proves the article's point.

Furthermore, you're perpetuating the myth that you can't write secure PHP or that writing secure PHP is difficult. In fact, you pretty much just prove the GP's point. PHP is perfectly fine, so long as the person who's writing it is not incompetant.

You wouldn't give a shotgun to a chimpanzee.

OK, then...

[humdinger70]

It's back to COBOL for you wankers.

A poor craftsman blames his tools

[CoffeeDog]

I think this is more a testament to the fact that crappy programmers will write crappy code in any language, instead of showing that all languages are equally as crappy for writing secure code. If the same person wrote the same program in different languages then you might have a fair comparison, otherwise this report just shows a similar ratio of bad programmers across different languages which I don't find all that surprising.

False dichotomy much?

[Hurricane78]

There isn’t just “secure” and “not secure”, you know? Some are more and others less secure.

And I have only one thing to say:

Haskell > Java > C :)

(Java has built-in checks that prevent the worst errors of C. And Haskell also has them, but at compile time, so you get back the performance. Of course those language are just examples, and any similar languages could be placed in there instead.)

Re:False dichotomy much?

[binarylarry]

In the case of an advanced JVM like HotSpot (the official Sun/Oracle JVM), you also get the performance back.

If the array bounds checking can be removed without compromising security, HotSpot's JIT compiler will do so when compiling the Java bytecode into native instructions.

Re:False dichotomy much?

[nacturation]

Or to paraphrase Orwell: "All languages are insecure, but some are more insecure than others."

Wow...

[Anonymous Coward]

You mean that application security is mainly affected by the person writing the code? Who could have predicted THAT one?

You're oversimplifying

[Anonymous Coward]

Simply put, the kind of people who learn a language out of interest than out of wanting to get a job tend to be better programmers on average.

People who do anything because it interests & fascinates them on a personal level do better than those who are only in it for the paycheck.

I'm going to have to disagree here. I have seen some code of a lot of crackpot geniuses in my time that was not worth a damn. Problem was, these guys were coding for the joy of it, but still working in a business environment. Which can turn out very badly when your programmer uses your very important application and its development as his personal programming playground. It's not that these people are bad programmers, but they are very often bad employees. Keep It Simple, Stupid has no meaning to them, and neither does pragmatism. When a programmer is coding just for the sheer joy of it, often the choices that bring them joy are not particularly useful or good for anyone else.

Re:OVERSOLD/HYPED: 'Web programming language'

[hAckz0r]

Agreed, I have yet to find a book on Web Programming in ADA, and I doubt if one ever did surface nobody would read it. Those features that make a language secure tend also to make it unpopular.

Re:Duh

[Anonymous Coward]

But, hey, if you are a good programmer you know how to avoid them.

So then how do you explain the existence of these problems even in code written by supposed "good" or even great programmers?

Re:OVERSOLD/HYPED: 'Web programming language'

[Hurricane78]

You forgot the functional programming languages, like Haskell, Ocaml, standard ML, Erlang, etc.
They usually have a track record of higher security without loss in performance (that Java has), since the checks can happen at compile time.

Of course you can still mess up things even in Haskell. E.g. [0,1,2,3,4,5]!!10 will cause a runtime exception. But the functions that can cause errors are well-known and can be avoided. Also, QuickCheck is a really great tool to test out all the possibilities.
If I ever had a heat-lung machine attached, I would want it to be written in Haskell. But never ever C, C++, or similar languages. Ever.

Re:OVERSOLD/HYPED: 'Web programming language'

[Anonymous Coward]

Oh no! Someone is wrong on the internet. I must correct them.

What's missing, obviously, are 'real' programming languages such as C, Java, FORTRAN, Ada, C++, Eiffel, etc.

No, many of the test pages are "real" programming languages, for any definition of "real" used by reasonable people. JSP and DO are Java. ASPX is based on the .NET framework. PL is Perl.

A lot of these languages share a common (C) heritage, and I'd assert "inherit" a lot of the security weaknesses of C. That's particularly true of weak typing for scalars, including array bounds.

No, Java, Perl, and C# do not share a type system with C.

What a dumb point...

[Anonymous Coward]

Sure, security is a matter of good coding habits. It still doesn't matter how good your habits are if the tools you use are insecure. Yes, PHP I mean you!

Re:Duh

[Hurricane78]

Ye Olde Excuse: “you’re just not good enough”

You know, in modern languages, you can once abstract that concept out that you don’t want buffer overflows and dereference null pointers, and you’re done.
In C, you have to re-invent the wheel again and again and do the same micromanagement over and over. It’s like the man with three buttocks on Monty Python: We’ve done that! We’ve solved it. We have nice standardized solutions. (Java doing runtime checks by default. And Haskell doing them at compile time.) Use them!

With modern languages, you can use your mental resources to tackle the actual problem, instead of having to constantly think about decades old and long solved problems that should long be included by default.
And the biggest joke is, that most C programmers manually implement those systems themselves, and then act all proud, because they re-invented the wheel, except that it never received the literally decades of testing of the well-studied existing solutions.

It’s dumb. Like those people re-implementing standard library functions. It’s unprofessional and inefficient. And very error-prone for no reason at all.

COBOL

[DarthVain]

Thousands of Banks can't be wrong! Right?

Re:Duh

[Hurricane78]

You got a nice statement there. Care to back it up with some actual arguments? You know:

I'm afraid it's you who is insecure, not C, because...

Re:Duh

[Anonymous Coward]

I agree that it's not very funny, but it's pretty obvious that it was intended as a joke.

This is absurd.

[Maltheus]

Sure, if you take extra precautions with the buffer-overflow languages, your software can be just a secure. But in the real world, that's almost never the case. Projects are always rushed and mistakes happen. Every team has one or more weak links. And what coder prefers burdensome process to development anyway? Anyone who promotes C/C++ over Java for a back-end enterprise application is not a professional IMO. They come across as stubborn basement hackers who can't keep their resumes up to date. C/C++ was never much more than a macro assembly language, and like assembly, not appropriate for most (non-single-person-genius) projects.

Re:This is absurd.

[gbjbaanb]

Anyone who promotes C/C++ over Java for a back-end enterprise application is not a professional IMO. They come across as stubborn basement hackers who can't keep their resumes up to date

anyone who promotes Java over .NET is not a professional IMHO. They come across as ex-web hackers can't keep their resumes up to date.

Place your votes for next year's 'ultimate' language.

But who provides the language implementation DOES

[khb]

http://www.c-program.com/kt/reflections-on-trusting.html is worth another read. Apple can make a reasonable case that allowing other development tools in their little garden reduces their ability to ensure a secure system.

I concur with posters who observe that some languages do have more protections than others; but in the end the application programmer needs to be careful and security aware, and there has to be complete trust in every step of the processing from what the programmer writes to what is run on the device.

Now whether the loss of flexibility is worth having to trust only Apple is a reasonable policy question; but I can see why Apple might want to be draconian about this.

Re:Duh

[Twinbee]

It's dumb. Like those people re-implementing standard library functions. It's unprofessional and inefficient.

I thought that too until I found the bottleneck that is converting from float to int using (int) casting. I found the following to be multiple times faster:

unsigned floatToInt(double d)
{
        d += 4503599627370496.0; // 1 52
        return (unsigned &)d;
}

Re:Duh

[Joce640k]

You mean like using std::vector and std::string instead of malloc, smart pointers instead of raw pointers and manual memory management?

We did all that years ago...it's only the uneducated C hackers who keep giving C++ a bad name.

Re:Duh

[Tyler Durden]

There are still tasks that are better suited for languages like C and C++. The interesting ones. The alternatives?

"You mean I get to build another boring business web application using the latest kludgy framework du jour so that it's obsolete two weeks later when the more popular kludgy framework comes out. Oh boy!" (OK, it's a little bit better than that. But not much. :) )

Games development, systems development, OS development, embedded programming and the like are places where it pays for development to be done by people who know what they're doing using tried and true programming tools that demand such expertise. When did Slashdot become so dull that nobody was interested in this stuff anymore?

There's also the fact that

[warrax_666]

There's also the fact that in Haskell (or, say, O'Caml) you can structure your application's interface to the web such that you cannot (by abstraction) do unsafe things unless you really want to(*). If you have such a framework the programmer has to be actively working against you to do unsafe things. (And there's nothing that can save you from an actively destructive/malevolent programmer inside your organization.)

(*) Define Unsafe/Safe string variants and force all strings trough Escape/Unescape for all transitions between those two.

Never underestimate incompetence

[Moraelin]

Never underestimate incompetence. Sure, Java protects you against some kinds of buffer overflows (but then a couple of versions had such vulnerabilities in their native parts of the JRE instead), but it doesn't protect against any other kind of incompetence.

There are probably a few SQL injection vulnerabilities and an XSS exploit being written somewhere right now. And someone out there is writing a servlet which reads and writes files off the hard drive, but isn't checking the paths, so really you can request the registry of that machine or anything. Someone else is putting a confidential document in there, betting on no more security than that nobody will think to look in that directory. Someone else is configuring a Lucene indexing and search which can bypass any access controls and find it. Someone else is coding a remote admin backdoor in the client's site, because it makes supporting it easier. Someone else thinks the users never reach pages except by clicking on the provided links, so he actually never checks parameters, and you can substitute your own id with the admin's ID on the page to change your password. (I've actually seen that one in a big money B2B site coded by expensive consultants from a big corporation.) Someone else out there is running half the company on the same user ID and password, because they can't be arsed to get a different password for the secretary than for the CEO, or because dealing with the IT department to get one involves more bureaucracy than that Asterix episode. (Invariably when some employee which used that account leaves the company, that account doesn't get its password changed or anything.) Yet someone else packs data the user shouldn't see or edit in hidden input fields or uses XPaths for input field ids, and blindly trusts whatever he gest back in those fields. (Then wonders why the user accepted the price for a Fiat 600 but could change the car model to a Lamborghini;)) Etc, etc, etc.

And, ironically, the myth that C is more dangerous than "sweating" dynamite while Java is physically impossible to break, only generates complacency in QA and hiring even less qualified burger-flippers for Java. I've seen I R Java Dev types which didn't even know what an SQL injection was before seeing it demonstrated to them. On the production machine.

And worse yet, you see a bunch of them arguing online, that SQL injection and XSS vulnerabilities are harmless and unavoidable, that the supposed danger is only hype, and that asking them to fix it is just stupid. And at least one such article was even linked to by Slashdot in the past.

Re:Never underestimate incompetence

[Thinboy00]

Just because a bunch of Java programmers are morons doesn't mean the language sucks.

gets(), the C standard library standard bug.

[Ungrounded Lightning]

Languages maybe. Standard libraries, oh boy for sure.

From the man(3) page for the set of functions including gets():

BUGS
              Never use gets(). Because it is impossible to tell without knowing the
              data in advance how many characters gets() will read, and because gets()
              will continue to store characters past the end of the buffer, it is
              extremely dangerous to use. It has been used to break computer security.
              Use fgets() instead.

gets() is the C standard library standard buffer overflow bug.

Re:gets(), the C standard library standard bug.

[shutdown -p now]

gets() is officially deprecated in ISO C99 standard, though, and will be removed entirely in ISO C1X. Most compilers today (even non-C99 ones) will output a warning if they see it, and warnings-as-errors is standard development practice for C/C++ these days.

Also the "secure" functions in TR 24731 (strcpy_s, strcat_s etc) will be part of the base standard library in C1X.

Use taint

[Anonymous Coward]

It's a start.

if I want to be a little secure I take bash ...

[Anonymous Coward]

... instead of php or perl.
Yes, simple shell script.
The risk of actually executing a variable contents is quite low compared to other languages who easily spawn a system shell call. If you are already in a shell, it's not getting spawned (except if you construct things like "|bash" or "eval ...")

So, the shell script is more secure than other languages.
Maybe C or java is in the same league as those don't do system shell calls when you don't suspect it.

Re:if I want to be a little secure I take bash ...

[FormOfActionBanana]

I wonder what other data flow sinks exist other than executing a shell call...
  - Log entries
  - File names
  - environment variables ...

Re:Duh

[shutdown -p now]

Games development, systems development, OS development, embedded programming and the like are places where it pays for development to be done by people who know what they're doing using tried and true programming tools that demand such expertise.

And yet all those categories of applications have buffer overflow etc bugs routinely found in them, and this doesn't seem to be ending. So much for "expertise".

Re:OVERSOLD/HYPED: 'Web programming language'

[shutdown -p now]

... "inherit" a lot of the security weaknesses of C. That's particularly true of weak typing for scalars, including array bounds.

Can you explain what you mean here?

Re:Duh

[Tyler Durden]

Sure these categories of applications occasionally have bugs. They're difficult to do. What do you expect?

However, how often they happen are pretty exaggerated as well. The Linux kernel is mostly written in C, of course. How often do you see it lock up for as difficult of a piece of software that is to write? How about all the millions of embedded pieces of code for mission-critical application that perform flawlessly day after day to the point that nobody notices them?

Besides for every C++ desktop app that crashes, there's a Java equivalent that eats up memory until it's unresponsive. People only focus on the C and C++ varieties of problems because they're taught Java or something similar as a first language and assume that lower level languages must be unmanageably difficult.

Levels of danger

[SuperKendall]

Sure, Java protects you against some kinds of buffer overflows (but then a couple of versions had such vulnerabilities in their native parts of the JRE instead), but it doesn't protect against any other kind of incompetence.

That is very true. But it's also true that C has buffer overflows in addition to all the other issues you mentioned. So inherently, it is worse because it always has at least that one other thing to worry about Java does not have.

Not to mention the core Java language has things like easy to use prepared statements for when you realize you do need to worry about SQL injection, whereas with C the ease of protection would depend on the library you were using.

culture

[epine]

I've done a lot of embedded development, some of it in the security sector, which is not tolerant of sloppiness.

One of the products had a web interface implemented in PHP, which I partly coded. I don't use PHP regularly, so I was entirely at the mercy of the PHP online documentation. This was a few years back, but my god was it a struggle to glean from the documentation the bounds of validity of the different PHP function calls. In many cases I had to resort to untangling a long and often contradictory discussion thread trailing at the bottom of the API documentation. I was brutally easy to get my C code right because I was coding against APIs which I rigorously understood. I never felt half as confident in my PHP code.

In several cases, the PHP documentation should have just said "this is exactly what you have to do to properly escape input into this function" and it didn't, not even close.

Because the documentation sucks, it's impossible to be rigorous coding any acceptable speed for your typical web application. No one wants to pay people to code web applications on slow and methodical embedded application time frames.

Ultimately what drives bug are high expectations and sloppy API documentation. Sloppy documentation of APIs is greatly enhanced if the API itself was stupidly designed. Good design leads to simple documentation.

One more example. In my embedded work, when I have to ensure that output from one module is valid as input to the next module, I only use positive filters: I match on known good patterns. Never filter by subtraction of suspected evil, you'll end up missing something. If your filter is too conservative, you'll find out about it, from a bug report, rather than an exploit. Do PHBs running web development shops accept that trade off? Or is the attitude to err on the side of uptime, security be damned?

Mostly it's culture, not language.

self-proclaimed "ninja" it would seem....

[BestNicksRTaken]

a security "ninja" who uses windows xp for everything? its a bit like a design "guru" who uses mspaint on a monochrome monitor.

and yeah its kind of obvious its not really down to the language, its down to the programmer. a little surprised by the stats though - i'd have thought perl hackers would have more security know-how than your average java monkey.

Bogus article title and bogus conclusion

[haruchai]

There''s a hell of a lot more to programming than just Web programming and there are a lot of real programming languages that go to great lengths
to make secure programming easier.

The Security Ninja is a paper tiger.

oh!!!

[nimbius]

"By analyzing the vulnerability assessment results of nearly 1,700 websites under WhiteHat Sentinel management"

i saw what you did there...

Re:Duh

[Anonymous Brave Guy]

We did all that years ago...it's only the uneducated C hackers who keep giving C++ a bad name.

Well, that and the facts that

• even std::string has a fairly poor interface,
• many popular libraries still use char* or their own incompatible string types because C++ didn't have its own at first,
• the default indexing operator in std::vector is the unsafe one while you have to do something special to get the range-checked version, and
• even well-established smart pointer libraries are rarely up to the standard of the built-in GC in many newer languages' runtimes,

anyway.

language safety vs programmer ability

[j1m 5n0w]

I don't know if I agree; haskell programmers tend to be demographically more experienced (it's the only language I know of where it seems that the median programmer has or is working on a PhD), but I would also trust a relatively inexperienced programmer to write fairly good code in Haskell, especially if they used an existing web framework like HappStack. Static typing and well-defined libraries go a long way towards making it hard to do the wrong thing. This is one of the things I find compelling about Haskell - you don't have to be some kind of awesome programmer to be able to write solid applications.

I feel like web security is like a bunch of switches that you have to know to turn off - training can help, but it's better if those switches are not just off by default, but hard to turn on. For instance, I used HappStack to write a simple web app, and never worried about escaping strings. Once things were working properly, I thought, "ok, now let's fix all the security holes I've left lying around and do some proper string escaping". I discovered, when I tried to enter html tags in one of the input forms, that the html library was escaping the strings for me, and I didn't even know it.

There is, of course, a steeper learning curve, and you won't find a pile of books to tell you how to use HappStack, like you would if you were using a more mainstream framework. This contributes to sampling bias; the mediocre or poorly motivated programmers are likely to give up, so it would be difficult to test my hypothesis.

Re:Duh

[thenextstevejobs]

Yeah totally! Who's ever seen a null pointer dereference crash a Java program?

I didn't RTFA but I agree with the sentiment of the summary. It's NOT THE LANGUAGE, it's the programmer and their knowledge of the interfaces they are working with.

plenty of things can and should be written in C. It is perhaps a sharper blade than Java, but were professionals. There's 100 other mistakes you will make being uncareful when programming that have nothing to do with language choice that are far more important to worry about.

this checked exception hands tied stuff is worse than baby boomer nanny state bullshit

Never said that Java sucks

[Moraelin]

I never said that Java sucks. But it seems to me like TFA has a point. You still need to educate your devs and take security seriously. There is no magic amulet that you can just put on and be immune from security problems.

Not that huge a difference

[Moraelin]

As you probably know already, virtually any CPU manufactured in the last years has some form or another of "no execute" flag. So someone could overflow your buffer all right, and... simply not be able to execute any code injected that way. And someone from the BSD gang could even add here that in their world they had a solution for that even before that.

And someone who is security-minded, since that was the thrust of the article anyway, will have used some C++ library or another that checks string bounds. Heck, it's trivial to write one yourself if you don't find one to your liking.

So being only 99% as vulnerable as before, well, still sucks.

In the end, the point isn't "Java sucks" or anything, but that basically the largest difference is in having your people be security minded. Between the team who programs in language X and is basically a bunch of paranoid pessimists who know that Murphy rules supreme and anything that can be broken will be broken, and the team who ploughs through language Y thinking the language alone lets them not bother with that kinda stuff, generally the former is the safest bet. Regardless of whether X = Java and Y = C++, or viceversa.

And knowing that about the prepared statements, or even that SQL injection can be a problem, well, that's already one step closer to the former.

Re:Duh

[Cyberax]

>Games development
Game developers are desperately looking for something, anything better than C++. C# is looking better each day.

Unfortunately, the choice of C++ is often dictated by externalities (no C# on PS3, etc.)

>systems development, OS development
There are several OSes developed in Java, C# and other languages. I'm pretty sure we'll move away from C-based OSes in 'near' future.

>embedded programming and the like
And it's more and more irrelevant (Moore's law). It's quite often easier to use more expensive embedded system then to pay for more complex development.

>are places where it pays for development to be done by people who know what they're doing using tried and true programming tools that demand such expertise
Hammer and a spade are also tried and true tools. But somehow I don't see people building bridges and tunnels exclusively with spades and hammers.

Re:Duh

[Tyler Durden]

Game developers are desperately looking for something, anything better than C++.

Citation needed. Maybe some tools in addition to C or C++ in some cases.

There are several OSes developed in Java, C# and other languages. I'm pretty sure we'll move away from C-based OSes in 'near' future.

Just because you can develop OSes in Java or C# (or parts of it anyway) does not mean it's a good idea. Web development can be done in C or C++, and it's equally stupid to do so. Unix variety OSes moving away from C is not bloody likely. Maybe parts in C++, if that. I'm pretty sure you're wrong.

Hammer and a spade are also tried and true tools. But somehow I don't see people building bridges and tunnels exclusively with spades and hammers.

Java is closer to a Tonka Toy Construction Set than C is to a hammer and spade. Sometimes close control of hardware and predictability on when memory is being released are good things. After you have some experience using RAII, you begin to realize what a kludge those damned finally blocks are.

Re:Duh

[Z00L00K]

All languages have their own problems, risks and limitations.

If you select a language that has a lot of built in checks you will end up with bad performance as well as limitations in functionality. A language with few checks like C demands more of the programmer in order to verify that things don't go out of hand but it will also offer a lot more performance.

There are a lot of "funny" implementations that can be found, some relies on garbage collection as the ultimate savior others rely on absolute object-orientation and yet others rely on typing the variable as it is assigned (as often is done in Basic among other languages).

What really matters for security is not only the language - the language is just a basic tool like a screwdriver, the design is more important. And if you have tools that supports you in order to avoid mistakes - like Lint or Findbugs you are a few steps further into a secure solution. But if the overall design still is bad then it doesn't matter what tools you are using. A moron can use a finely tuned instrument as a hammer.

Then there are different causes for security problems. Bad basic design is one, but another is extensions and maintenance of a legacy system. Adding new features exposes functionality in the original system that wasn't intended to be exposed and may therefore lack security constraints. The security constraints may have been in the calling procedure of the original system, so it wasn't a problem there.

Re:Duh

[Pinky's Brain]

Tim Sweeney regularly pontificates on the need of a new language.

Although I think his love for functional programming and STM is misguided ... I think Occam-pi is a better example of the way forward for parallel programming.

Re:Duh

[nacturation]

C...

Oh cool, is C ellipses the new C sharp?

No, it's just another form of object notation in the next version of Objective-C. sigh ...

I take it that was an objective sigh?

Re:OVERSOLD/HYPED: 'Web programming language'

[Anonymous Coward]

FORTRAN? a C heritage?

C can be coerced into C linkage, but that's about it.

FORTRAN - 54
C - early 70s

(yes, my day job is FORTRAN, C/C++, python and the rest)

Table-valued parameters?

[tepples]

Not to mention the core Java language has things like easy to use prepared statements for when you realize you do need to worry about SQL injection

But can Java use table-valued parameters in a prepared statement? For example, SQL's operator IN takes a single-column table as its second argument. if I am writing a SELECT query that uses WHERE username IN ('alice', 'bob', 'charlie'), the existing database interfaces for PHP and Python don't let me do WHERE username IN ? and pass in an array. Instead, I have to either A. write a function to escape the list myself and use that throughout my program, or B. write a function to make an appropriately long list of ?s and then append the list of arguments, which doesn't work if the database interface expects there to be a fixed number of ?s in a given statement *cough*PHP mysqli_bind_param()*cough*.

Return to Oz? No, return to libc.

[tepples]

virtually any CPU manufactured in the last years has some form or another of "no execute" flag. So someone could overflow your buffer all right, and... simply not be able to execute any code injected that way.

That's what NX's proponents thought until someone figured out how to return to libc. Even in an NX environment, an attacker can use the stack as a virtual machine, calling one function after another as each function returns.

Silent failure: customers take business elsewhere

[tepples]

If your filter is too conservative, you'll find out about it, from a bug report, rather than an exploit.

No, you'll find out about it when customers affected by the overly conservative filter take their business elsewhere because they can't get your broken-ass site to work. For example, you won't find out about a character whitelist for shipping addresses that doesn't include any code points above U+0080 until you aren't getting as many international orders as you expected.

Re:Duh

[gbjbaanb]

It is perhaps a sharper blade than Java, but were professionals.

No, we're not. We're the cheapest, project-managed bunch of attention-deficit fools that ever wore a suit. Once we tried to do things right, to code correctly and bugs were a major source of embarrassment and shame. Now, we can't wipe our bums without a framework and instructions copied from the internet. And once we have learned how to do that, we decide its not good enough and we need another new framework, possibly language and architecture and start all over again.

I have a feeling the masses of choice has made us like this. Once we did it all in a couple of langauages and all was ok - but now, there are so many languages that we are locked into a never-ending cycle of always looking for something else. Never satisfied with what we've got, possibly because once we do become settled (and happy), the world changes and its time to get back on that merry-go-round and learn something else that is the 'new big thing'. Which often turns out not to be quite so good as it was hyped up to be. which often makes us look for something else to satisfy that void the marketing men promised us we'd have.

In addition, this has turnd us from true professionals to hyper-active attention-deficit internet-addicted 'coderz', and so its no wonder management has stopped thinking of us as the boffins and started to treat us like children - one programmer is just as good as another is a mindset they have now, which in turn has led to all that outsourcing. Why pay for an expensive coder when you can get a cheap one, they're all the same nowadays, coding is easy, they have all these easy-to-use frameworks, languages and tools.

So, yes, on an individual basis its not the language its the skill of the worker. For the programming community as a whole, its not the individual it is the languages.

Hmm. I need to get out and find more beer!

And here we go again

[tuomoks]

"One of the things I liked about Java was that there aren't any buffer overflows to worry about. Well, apart from ones in the JVM, ..." - one thing I like about assembler that there aren't any buffer overflows to worry about. Well, apart from ones the programmers do! See - same problems, again and again.

Who do you think creates the objects, methods, interpreters, (just in time) compilers, APIs, etc? Maybe programmers(?) - make an error or even worse, design a "bad" object, API, compiler, etc and you have problems!

A rant - one time, a long time ago, I designed an (unfortunately "proprietary" - I know, corporations suck!) "application" interface, supports all the languages we tried over 35 years (really, from Cobol, ADA, Fortran, C, AWK, REXX to Java, Erlang, Python, Delphi, C#, Unix and Windows shells, etc with Oracle, MySQL, PostgreSQL, Cache, C-tree, native filesystems, and so on), is used in networked (from async, bsc, X.25 .. to SNA, IP - all TCP/UDP/SCTP/...) , distributed, clustered, whatever environments with several Unix, Linux, Windows, Tandem Guardian and NSK systems (tested with even more exotic but not in production), blah, blah, blah. Now - used in fail safe, fail over, HA, etc wireless and wired systems and so on, and so on.

The purpose about that rant - yes, there has been some "security" and other problems but not with languages used, the problems were at first with the interface design, didn't get everything right at first, later in coding of the interface but - the late versions really have zero "security" problems, no matter in what language the "application" is coded, the interface was / is protecting against any such problems. Now - logical or on purpose problems, that's another story totally but has nothing to do what language is used.

Anyhow - you can use any language to code insecure applications, whatever. None is better or worse in that sense, well you can do that easier in assembler if you know what you are doing but I digress. I don't know about anybody else but what I see today is that programming skills on that level have gone down a lot? Thinking and understanding has been replaced by certificates, strange titles or just purely "do as I say"! You think that our systems, operating or application, would be on the level they are if everyone would have used just the "real", licensed, by manager (wow!!) certified / allowed methods/ways, etc when creating the systems we have today? Maybe time to go "back to the roots" and stop this "which language, OS, whatever" is the best?

Re:Duh

[K. S. Kyosuke]

You got a nice statement there. Care to back it up with some actual arguments?

...because I was trying to make a joke, since the GP sounded like having a bad case of C allergy. Therefore, I meant it only half-seriously.

Frankly, I like C, but I try to keep it at the necessary minimum. I can't avoid it, though, since for juggling bits around, there's still nothing better (and portable and widespread at the same time) for that purpose.

(On that note, why the hell is popcount for longs in Java ten times slower than the same code in C? I thought that the HotSpot folks had ironed out that one a long time ago. After all, it's just manipulating with - I hope - rather fast primitive types.)

Re:Duh

[K. S. Kyosuke]

After you have some experience using RAII [wikipedia.org], you begin to realize what a kludge those damned finally blocks are.

Funny that the C++ people seem to be the only ones who think this way, while everyone else seems to be sold on GC (a huge concurrency enabler) and guarded blocks such as finally in Java, or simply cleanup blocks of the "control flow methods" in Smalltalk etc. Is everyone else wrong and the C++ guys the only ones right or what?

(And frankly, any X programmer bent on criticizing the Y language for being kludgey should first learn Self.)

Thanks

[Weezul]

I'd say that's very good news for PHP users, that said I'm unsure why PHP exists. Perl is rather "choosy about it's friends", but Python and Ruby obliterate PHP while being incredibly easy for everyone. To me, there is only one viable reasons for using PHP : You want cheap replaceable programmers so badly that you need a language so brain dead nobody will ever write anything clever and confusing.

Re:Thanks

[Anonymous Coward]

You want cheap replaceable programmers so badly that you need a language so brain dead nobody will ever write anything clever and confusing.

There are a staggering amount of PHP jobs that involve trying to fudge two custom-made legacy content-management systems together (more to the point, copy-and-paste and modify-where-necessary)

This is because someone sold the idea that their custom-made CMS is better and suddenly realised it will take a lot longer than writing some fresh code, and it needs to interact with the already existing database (with hundreds of thousands of records), thusly the best course of action is to take the legacy code and wrap the new CMS around it.

Except ..

[Weezul]

.. PHP's raison de etre has always been using cheap less experienced easily replaceable programmers. You start losing those benefits once you build your API.

Re:Duh

[boa]

"It’s unprofessional and inefficient. And very error-prone for no reason at all."

There are many good reasons for choosing C over C++, Java or other languages. The most obvious reason is that C is the only language available for the target platform. Performance requirements (both size and speed) are also good reasons for choosing C.

Re:Duh

[vcompiler]

C++ has many good libraries to solve problem like "string" and "memory management." The problem is they are libraries rather than language constructs. For example, shared pointer is a good thing, the problem is, because it is not language constructs, different third party libraries in your program may use different shared pointers mixed with raw pointers which makes the reference counting as unmanageable as they had not existed.

Re:Duh

[dave87656]

>embedded programming and the like
And it's more and more irrelevant (Moore's law). It's quite often easier to use more expensive embedded system then to pay for more complex development.

My experience has been, that every software system which has taken that approach, was written so inefficiently and was so slow that it frustrated users or was just plane unusable.

Case in point, our mfg software written for slower processors at the time and we didn't fall for the trap of assuming that faster processors would take up the slack in the future. We just took over a company which took a different approach. Their software was so slow in the end that their $100,000 server couldn't keep up. We moved them over to our software which is now running efficiently on a Dell Vostro desktop (running as our server) with an Intel E8400 processor and 4G of memory, which cost about $500.

BYW, the software was written in Java, which, despite rumors, is quite fast now.

Re:Duh

[alexo]

>embedded programming and the like
And it's more and more irrelevant (Moore's law). It's quite often easier to use more expensive embedded system then to pay for more complex development.

Moore's law does not apply to battery life.

What is the real issue?

[Anonymous Coward]

I guess it depends on the type of security breach we're talking about. Are we talking about buffer overrun? Are we talking about script-based attacks like XSS? Do you include flaws that produce SQL Injection attacks?

People can definitely protect themselves against XSS, CSRF, and SQL Injection attacks (and all other forms of nasty acronyms) by developing their code properly. If, on the other hand, we're talking about an expoit to the program that runs that language itself... that's up to THEIR developers to fix.

Re:Duh

[exomondo]

so because there is the ability to have buffer overflows and dereference null pointers that makes it inherently insecure? No, it means you can create an insecure implementation out of it. Just because threading concepts have the potential to create a deadlock doesn't mean the concepts are inherently buggy, just a bad implementation. Just because you can crash your car and die doesn't make the act of driving 'deadly', just a bad situation.

It's not to do with the language, concepts, etc...it's the implementation created by the user of those languages, concepts, etc...

+5 Insightful

[neiras]

In addition, this has turnd us from true professionals to hyper-active attention-deficit internet-addicted 'coderz', and so its no wonder management has stopped thinking of us as the boffins and started to treat us like children.

1. Hit nail on head
2. Sit back
3. ????
4. Karma!

"clever and confusing"

[Anonymous Coward]

Ohhhh great, you're THAT guy. The guy who writes "clever" code that no one else knows instead of operating with established conventions and design patterns that are usually at least as efficient if not more so. Thanks for providing me years and years of employment, replacing systems written by people like yourself, who use corporate projects as their own personal computer science playground rather than keeping it simple, manageable, and affordable for the long term.