How you should never configure your logging in PHPWednesday, December 7. 2005Wednesday, December 7. 2005 Today I had the pleasure to look at code examples from a recently released book. I guess readers of my blog know exactly what book I am referring to.
This example seems to explain how a script should configure it's logging in a secure way. I cannot say what the book says about this example, because I don't feel like wasting my money on it. Maybe the guys who say they have reviewed it can comment on it.
Comments
Display comments as
(Linear | Threaded)
I presume the library in question is here: http://phpsec.org/library/
posted on Wednesday, December 7. 2005
He might have apache chrooted which would put the permissions and logs of the apache within that persons chroot so it is slightly possible this might work.
The simple fact of the matter though, a lot of hosts give there customers access to the log files both so they can run there own tracking programs on the logs and also so they can self manage them if they get to large and are taking up to much of there quota space. So its possible it would work, but would it work in most default enviroments, no. posted on Wednesday, December 7. 2005
#2.1
Stefan Esser
()
Just because it may work on some hosters configuration does not change the fact that it is still a bad idea (from a security point of view) to leave logfiles writeable for the user executing PHP scripts. Anyone that breaks in through a hole in a PHP script will surely love that he is allowed to erase all traces of his actions from the log file.
posted on Wednesday, December 7. 2005
Said author might be more receptive to things like this if you presented it in a less hostile manner.
Phrases like "wasting my money on it", "funny enough for now", and the comment about the library almost make one not want to bother with the rest of this post. It's one thing to point out security issues with a script. It's a complete other thing to allow your personal grudgles to seep into it, making it a more than slightly uncomfortable read for those "in the know" and completely confusing those that aren't. posted on Wednesday, December 7. 2005
#3.1
Stefan Esser
()
If you do not like my postings then you are free to not read them.
If you do not think it is amusing that a book about PHP Security, that claims to be from the #1, gives such basic examples that don't work or only when the webserver is configured in an insecure way, then you should not read my blog. And do you wanna bet how fast we get removed from the library (again)? posted on Wednesday, December 7. 2005
I think enygma tried to say that some people read this because you have valuable things to say php security-wise that may not get written elsewhere.
That said, I don't care if you develop into the rude pundit of php. Write what you like, I'll read it as long as you have a valid reason for writing it. If and when it seems pointless to me, I'll stop reading. When you and a certain author had a comment slap-fest a few months ago, I stopped reading the comments because they seemed childish and completely useless. Nobody forced me to sit at the page and hit refresh until the conversation stopped. posted on Wednesday, December 7. 2005
So what enygma - you read this blog religiously just so you can stick up for you buddy Chris?
The post is legitimate. Number one, Chris Shiflett should at least test his example code before publishing it. That's pretty standard. And Stefan is right - it does betray a very shallow understanding. Number two, Chris Shiflett has been plenty nasty in the past rallying up his PHP lecture circle buddies in order to keep up the illusion he's some top PHP security expert while in fact he has about as much understanding of PHP security issues as anyone who's developed using PHP for more than a couple of years. When it comes down to it who would you rather trust or use auditing services from - SE who has developed Hardened-PHP or Shiflett who's written an O'Reilly light-weight book. posted on Thursday, December 8. 2005
It could be that their examples were tested on a Windows Box. Still, that's no excuse for not testing it on a *nix box too...
posted on Wednesday, December 7. 2005
Hi Stefan,
The path to the error log is arbitrary. The examples have been changed to /path/to/error_log to make this clearer (with or without context). If you happen to find errata, please report it rather than blog about it. You should know better. These examples work for me, because I'm testing within the Apache-Test framework. posted on Wednesday, December 7. 2005
sure it's not fine in image and business point of view if someone exposes mistakes in the public. but this is security point of view which should always be exposed to the public, because the public have to be aware about it.
generally everyone should clearly expose his own mistakes to the public who writes about security (and make mistakes too i don't know if someone (or you chris) do so, if yes, forget about my comment. posted on Thursday, December 8. 2005
LOL.....pretty soon the number of pages for errata will be as long as the book itself. So, should we consider the errata the 2nd Edition?
posted on Thursday, December 8. 2005
Script "Edit Session Data (inject.php)" in Chapter 8 doesn't check POST data and let anyone overwrite your files.
If you don't overwrite $_FILES yourself, it's not necessary to check is_uploaded_file($_FILES['attachment']['tmp_name']) as in examples from Chapter 2. Filenames in this array couldn't be injected. posted on Thursday, December 8. 2005
I believe the code snippet in the blog post was taken out of context. In the provided code on the book's website, it has an example path. I think you're assuming that it *has* to be to the server's apache log, which isn't the case. I think the point of this code snippet was to isolate your php errors, versus attempt to over-write the apache error_log.
On some of the servers that I maintain, we have numerous java apps, as well as php apps running. It's *very* handy to have the php errors piped to a different log, rather than thrown in the mix with all the other errors. I don't consider it a security issue, more of an issue of handiness. Had the code above been verbatim copied, it would've made more sense to your blog readers, instead, I saw the error more in your interpretation of Chris's approach. Ha posted on Thursday, December 8. 2005
#7.1
Stefan Esser
()
Mr. Keith an example in a security book for beginners should work and not only work when an unsafe server configuration is used.
You obviously did not understand the whole point of this blog posting. It has nothing todo with overwriting log files. It had todo with the fact, that the example path given is the default apache logfile path and that the examples therefore can only work in a very unsafe server configuration (apache running as root or the apache logfile writable for anyone else than root). BTW: If you have servers where the 2nd example works I suggest that you get yourself a new admin. posted on Thursday, December 8. 2005
I must've looked at the site after the fix had been placed. When I viewed it I didn't see any reference to the apache dir, so I didn't see anything wrong with the example path that was given. It appears that your comments were put in place, which caused my confusion.
posted on Thursday, December 8. 2005
#7.1.1.1
Stefan Esser
()
Ahh I see. The code examples on the book's website were changed. Now they are only wrong in the book...
posted on Thursday, December 8. 2005
#8
Stefan Esser
()
Reminder to myself... Get a new skin for the blog, that survives deep comments.
posted on Thursday, December 8. 2005
Add Comment
|
Calendar
Archives Categories Syndicate This Blog |
|||||||||||||||||||||||||||||||||||||||||||||||||


