PHP 7 deployment at Dailymotion
Hack and HHVM solves what is, IMO, the worst feature of the default PHP runtime environment[0] - and that is the superglobals.<p>It wasn&#x27;t mentioned in the post from Slack, but default superglobals and the earlier register_globals design decisions are the worst and most impactful wart in PHP.<p>Because it was designed as a templating language, the default web server interface, which is CGI - will auto-expose all variables in global scope, ex.<p><pre><code>    echo $_POST[&#x27;user_id&#x27;]
</code></pre>
PHP has a horrible reputation with security for this reason - we all know that somehow, somewhere, in almost every project someone is pulling in a user-controlled variable from a superglobal and they aren&#x27;t escaping or checking it properly (since you can&#x27;t be warned about it but the feature will work).<p>Worse - and i&#x27;ve seen this <i>a lot</i>, even with Laravel, CodeIgniter, Cake, Symfony&#x2F;Silex etc. you end up with these well structured projects that declare request classes, methods and variables etc. etc. but then sometime down the road a developer takes a shortcut in a method and pulls in a $_GET or $_POST inside a controller (usually because they don&#x27;t know how, or aren&#x27;t bothered to - changing all the related classes) - running around the default exec stack.<p>I&#x27;ve seen this so often - because it&#x27;s so easy to do it. The most common place is where a designer has built a frontend AJAX form. They now need to build a quick backend check, so they Google &quot;php backend ajax username check&quot; and they&#x27;ll likely get a result like this one:<p><a href="http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;29459183&#x2F;check-username-availability-using-ajax" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;29459183&#x2F;check-username-a...</a><p>where the 4th and 5th lines to the solution are:<p><pre><code>    $username=$_POST[&#x27;username&#x27;];
    $query=&quot;SELECT * FROM username_list WHERE     username=&#x27;$username&#x27; &quot;;
</code></pre>
they copy that into a file called ajax_username_check.php and save it to the server - and they&#x27;ve now destroyed all that previous good work by opening up a very blatant and easy to find SQLi vulnerability. Their database will be on pastebin within a month.<p>You can spot this type of vulnerability from the frontend because the URLs used in the AJAX calls don&#x27;t match the URL router patterns for the rest of the app (ex. GET &#x2F;user&#x2F;username_check_ajax.php vs &#x2F;user&#x2F;check_user).<p>In other languages you can&#x27;t get that without using a standard library that will escape the values by default. Any solution you search for will always be a safe method to obtain the variable values by default.<p>Some good news: Hack doesn&#x27;t expose superglobals in strict mode:<p><a href="http:&#x2F;&#x2F;cookbook.hacklang.org&#x2F;recipes&#x2F;get-and-post&#x2F;" rel="nofollow">http:&#x2F;&#x2F;cookbook.hacklang.org&#x2F;recipes&#x2F;get-and-post&#x2F;</a><p>I&#x27;d <i>strongly</i> recommend that this is used in all PHP projects, since it strictly enforces variable access - even in cases where you&#x27;re using a framework that is supposed to enforce it.<p>IMO PHP missed a big opportunity with not removing superglobals in version 7 and enforcing an explicit safe request object much like other languages do. They likely wanted to avoid it because of the cluster of register_globals and magic_quotes from earlier versions.<p>[0] I think it is important to distinguish PHP the language and PHP the runtime. PHP the language is now decent - having caught up with a lot of features (although I find it very verbose and harder to read) while PHP the runtime is undoubtably still a horrible runtime - hence HHVM