On Mon, 2010-06-07 at 15:00 -0300, Igor Escobar wrote:
> PHP Injection is the technical name given to a security hole in PHP
> applications. When this gap there is a hacker can do with an external
> code that is interpreted as an inner code as if the code included was
> more a part of the script.
>
>
>
> // my code...
> // my code...
> include ('http://..../externalhackscript.txt');
> //my code...
> //my code..
>
>
> I know how to fix that too. The problem is: WHERE I HAVE TO FIX THAT.
>
>
> Got it?
>
>
>
>
>
> Regards,
> Igor Escobar
> Systems Analyst & Interface Designer
>
> + http://blog.igorescobar.com
> + http://www.igorescobar.com
> + @igorescobar (twitter)
>
>
>
>
>
>
> On Mon, Jun 7, 2010 at 2:48 PM, Ashley Sheridan
> <a...@ashleysheridan.co.uk> wrote:
>
>
> On Mon, 2010-06-07 at 14:42 -0300, Igor Escobar wrote:
>
> > It's not a SQL Injection or XSS problem, Michael.
> >
> > It's a PHP Injection problem. I know how fix that but the
> web site is very
> > very huge, have lots and lots of partners and i'm have a bug
> difficult do
> > identify the focus of the problem.
> >
> > Got it?
> >
> >
> > Regards,
> > Igor Escobar
> > Systems Analyst & Interface Designer
> >
> > + http://blog.igorescobar.com
> > + http://www.igorescobar.com
> > + @igorescobar (twitter)
> >
> >
> >
> >
> >
> > On Mon, Jun 7, 2010 at 2:38 PM, Michael Shadle
> <mike...@gmail.com> wrote:
> >
> > > It's not that bad.
> > >
> > > Use filter functions and sanity checks for input.
> > >
> > > Use htmlspecialchars() basically on output.
> > >
> > > That should take care of basically everything.
> > >
> > >
> > > On Jun 7, 2010, at 6:16 AM, Igor Escobar
> <titiolin...@gmail.com> wrote:
> > >
> > > This was my fear.
> > >>
> > >> Regards,
> > >> Igor Escobar
> > >> Systems Analyst & Interface Designer
> > >>
> > >> + http://blog.igorescobar.com
> > >> + http://www.igorescobar.com
> > >> + @igorescobar (twitter)
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Mon, Jun 7, 2010 at 10:05 AM, Peter Lind
> <peter.e.l...@gmail.com>
> > >> wrote:
> > >>
> > >> On 7 June 2010 14:54, Igor Escobar
> <titiolin...@gmail.com> wrote:
> > >>>
> > >>>> Hi Folks!
> > >>>>
> > >>>> The portal for which I work is suffering constant
> attacks that I feel
> > >>>>
> > >>> that
> > >>>
> > >>>> is PHP Injection. Somehow the hacker is getting to
> change the cache
> > >>>> files
> > >>>> that our system generates. Concatenating the HTML file
> with another that
> > >>>> have an iframe to a malicious JAR file. Do you have any
> suggestions to
> > >>>> prevent this action? The hacker has no access to our
> file system, he is
> > >>>> imputing the code through some security hole. The
> problem is that the
> > >>>>
> > >>> portal
> > >>>
> > >>>> is very big and has lots and lots partners hosted on
> our estructure
> > >>>> structure. We are failing to identify the focus of this
> attacks.
> > >>>>
> > >>>> Any ideas?
> > >>>>
> > >>>>
> > >>> Check all user input + upload: make sure that whatever
> comes from the
> > >>> user is validated. Then check all output: make sure that
> everythin
> > >>> output is escaped properly. Yes, it's an enormous task,
> but there's no
> > >>> way around it.
> > >>>
> > >>> Regards
> > >>> Peter
> > >>>
> > >>> --
> > >>> <hype>
> > >>> WWW: http://plphp.dk / http://plind.dk
> > >>> LinkedIn: http://www.linkedin.com/in/plind
> > >>> BeWelcome/Couchsurfing: Fake51
> > >>> Twitter: http://twitter.com/kafe15
> > >>> </hype>
> > >>>
> > >>>
> > > --
> > > PHP General Mailing List (http://www.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
>
>
>
>
> What do you mean it's a PHP injection? PHP is all on the
> server, and the
> only way to get at that if you don't have direct access to the
> server
> (which you've said isn't possible as the passwords, etc are
> all fine)
> then the bad data is coming from either a form or another area
> where
> user data is expected. This data might be as simple as
> unsanitised URL
> variables that are intended to fetch a blog entry, to form
> data sent in
> a registration page.
>
> All data coming from the user is bad until proven otherwise.
>
>
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
>
>
That data is still coming from somewhere, so is still badly sanitised
data either coming from a form or a URL. You really should go over all
the code to find these and root them out, which is a mammoth task. To
narrow it down, those access logs I mentioned before will help. I think
there are ways you can automatically detect security holes in your
software, but if none of your user data is sanitised correctly, then
virtually everything is a potential security hole.
Thanks,
Ash
http://www.ashleysheridan.co.uk
