[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fixing stupid PHP application design flaws



Jeroen van Wolffelaar wrote:
> > What do people on this list think about fixing PHP include files in a
> > DSA that are accessible via HTTP as well and contain one bug or
> > another as they are not supposed to be accessible via HTTP but
> > accidently are.
> > 
> > I'm rather annoyed by the lack of comptence of some PHP coders who
> > manage their project in a way so that include files are stored within
> > the regular DocumentRoot and are hencely accessible via HTTP as well.
> > Include files normally also don't contain any precaution about being
> > "executed" standalone.
> > 
> > These files should not be accessible via HTTP in the first place but
> > put into /usr/share/something instead and included from there.
> 
> I don't think that those include files are per definition a problem -- a
> well-managed project will only ship 'stock' include files only
> containing functions, whether the user gets to see the source of it, or
> it's being executed, it doesn't hurt.

I agree, as long as they are silent, they don't pose a problem per se.

> Of course, it's different if this is not the case (non-function stuff in
> include files). I'd myself be inclined to advice to only fix those

non-function and non-class.

> cases where there might be a potential problem. A lot of PHP web
> applications are designed by upstream to be simply untarreable in the
> place where the URL is supposed to be, and as such have include files
> necessarily http-accessible. It's sometimes hard for packagers to fix
> this, and when the include fiels cannot do harm, I don't see why.

Clean design.  Less tempting for stupid "coders".  Just to name two.

> It'd be wise for those projects to take the extra precaution by allowing
> (and the Debian maintainer to do so) include files outside the web root,
> but to DSA for such a thing when there might not even be a vulnerability
> at all, seems premature to me. It'd be like fixing all uses of sprintf
> because the programmer could have used snprintf to be more sure there is
> no problem.

Sure, that was never my intention either.

Regards,

	Joey

-- 
Never trust an operating system you don't have source for!

Please always Cc to me when replying to me on the lists.



Reply to: