php security books

Hi Andrew,

Wednesday, July 4, 2007, 8:29:51 PM, you wrote:

> I have no doubt he is a great bloke and a great public speaker / PR
> for PHP application level security, I apologise if it sounded like
> FUDing (why does that sound dirty?). I just don't like / agree with
> his book or some of the security articles he wrote (again, I haven't
> read them in quite a while). I think Ilia's book is a lot better.

Fair enough. This wasn't actually obvious from your one
sentence personally directed comment my reply was based upon.

I actually agree with you about Ilia's book, it is the best of the
three available (the Pro PHP Security one is certainly the worst),
although there are areas where even Ilia basically shrugs his
shoulders in the text and says "you can never have it 100%" and sort
of gives up on you :)

All three books are now well behind the times though imho.

> I also agree that awareness is no bad thing, but people should also
> be aware he is not the be all and end all of PHP application level
> security, and he has made mistakes (as have I and probably everyone
> else here at some point).

Sure, no-one is perfect :) I remember asking him years ago why he
wanted to concentrate on PHP Security explicitly, and his response was
simply that he wished he didn't have to, but no-one else was, and
ultimately in his ideal world PHP would be secure enough 'out of the
box' that he need not have to focus at all.

Cheers,

Rich
--
Zend Certified Engineer
http://www.corephp.co.uk

"Never trust a computer you can't throw out of a window"

On Jul 4, 2007, at 3:22 AM, Ross wrote:

>
>
> http://amazon.co.uk/s/ref=nb_ss_w_h_...71317-2810350?
> initialSearch=1&url=search-alias%3Daps&field-
> keywords=php+security&Go.x=0&Go.y=0&Go=Go
>
>
> looking at the top 3 on the list here, personally I quite like the
> O'Reilly
> books. Can someone recommend one of these or any other that will give
> me a
> good solid understanding of PHP security?
>
>
> Thanks,
>
>
> Ross
>
Have you seen Pro Php Security by Snyder and Southwell; Apress ?
It appears to be as comprehensive and well written as the subject
can get.
JK

Andrew Hutchings wrote:
> In article <468BE67E.5050504@iamjochem.com>
> jochem@iamjochem.com(Jochem Maas) wrote:
>
>> > OK, well, for example page 3 of the book suggests making
>> PHP output > errors into Apache's error_log. To do this on Linux
>> it means PHP> would have to be run as root.
>>
>> huh? funny thing is that on all the machines I work with Apache
>> runs under it own user (apart from at start up when it briefly urns
>> as root before switching), I run php as an Apache module (I'm
>> assuming we're not talking about php cli given that we're mentioning
>> Apache), this means php is running in the context of the apache
>> user.... and btw is quite capable of logging to the Apache error_log
>
> Exactly, the initial process runs as root, and this is the process
> that does the logging, it would be another security issue to have your
> logs set as apache's owner. PHP is run as apache's user (unless you
> use something suPHP) so if you use PHP's error handler function (not
> the thing that sends data to the error logs) to write to apache's logs
> they would either have to be owned by apache or php would have to run
> as root.

ok - I didn't realise the logging occurs under a root user process,
I checked and can confirm that you are correct in that respect.

I would assume though that Chris was referring to the use of error_log()
which would mean php doesn't need any direct access to the log file - the
'log error' request is handed off to apache (which I'll assume securely
manages to hand the request off to the root process that performs the
actual write). therefore using error_log(), at least, doesn't pose a
direct threat (a flaw may exist at the apache level but that is not
something php can do much about - and as such any apache module would
suffer from the same problem).

If Chris did mean that one could/should write to apache's error_log()
manually (i.e. not via error_log()) then I think that would constitute
an incorrect advisement - giving read/write access to a webprocess for
a file that should be accessible only by root doesn't seem right :-).

Maybe Chris picks this thread up and offers some clarity on the matter,
I'm sure he'd be the first to admit a mistake and take on board new/improved
procedures.

To give him credit it's probably quite tough to be one of only a very few
'php security' guys ... everything he says is taken apart with
a fine toothcomb and being a kind of 'frontman' he takes all the flack,
such is life.

> You are entitled to your opinions, and I am entitled to mine. If you

ai.

> believe I am spreading FUD, so be it.

okay, FUD might have been too strong a word - it puts you in the same league as
Steve Ballmer and that probably not fair at all :-)

> But that example _is_ a
> security flaw.

<tangent>
the greatest flaw regarding security is to assume that it exists at all
.... those understand this won't need to comment, those that don't please
forget I said anything. :-)
</tangent>

At 11:23 AM -0400 7/4/07, Andrew Hutchings wrote:
>In article <200707041544.30740.php@wastedtimes.net>
>php@wastedtimes.net(Mark Kelly) wrote:
>
>> Hi.
>>
>> On Wednesday 04 July 2007 13:01, Andrew Hutchings wrote:
>>
>>> Avoid the O'Reilly one as it is flawed.
>
>> In what way?
>
>Its written by Chris Shiflett, isn't that enough reason?


As will post written by you will be sufficient reason for my kill file.

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

Andrew Hutchings wrote:
> Avoid the O'Reilly one as it is flawed.

Hollow claims are disrespectful and harmful to professional discourse.
Perhaps you are motivated to persuade others that this is true and will
do so at any cost, even if it means spreading misinformation. I'm aware
of one person who does exactly this, so maybe you're just a victim of
his propaganda. I'll give you the benefit of the doubt and assume the
latter.

The entire errata is published online and has been maintained very
diligently:

http://phpsecurity.org/errata

I would argue that none of these errors constitute poor security advice,
whereas I can't say the same for the other books I've read on the
subject. (I don't want to disparage anyone's hard work, and feel free to
discount my opinion as biased.) The errata is there for you to form your
own opinion, and if you actually do know about something that isn't
listed, then please disclose it. "Put up, or shut up."

There's nothing worse than poor security advice, but the fear of being
wrong can't prevent us from sharing what we've learned. I have nothing
but contempt for those who, for their own personal benefit, want to
silence and discredit the people who are trying to help. The PHP
community is one of the most open, friendly, and helpful communities
around, and I think we are also one of the most security-conscious as a
result.

If you'll look through the reviews, you might notice that many leading
PHP and web application security experts highly recommend it:

http://phpsecurity.org/reviews

Are all of these people fools, or is it really a good book?

Chris

--
Chris Shiflett
http://shiflett.org/

Andrew Hutchings wrote:
> I prefer prepared statements and would use them all the time if
> it wasn't for the fact that those queries aren't cached until
> recent versions of MySQL 5.1

Use PDO. It emulates prepared statements and doesn't avoid the query cache:

$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, TRUE);

For more information:

http://netevil.org/blog/2006/apr/using-pdo-mysql

Hope that helps.

Chris

--
Chris Shiflett
http://shiflett.org/