Slashdot Mirror
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.'"
fp
This is because all of these web languages are implemented in C which is THE most insecure language ever designed.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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
"Maybe this world is another planet's hell"
Aldous Huxley
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.
In soviet russia the government regulates the companies.
'Cause even if the source is available, the would-be attacker won't be able to understand it!
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.
"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.
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.
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
You mean I am actually supposed to know what I'm doing?!
If you know what programming language a programmer uses you can tell if they know what they are doing or not.
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
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)
93rd rule of Slashdot: No matter how obvious my sarcasm is, my comment will be taken seriously by someone.
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.
Don't thank God, thank a doctor!
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.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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've been using intercal, and so far noone has comprimised my code.
Who would win this election: Andrew Weiner vs Andrew Weiner's weiner.
"My favourite programming language is a soldering iron".
If anyone knows who deserves the credit for that one, BTW ...
Lacking <sarcasm> tags,
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.
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!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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... :-)
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
Get your own free personal location tracker
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.
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.
It's back to COBOL for you wankers.
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.
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.)
Any sufficiently advanced intelligence is indistinguishable from stupidity.
You mean that application security is mainly affected by the person writing the code? Who could have predicted THAT one?
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.
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.
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.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
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.
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!
Thousands of Banks can't be wrong! Right?
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.
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.
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.
HAND.
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.
A polar bear is a cartesian bear after a coordinate transform.
Languages maybe. Standard libraries, oh boy for sure.
From the man(3) page for the set of functions including gets():
gets() is the C standard library standard buffer overflow bug.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
It's a start.
... 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.
... "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?
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
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.
#include <sig.h>
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.
Pain is merely failure leaving the body
"By analyzing the vulnerability assessment results of nearly 1,700 websites under WhiteHat Sentinel management"
i saw what you did there...
Good people go to bed earlier.
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.
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.
A polar bear is a cartesian bear after a coordinate transform.
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.
A polar bear is a cartesian bear after a coordinate transform.
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)
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*.
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.
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.
"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?
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.
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
.. 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.
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
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.
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!
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.