<!DOCTYPE html><html><head>
<style type="text/css">body { font-family:'DejaVu Sans Mono'; font-size:12px}</style>
</head>
<body><div>Hi,</div><div><br></div><div>I have been following this debate about PHP. To summarize:</div><div><br></div><div>1. PHP has some problems that can easily lead to website vulnerabilities if the programmer does not take precautions to prevent. PHP appears to have more of these problems than Python/Django, Ruby on Rails, or .NET. So if you can use something else, this is the preferred route.</div><div><br></div><div>2. PHP being relatively easy to learn and very common for webscripting is often used by poorly supervised, inexperience programmers who do not security best practices. Whether the programmers know about the best practices is often problematic since some are really web designers not programmers. Python and Ruby seem to be more complex than PHP but still fairly easy to learn. Given many webdesigners do not really like programming this could be an issue. I do not know much about .NET or Perl.</div><div><br></div><div>The combination of the two can lead to some very disasterous problems for a website. Which issue is the most important? I would tend to lean towards 2 by a nose because even if the PHP problems were largely cleaned up in say version 6 an inexperienced programmer will make serious security mistakes. Or if another language was used poor coding, and inattention to security is still a major problem.&nbsp;</div><div><br></div><div>On Mon, 22 Jul 2013 09:57:25 -0400, Andy Borgmann &lt;andy@borgmann.me&gt; wrote:<br></div><br><blockquote style="margin: 0 0 0.80ex; border-left: #0000FF 2px solid; padding-left: 1ex"><div dir="ltr"><div>Facebook hasn't had any hacks that I am aware of. &nbsp;I know they release a lot of information via Graph and other areas, which leads many of us to feel uncomfortable with there security practices. &nbsp;But it seems all the information that is released, is released by design. &nbsp;And I don't see how just because they run PHP through HipHop (which they created) to run there code through C and C++ for <i>performance reasons</i>&nbsp;makes it anymore secure than standard PHP?</div>
<div><br></div><div>Also, just because PHP can be written poorly and that it attracts beginner developers, doesn't mean that it is by itself an insecure language - it just means those applications with poor coders are insecure. &nbsp;Also, your reason #3 would speak to the inefficiency of PHP but I don't see how it speaks to the insecurity of PHP.</div>
<div><br></div><div>To me the larger issue always seems to be with code that is available for public distribution (i.e. WordPress, phpBB, etc...). &nbsp;If people can peer into the code and find the vulnerabilities and exploit un-updated versions of it, it makes sense that <i>they</i> are insecure. &nbsp;But not that the platform itself is insecure. &nbsp;But if you're code is never released publicly, and you take good measure to secure the server (which is more of a Linux thing anyways assuming a LAMP stack), then how is it PHP's fault?</div>
<div><br></div><div>Also, isn't SQL injection pretty much fixed with Magic Quotes? &nbsp;I had a security guy from GA Tech test my site once and was unable to SQL inject attack the site. &nbsp;I thought this was largely due to the fact that any $_POST to the site is automatically escaped via Magic Quotes.</div>
<div><br></div><div>I appreciate the articles Charles has submitted. &nbsp;I will read those for sure.</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div><b><br></b></div><div><b>--</b></div>
<div><b>Andy Borgmann</b><br><br><div>E-mail: <a href="mailto:andy@borgmann.me" target="_blank"><font color="#990000">andy@borgmann.me</font></a>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;<br>Cell Phone:&nbsp;<font color="#990000">(404) 492-6527</font>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</div>
<div>Personal Website: <a href="http://andy.borgmann.me/?r=email" target="_blank"><font color="#990000">http://andy.borgmann.me/</font></a></div><div><br>"<i>Preach the Word; be prepared in season and out of season; correct,&nbsp;<br>
rebuke and encourage - with great patience and careful instruction.</i>" - 2Timothy 4:2</div></div></div>
<br><br><div class="gmail_quote">On Mon, Jul 22, 2013 at 9:47 AM, Michael B. Trausch <span dir="ltr">&lt;<a href="mailto:mbt@naunetcorp.com" target="_blank">mbt@naunetcorp.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div class="im">
    <div>On 07/21/2013 04:44 PM, Andy Borgmann
      wrote:<br>
    </div>
    <blockquote type="cite">Where do you see this being a PHP non-security. &nbsp;It
      sounds like it was an updated version of vBulletin's admin panel
      that had a security flaw. &nbsp;Even if vBulletin is coded in PHP, I
      don't see why blaming PHP as a whole is warranted in this case and
      not just vBulletin. &nbsp;PHP seems secure enough or Facebook.</blockquote>
    <br></div>
    Some points:<br>
    <ol>
      <li>Facebook does not run the official PHP, they run a subset of
        it that is then compiled, if memory serves, to C++ and then
        compiled to system code.</li>
      <li>PHP itself is insecure for <b>many</b> reasons, the least of
        which:</li>
      <ol>
        <li>PHP has never deprecated functionality that is known-unsafe,
          given the average experience of the PHP-only programmer; for
          example, SQL injection attacks are pandemic in PHP code not
          because it's any less safe than C, but because it is just as
          safe as C and PHP-only programmers don't have perspective from
          which to draw from to secure their own code.&nbsp; This flaw could
          be fixed in PHP by removing functions that permit it; in my
          book, that makes it a PHP flaw (it's easier to fix PHP than it
          would be to fix all PHP programmers).</li>
        <li>PHP has a large number of pseudoprogrammers that work with
          it.&nbsp; These people are mostly management types that found that
          they can quickly piece together a PHP script and make it do
          something useful.&nbsp; These people have no background in
          security, information technology, information systems or any
          similar such topic.&nbsp; They often C&amp;P pathologically, and
          the systems that they create are swiss cheese from a security
          perspective.&nbsp; Again, this is something that can be fixed in
          PHP, by ensuring that variables that come from the user are
          always represented in a canonical format and that outputs are
          properly escaped.</li>
        <li>PHP has a large number of what I call "auto-fsck-you"
          features built-in to it that most people do not understand.&nbsp;
          One such example is PHP's associative arrays, which are really
          integer arrays. The reason that integers and string keys can
          both be used in PHP in the same array is that they share the
          same namespace; a very large sequential array is quite likely
          to clash with the hashed namespace used for string keys.&nbsp; Fun,
          yes?&nbsp; And that's just one example.</li>
      </ol>
    </ol>
    <p>I could go on for pages, but there are many others who have done
      so at length; I won't reinvent the wheel here.&nbsp; I can say, though,
      that a quick review of US-CERT data shows that PHP and
      applications written in it are still among the most common of
      security problems—even in systems written by professional
      programmers.<span class="HOEnZb"><font color="#888888"><br>
    </font></span></p><span class="HOEnZb"><font color="#888888">
    <div>-- <br>
      <table border="0">
        <tbody>
          <tr>
            <td> <img src="cid:part1.08030604.02090804@naunetcorp.com" alt="Naunet Corporation Logo"> </td>
            <td> Michael B. Trausch<br>
              <br>
              President, <strong>Naunet Corporation</strong><br>
              ☎ <a href="tel:%28678%29%20287-0693%20x130" value="+16782870693" target="_blank">(678) 287-0693 x130</a> or <a href="tel:%28888%29%20494-5810%20x130" value="+18884945810" target="_blank">(888) 494-5810 x130</a><br>

              <br>
            </td>
          </tr>
        </tbody>
      </table>
    </div>
  </font></span></div>

<br>_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br></blockquote></div><br></div>
</blockquote><br><br><br><div id="M2Signature"><div>-- </div><div><div>Jay Lozier<br>jslozier@gmail.com</div><div><br></div></div></div></body></html>