[binarycloud-general] Re: [binarycloud-dev] php security primer

[Alex B. <en...@tu...>]

http://www.securereality.com.au/studyinscarlet.txt

And... here we go :)

3. Global Variables
---------------------
"The problem is that the code incorrectly assumes that the variable $auth
will be empty unless it sets it. Remembering that an attacker can create
variables in the global namespace, a url like
'http://server/test.php?auth=1' will fail the password
check but the script will still believe the attacker has successfully
authenticated."

First: under no circumstances should you assume that a variable is set to
"what you expect". Second, and more importantly, this is the reason there's
a request class in r2: for explicitly requesting values from the "user
space" instead of having register_globals on in php.ini and opening up your
application to attack.

register_globals is convenient, but it is dangerous, as this article points
out.

4. Remote Files
---------------------
This is actually not different from "Global Variables" above, and obviously
you should never take entire paths from the user for inclusion. You should
also, (of course) make sure that your webserver is running as a user in a
group by itself, and ensure that permissions in your fs are properly set.
Best is to chroot apache.

5. File Upload
---------------------
Uh, notice a trend here?
turn _off_ register_globals, and all is well :)

6. Library Files
---------------------
Heh, don't include your library files in htdocs where thy can be served?!
(duh!?! :)

7. Session Files
---------------------
Again, global variables.

8. Loose Typing And Associative Arrays
---------------------
I agree with this, though I don't think (including the above) that it poses
a security risk. This is an extremely simple expression of the idea that an
application needs "central" validation logic which is used everywhere.. the
complex version is... entities!

9. Target Functions
---------------------
I don't think there is a good place for eval() in a well written
application. It is of course a security risk, unless you're _really_ sure of
the content of the string you are evaling.

In general, executing apps "on the command line" though php is a no-no, and
a security risk. Of course if you're careful about how you do it, and you do
really need to do it, it's fine.


10. Protecting PHP
---------------------
heheh:
* = Mostly painless
** = Vaguely painful
*** = Seriously hurts
**** = Chinese Water Torture

**** - Set register_globals off
(thus, the request class :)

*** - Set safe_mode on
(ick, this is a pain in the ass)

** - Set display_errors off, log_errors on
(Agreed, this is a part of the error handling infrastructure in bc)


11. Responsibility - Language Vs Programmer
---------------------
"I contend that it is very hard to write a secure PHP application (in the
default configuration of PHP), even if you try."

Bullshit. You do have to think about what you are doing, but really, in most
cases all you have to do is use a little common sense.

Don't use global variables to set include paths, don't blindly use values
from globals, etc etc.

All of this stuff has to do with globals! If you solve the globals problem,
everything else is no big deal. ASP's 'Request' class (*cough*, yes I know
MS n' all) - is the right idea.

"Web designers and other non coders end up writing PHP applications."
I'm part web designer, but I get the point. Of course this is sort of like
saying stupid people don't drive well and it's the car's fault :)

"In its search for the ultimate functionality PHP has undermined the
programmer's ability to understand the workings of their code in all
situations."

Again, bullshit. I think proper namespaces would be nice, but php code (even
if it's spaghetti) is almost _always_ easy to read. Anyone ever try
debugging complex perl? Give me a razor! :)

---------

With three commands I can turn an apache install into a blaring invitation
to hack. I do agree that registering globals is bad. At the same time,
that's what the config is there for.

_a


> Hello All:
> I think the article link below is useful... depending on your php
> experience/knowledge
> it may/not be...
> But what I want to know since I haven't thoroughly perused BC's yet
> morphing codebase... How does BC cope with such potential security attacks?
> -WD
> 
> <-- snip -->
> With the recent code red activity it has gotten me thinking about any
> vulnerabilities within phpwebsite.  I ran across this article
> <http://www.securereality.com.au/studyinscarlet.txt> that details some
> common problems with php based scripts.  It makes for some really good
> reading.  There is some good supporting material that breaks down specific
> scripts.  How much has the development team looked into fixed security
> holes?
> 
> Thanks,
> Eric
> <-- snip -->
> 
> __________________________________________________
> FREE voicemail, email, and fax...all in one place.
> Sign Up Now! http://www.onebox.com
> 
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 


--
alex black, ceo
en...@tu...

the turing studio, inc.
http://www.turingstudio.com

vox+510.666.0074
fax+510.666.0093