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
