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
>
>
>
