<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 07/22/2013 10:15 AM, Andy Borgmann
wrote:<br>
</div>
<blockquote
cite="mid:CABGEp7oLurFZab_Afkk79VpZUOW0giUPT-WFZ86EHqyFvFeusw@mail.gmail.com"
type="cite">
<div>No need to get defensive. I am not "minding" you, and I am
sure you are a great programmer and have more experience than
me. My only point in this is that PHP is not inherently
insecure. Not saying it is better than C or Java or Python.
All I am saying is that the security flaws in PHP have more to
do with poorly written code that is publicly viewable to the
world than the system itself, and that the examples provided
thus far haven't convinced me that it is any less secure than I
originally knew other than less qualified people use it due to
the low barrier of entry.</div>
</blockquote>
<br>
On a technical level, you are correct.<br>
<br>
On a practical level, the only way to secure the web of PHP
applications that are out there that would have any chance at being
effective would be to remove PHP's automatic-screw-yous (e.g., the
array one is particularly bad if you've ever been bitten by it—and
you'll never, ever forget it if you do get bit by it, either) as
well as remove its bad ideas.<br>
<br>
For example, there should be a standard, inbuilt method for creating
secure SQL queries, and you should have to go out of your way to
bypass it. IOW, secure by default. There is, sort of, but the
defaults are still "whatever you want". C# fixed this problem in
its world by creating an extension to the language that maps
directly to database queries (and it actually was developed for
security sake, but it seems to create far better queries than most
humans do by default, so in that case, security caused a performance
benefit, too).<br>
<br>
<blockquote
cite="mid:CABGEp7oLurFZab_Afkk79VpZUOW0giUPT-WFZ86EHqyFvFeusw@mail.gmail.com"
type="cite">
<div>And I would very much be interested in what you know about
HipHop, because everything I have read about it and looked into
relates to performance, not security.</div>
</blockquote>
<br>
It's been three or four months since I spent any time looking at
it. I've come back to looking into it with every PHP project I have
done, including the current one. However, the base requirements for
the project I'm on, once they were decided, excluded HPHP for
technical reasons (the base cannot be compiled with it).<br>
<br>
Among the things that weren't supported the last time I checked it
out, and I <i>believe</i> are still unsupported (and these are the
overlapping ones—both technically difficult and insecure):<br>
<ul>
<li>eval—which shouldn't really ever be used anyway, as it allows
injection to occur upon the compromise of any system trusted to
inject via that method.</li>
<li>dynamic includes—With truly bad code, there is no way to avoid
them. Such code cannot ever be compiled by HPHP because the
very thing it depends on does not exist. (They do appear to
have a new mode that runs in a VM that might allow it, but
whether they enabled such functionality or not is not easily
discoverable and I'd have to check it out to test it.) Dynamic
includes are worse than most people realize because they almost
never realize just how easy it is to attack and trick a PHP
system into including things outside of the app's control.</li>
</ul>
Namespaces weren't implemented, either, the last time I checked, but
that was because they hadn't gotten around to adding support for PHP
5.3 yet. Those are a great security feature, too.<br>
<br>
— Mike<br>
<br>
<div class="moz-signature">-- <br>
<table border="0">
<tbody>
<tr>
<td> <img src="cid:part1.06010909.05070705@naunetcorp.com"
alt="Naunet Corporation Logo"> </td>
<td> Michael B. Trausch<br>
<br>
President, <strong>Naunet Corporation</strong><br>
☎ (678) 287-0693 x130 or (888) 494-5810 x130<br>
<br>
</td>
</tr>
</tbody>
</table>
</div>
</body>
</html>