Forgot your password?
typodupeerror
Programming Security IT

Choice of Programming Language Doesn't Matter For Security 192

Posted by Soulskill
from the obvious-things-your-boss-doesn't-understand dept.
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.'"
This discussion has been archived. No new comments can be posted.

Choice of Programming Language Doesn't Matter For Security

Comments Filter:
  • by SuperKendall (25149) on Friday May 07, 2010 @02:41PM (#32130968)

    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:Duh (Score:1, Informative)

    by Anonymous Coward on Friday May 07, 2010 @02:51PM (#32131204)

    True.

    A system without any users is secure.

  • The Python Paradox (Score:4, Informative)

    by calmofthestorm (1344385) on Friday May 07, 2010 @02:52PM (#32131224)

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

    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:Perl most secure (Score:3, Informative)

    by crow_t_robot (528562) on Friday May 07, 2010 @03:02PM (#32131402)
    Perl is terrible but Malebolge takes the cake: http://en.wikipedia.org/wiki/Malboge_(programming_language) [wikipedia.org] Enjoy your brain exploding.
  • by Anonymous Coward on Friday May 07, 2010 @03:22PM (#32131686)

    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. [pbm.com]

  • by bmajik (96670) <matt@mattevans.org> on Friday May 07, 2010 @03:49PM (#32132084) Homepage Journal

    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).

  • by eulernet (1132389) on Friday May 07, 2010 @04:06PM (#32132342)

    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 [wikipedia.org]
    with an example here:
    http://stackoverflow.com/questions/381171/help-me-understand-this-javascript-exploit [stackoverflow.com]

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

  • by wmbetts (1306001) on Friday May 07, 2010 @04:11PM (#32132436)

    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 [php.net]

    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 [php.net]

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

  • by shutdown -p now (807394) on Friday May 07, 2010 @06:33PM (#32133580) Journal

    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 [us-cert.gov]) will be part of the base standard library in C1X.

1 1 was a race-horse, 2 2 was 1 2. When 1 1 1 1 race, 2 2 1 1 2.

Working...