I'm totally agree with you Ash, I came up here to ask you guys some for light. Anything to well me to track that M%$#% F#$CK#$# and discover from where he's attacking. Regards, Igor Escobar Systems Analyst & Interface Designer + http://blog.igorescobar.com + http://www.igorescobar.com + @igorescobar (twitter) On Mon, Jun 7, 2010 at 3:06 PM, Ashley Sheridan <ash@xxxxxxxxxxxxxxxxxxxx>wrote: > 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 <ash@xxxxxxxxxxxxxxxxxxxx> > 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 <mike503@xxxxxxxxx> > 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 <titiolinkin@xxxxxxxxx> > 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.lind@xxxxxxxxx> > > >> wrote: > > >> > > >> On 7 June 2010 14:54, Igor Escobar <titiolinkin@xxxxxxxxx> 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 > > >
