Security Issue
in [General]
|
Prev: DOMDocument::loadXML() failed when parsing comments inside a script tag
Next: combo box validation
From: Michael Shadle on 7 Jun 2010 13:53 You could do generic things to modify the $_GET and other superglobal arrays. For example if you wanted to implement magic quote yourself have a recursive function (I'd paste one but I'm on my phone) but something akin to this: $_GET = your_function_name($_GET); An idea for you might be to look for / or .. and reject or sanitize that in some fashion. Really hard to speak on what would safely work across the website globally (you could also just modify those specific array indexes of $_GET that have filenames or something the cache uses) Hope that makes sense. iPhones aren't the easiest to explain (or bottom post) On Jun 7, 2010, at 10:42 AM, Igor Escobar <titiolinkin(a)gmail.com> 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 > >
From: Michael Shadle on 7 Jun 2010 13:59 Because that only typecasts it. It's safe but it isn't what the user actually entered. This way I can actually determine if the user put in "123abc" and reject it, not accept it and keep the "123" silently for example. Same with floats. You may or may not consider a negative number acceptable, or with ints and floats 0 might not be acceptable too. So it's some analysis before intval/floatval/etc. I want to return to the user with a rejection notice so they literally get what they gave me (assuming it passes the sanity check) - it's not just simple silently typecasting and giving them something they didn't give me. And I meant to say "garbage in, garbage out*" * properly encoded or sanitized of course :) On Jun 7, 2010, at 10:51 AM, Ashley Sheridan <ash(a)ashleysheridan.co.uk> wrote: > > Why waste time validating an integer value when intval() will do > that for you? > > Thanks, > Ash > http://www.ashleysheridan.co.uk
From: Michael Shadle on 7 Jun 2010 14:00 I disagree and this kind of approach could be appropriate if you walk your input globals and apply some sanity checks and appropriate filtering you could fix the issue. On Jun 7, 2010, at 10:52 AM, Igor Escobar <titiolinkin(a)gmail.com> wrote: > I think we're getting off topic here folks... > > > Regards, > Igor Escobar > Systems Analyst & Interface Designer > > + http://blog.igorescobar.com > + http://www.igorescobar.com > + @igorescobar (twitter) > > > > > > On Mon, Jun 7, 2010 at 2:51 PM, Ashley Sheridan <ash(a)ashleysheridan.co.uk > > wrote: > On Mon, 2010-06-07 at 10:48 -0700, Michael Shadle wrote: >> >> Oh yeah. I do more than just intval() I make sure they didn't feed me >> anything BUT numeric text first. I do sanity check before type >> forcing :) >> >> I use garbage in garbage out. So I take what is given to me and yes I >> escape if before the db of course as well, and then encode on output. >> >> On Jun 7, 2010, at 10:45 AM, Ashley Sheridan >> <ash(a)ashleysheridan.co.uk> wrote: >> >> > On Mon, 2010-06-07 at 10:38 -0700, Michael Shadle 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> >> >> >> >> >> >> > >> > htmlspecialchars() is really only good for user input that you are >> > outputting to the browser. For inserting data into a database, use >> > mysql_real_escape_string(). I find it's good to think carefully >> > about what sort of data I expect and sanitise it accordingly. If I >> > want a numerical value, I use intval($_GET['var']) or floatval(). >> > For things like small text box elements, regex's work well >> depending >> > on the data. For data from select lists of checkboxes, make sure >> the >> > value given is within a list of pre-determined values you have. >> > Basically, nothing from the user should be trusted at all, ever. >> > >> > As soon as you let go of that trust in the good honesty of people >> > you'll do fine ;) >> > >> > Thanks, >> > Ash >> > http://www.ashleysheridan.co.uk >> > >> > > > Why waste time validating an integer value when intval() will do > that for you? > > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > >
From: Igor Escobar on 7 Jun 2010 14:00 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 > > >
From: Igor Escobar on 7 Jun 2010 14:15
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(a)ashleysheridan.co.uk>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(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 > > > |