|
|
Posted by Jason Morehouse on 06/10/51 11:05
Richard Lynch wrote:
> Ahhhh! Now we see the question! Why doesn't it yield 403 like it "should"
>
> First and foremost, use php.ini or httpd.conf or .htaccess to *NOT* let
> PHP send error messages OF ANY KIND to the browser on a production site.
>
> [You could also use ini_set within a script if the file in question is to
> be include'd into other files.]
>
> You should do this anyway.
>
> Admittedly, your server still behaves not quite like you want, as *.html
> yields a 403 response, and *.php yields a 200 response, and a page of no
> content. But at least the Bad Guys don't see your server internals.
>
> I don't think there's any way you can configure Apache to pre-empt the PHP
> trying to read the file -- though I presume Apache *could* be altered to
> behave that way... Except it would be rather difficult for Apache to
> 'know' a priori what User PHP runs as, given suexec, CGI setups, etc...
>
> Depending on your application, you might be able to "wrap" all the access
> to files through a known good PHP file, and then use PHP error handling
> (http://php.net/set_error_handler) to determine if this error occurred,
> and then send a 403 header.
>
> Probably an Apache list would be better suited to knowing for sure any way
> around this... You could maybe tweak the PHP source to detect this
> condition and send 403 instead of trying to include() the file, which is
> what it seems to be doing.
>
Yeah, thanks all. I usually have error logging off, but enabled it from
time to time when hunting down bugs (and forget to add it back).
Anyway, I guess I'll have to deal with just blank pages coming up in the
event of a .php 403... not a big deal really, I just prefer constancy.
I still don't really get why apache hands parsing off to php when it
knows it doesn't have read access to the file, but I'll save that for
another list!
Thanks again.
-J
--
Jason Morehouse
Vendorama - Create your own online store
http://www.vendorama.com
Navigation:
[Reply to this message]
|