[WEB SECURITY] AT&T exposes /etc/passwd , bad php

Andrew van der Stock vanderaj at owasp.org
Thu Jul 30 06:57:43 EDT 2009 

@Arian, thanks for the props!

@All, PHP can be written securely, but it's much harder than for other  
languages / frameworks.

Considering that most PHP coders are what I consider entry level /  
hobby programmers who haven't had formal security training, it's  
amazing there are any safe PHP apps.

PHP has 5900 functions as of a few moments ago. Despite this, there  
are no functions for:

* Authentication. PHP has optional modules for Kerberos, Radius and  
LDAP... but there's no authentication principal behind these modules.  
It's up to you to write that bit. So everyone does.

* Access Control. There's no MAC or RBAC for coarse, medium or fine  
grained data, function or resource control. So apps have to write  
these for themselves. Few get this right.

* Canonicalization is very limited. Beyond htmldecode() and  
urldecode() and a few others - but you need to figure out what the  
input is so you can use the right decoder. Hopefully, ESAPI for PHP  
will fix this.

* Input validation. PHP is quite a capable string manipulation  
language, with several different regular expression helpers (PCRE,  
etc), but it has no functions to force the super globals to be  
validated prior to first use. Some frameworks do this for you, but you  
can still trip over yourself if you access the super globals directly.

So if you do these things in a web app, you're writing your own, or  
using a framework and customizing them. So there are so many millions  
of AuthC and AuthZ systems out there, and I bet there are few that  
work properly.

PHP has rudimentary:

* Session management. It's often misconfigured or outright not  
configured, and it's hard for apps in a shared hosting environment to  
use these as you can't guarantee your app will work after calling  
session_start(). So most apps that rely on PHP's native session  
handler override the inbuilt session handlers. It's not surprising  
then that few apps use sessions if they don't need to - so many apps  
have hidden fields and dodgy cookies. There's no standard mechanism to  
avoid CSRF attacks, so each app is left to its own devices. Session  
fixation is trivial - it will happily accept the session identifier 'a'.

* Output encoding. By default, all output mechanisms have zero output  
encoding, even though this is the exception and not the rule. So echo,  
print and so on all output raw HTML, even though that has always  
bitten apps. htmlencode() does the big 5 and that's it. urlencode()  
does what it says. These two are not Unicode aware. JSON encode until  
5.3.0 does not encode dodgy characters, and only if you then include  
an additional parameter asking for that to occur. Both versions cannot  
encode Unicode strings (they produce null in the output, so it's at  
least "safe"). You get the picture. There's no encoders for many  
common output formats.

* SQL encoding is hilarious (addslashes() - not safe for Unicode apps,  
mysql_escape_string() - still not safe, and then my favorite  
mysql_real_escape_string() which is really, honest - really somewhat  
safe, albeit is an order of a magnitude slower than the first  
function. And yet, there's no inbuilt support for prepared statements  
that can talk to a database without recompiling. PDO is there, but if  
you want it to do prepared statements for the most common database,  
welcome to gcc and autoconf as you recompile PHP from scratch to get  
MySQL, Oracle, DB2 or PG support. So apps don't use PDO as they can't  
guarantee it being there.

* Logging. This is simply not configured on most hosts, and writing to  
a log you can't see (/var/log/messages) is not acceptable

* OO. Most code written for PHP is scripting and procedural. You can  
do OO for your own code (ESAPI for PHP does this), but because there  
are a tiny (and I mean minute) fraction of those 5900 standard  
functions throw exceptions. Even MySQLi OO gives error codes rather  
than throwing exceptions. There's no finally in PHP as of today. I  
hope PHP 6.0 has it. Another gripe - don't try to search for "try" or  
"catch" or "exception" in the documentation search. It fails to  
produce any results. You have to search the "entire" site to find  
information about OO.

* Crypto. Mhash and Mcrypt are rarely available on hosted  
environments, so AES (!) and SHA-256 (!) are not available on PHP  
5.3.0. This is unacceptable. So apps don't use them as they can't  
depend on them being there.

* Internationalization. Out of the box, PHP has no mb_string compiled  
in. So if your ISP / hoster hasn't recompiled, you can't do basic  
I18N. So every app bodges it.


PHP has surprises:

* Most functions return false for failure, some return -1, some return  
null, some return 0, some have a function to tell you what went wrong  
(json_last_error()) but rarely do they throw exceptions (SPL is about  
the only thing that can/does). But if you're not checking for false,  
or 0 is a valid but not failed situation, you need to KNOW that you  
need to use the type equality checker:

if ( $condition === false )

rather than

if ( $condition )

You'd be surprised how often that is a defect in apps.

* Until recently, PHP had register_globals on. This makes apps that  
are otherwise secure but fail to initialize variables subject to XSS.  
Once a script starts, you can't easily unregister the registered  
globals. Apps that rely on register globals routinely emulate this  
feature... Badly. See EXTR_SKIP for more details.

* Until recently, PHP used to automagically insert slashes in input  
just in case you happened to use MySQL (http://php.net/magic_quotes).  
This is now off by default, thankfully. But apps often have a few  
lines of code to put it back, and then don't do it properly (EXTR_SKIP  
instead of EXTR_OVR) and leave themselves open to trivial SQL  
injection if they don't emulate it or they were counting on it.

* By default, PHP has filters, such as the zlib handler which allows  
you to read compressed data from pretty much anywhere. It gets around  
safe mode, which itself is a joke.

* By default, PHP has allow_url_fopen on. This allows remote include  
attacks if you do things like include content from afar in any of the  
10's of functions that open files.

* Until recently, PHP had allow_url_include on. This allowed RFI  
attacks if you wrote code that was bad.

Don't get me wrong, PHP is my favorite language. But it's woefully  
insecure. It's far too hard to do the basics, and not everyone will  
want to pull in a framework like Zend Framework or ESAPI for PHP to  
cover these issues.

I'd love to work with the PHP core team to get basic and extensible  
security into PHP 6.0. I'd be even happier if that was based upon  
ESAPI for PHP as I think it's a great place to start. That way, all  
PHP apps can start from a relatively secure base.

thanks,
Andrew


On 28/07/2009, at 12:55 PM, Arian J. Evans wrote:

> You are a man (?) after my own heart re: Ultraedit & macros auditing  
> of source.
>
> There has been a significant amount of work done over @OWASP regarding
> secure coding in PHP. Cue Andrew Van Der Stott.
>
> I agree that PHP by default makes it easy to shoot yourself in the  
> foot.
>
> C# and the .NET framework probably make it the hardest to shoot
> yourself in the foot. Java is a little better, but you have to reach
> out for 3rd party frameworks and APIs like ESAPI to make doing a good
> job easy(ier). I rarely ever see directory traversals in C#/.NET and
> Java apps, thought I found a major one in .NET (due to
> canonicalization and mis-ordered authorization) back in 200/2 or /3.
> Haven't seen one like that in the six years since.
>
> This said: I have seen a few folks do a decent job coding securely in
> PHP. See above.
>
> Ultimately I think choice of language and framework is a business
> decision, and I try not to tell people what they should have coded
> things in. I don't find this very productive (unless they ask, from
> the start). There are sound business reasons someone might choose
> PHP/LAMP.
>
> So now we are way off topic,
>
> -- 
> Arian Evans
>
>
>
>
>
> On Mon, Jul 27, 2009 at 6:43 PM, Matt  
> Parsons<mparsons1980 at gmail.com> wrote:
>> Dee,
>>        I agree insecure code is insecure code.  If you don't  
>> validate input
>> it can be bad and therefore insecure in any language.  That is  
>> secure coding
>> 101.
>>        I have completed source code reviews in Java and .NET and  
>> there are
>> many more resources available to write secure code in these  
>> languages.   PHP
>> being a scripting language is more insecure.  In my career, I have  
>> scanned,
>> using an unmentioned vendor neutral, static code analysis vendor for
>> thousands of LOC in PHP.  I have also completed hand audits of PHP  
>> code
>> using ultraedit.  Just the functionality of echo introduces a whole  
>> new
>> realm of XSS vulnerabilities never mind the one with the directory  
>> traversal
>> attack at AT&T.
>>        I think PHP security is new practice and standards need to  
>> be put in
>> place to write PHP securely.  Does anyone disagree with me?  Does  
>> anyone
>> have experience writing PHP securely and doing source code reviews  
>> in PHP?
>>
>> Thanks,
>> Matt
>>
>>
>>
>> Matt Parsons, CISSP
>> 315-559-3588 Blackberry
>> 817-238-3325 Home office
>> mparsons1980 at gmail.com
>> www.parsonsisconsulting.com
>>
>>
>>
>>
>> -----Original Message-----
>> From: Dee [mailto:damien.watson at gmail.com]
>> Sent: Monday, July 27, 2009 8:21 PM
>> To: websecurity at webappsec.org
>> Subject: Re: [WEB SECURITY] AT&T exposes /etc/passwd , bad php
>>
>> 2009/7/28 Matt Parsons <mparsons1980 at gmail.com>:
>>> Personally, I would have written the application
>>> in a language that is a bit more secure like .NET or Java.
>>
>> And you can still fail to validate data at the relevant boundary in
>> .NET and Java.
>>
>> ----------------------------------------------------------------------------
>> Join us on IRC: irc.freenode.net #webappsec
>>
>> Have a question? Search The Web Security Mailing List Archives:
>> http://www.webappsec.org/lists/websecurity/archive/
>>
>> Subscribe via RSS:
>> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>>
>> Join WASC on LinkedIn
>> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>>
>>
>> ----------------------------------------------------------------------------
>> Join us on IRC: irc.freenode.net #webappsec
>>
>> Have a question? Search The Web Security Mailing List Archives:
>> http://www.webappsec.org/lists/websecurity/archive/
>>
>> Subscribe via RSS:
>> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>>
>> Join WASC on LinkedIn
>> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>>
>>
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>


----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA

More information about the websecurity mailing list