Daniel, never mind. I had not put the / in there. That cause it to XSS like you said.
Thanks, Adrian On Mon, Feb 27, 2012 at 4:09 PM, Adrian Crenshaw <[email protected]>wrote: > Ok, for me that does not work. The difference in URL cause it not to run > the script. I also tried: > > http://example.org/test.php?";>script>ALERT xss ; > /script>#7227401544211943741 > > and had the same results, $_SERVER['PHP_SELF'] only held the equivalent > of "/test.php" > > Adrian > > > On Mon, Feb 27, 2012 at 3:54 PM, Frisch, Daniel (JUS) < > [email protected]> wrote: > >> ** >> The attack would look like this: >> >> http://example.org/test.php/";><script>alert('xss');</script> >> >> I was surprised the first time I saw that too :) >> >> Dan >> >> ------------------------------ >> *From:* [email protected] [mailto: >> [email protected]] *On Behalf Of *Adrian Crenshaw >> *Sent:* February 27, 2012 10:49 AM >> >> *To:* PaulDotCom Security Weekly Mailing List >> *Subject:* Re: [Pauldotcom] Is this a secure way to parse logs over the >> web? >> >> Thanks, but can you give me an exampe of how an attacked would use >> $_SERVER['PHP_SELF'] >> for XSS? I did not think PHP_SELF held user controlled input. >> >> Thanks, >> Adrian >> >> On Mon, Feb 27, 2012 at 10:30 AM, Frisch, Daniel (JUS) < >> [email protected]> wrote: >> >>> ** >>> Another thing to note: outputting the $_SERVER['PHP_SELF'] variable >>> without htmlenties also leaves you open to xss (lins 5 & 49). >>> >>> Dan >>> >>> ------------------------------ >>> *From:* [email protected] [mailto: >>> [email protected]] *On Behalf Of *Adrian Crenshaw >>> *Sent:* February 26, 2012 3:30 PM >>> *To:* PaulDotCom Security Weekly Mailing List >>> *Subject:* Re: [Pauldotcom] Is this a secure way to parse logs over the >>> web? >>> >>> Point taken about XSS, I've added some encoding for that since >>> (htmlentities). I'll likely recommend people password protect wherever they >>> put the script. >>> >>> Adrian >>> >>> On Sun, Feb 26, 2012 at 1:21 PM, Dancing Dan <[email protected]>wrote: >>> >>>> Disclaimer: My PHP skills are very rusty so, I may have misunderstood >>>> some of what I saw. Some of what I say may be complete or partial >>>> rubbish.... YMMV >>>> >>>> I'm not sure how much of a difference this would make but, I would >>>> constrain the choices from the Internet to specific items instead of >>>> allowing regexs. It would be good to white list the specific searches you >>>> want to allow and discard anything not on the approved list. >>>> >>>> You could separate the retrieval and searching functions from the >>>> display functions by using a scheduled task on the server to extract the >>>> data to separate files with a subset of data. Not necessarily real time >>>> but, it would gain a little separation and could be a lower privileged >>>> process separate account. This could be especially helpful if you are using >>>> SELinux or other MAC control. >>>> >>>> I would also suggest considering the types of data that could be stored >>>> in the log. It would be a bad thing (TM) for someone to generate a log >>>> event that would cause reflected XSS when viewing the log file in a >>>> browser. My paranoia would cause me to retrieve a text file containing data >>>> that I could view as pure ASCII.... >>>> >>>> Hope this helps.... >>>> >>>> Bart >>>> >>>> On Fri, Feb 24, 2012 at 10:02 AM, Adrian Crenshaw < >>>> [email protected]> wrote: >>>> >>>>> >>>>> Ok, not saying this code is well done, but I had a question about if >>>>> it was possible to do some Regex injection that has really bad >>>>> consequences. I've made a simple little PHP (attached) script as a test to >>>>> look for the top 404s and 403 on a site based on its http log. Since web >>>>> scanners seem to cause a lot of these (causing errors and looking for >>>>> files >>>>> that are not there), it seems like a good way to spot them. The downside, >>>>> I'm pretty much letting the user put anything into the regular expression >>>>> for searching that they want. I'm not using the exec function, but >>>>> preg_match instead, so shell execution should not be an issue as far as I >>>>> know. Assuming I don't care if people know what is in my logs, how secure >>>>> is this? I could also always just password it off. >>>>> >>>>> >>>>> Thanks, >>>>> Adrian >>>>> >>>>> >>>>> -- >>>>> "The ability to quote is a serviceable substitute for wit." ~ W. >>>>> Somerset Maugham >>>>> >>>>> _______________________________________________ >>>>> Pauldotcom mailing list >>>>> [email protected] >>>>> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom >>>>> Main Web Site: http://pauldotcom.com >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pauldotcom mailing list >>>> [email protected] >>>> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom >>>> Main Web Site: http://pauldotcom.com >>>> >>> >>> >>> >>> -- >>> "The ability to quote is a serviceable substitute for wit." ~ W. >>> Somerset Maugham >>> "The ability to Google can be a serviceable substitute for technical >>> knowledge." ~ Adrian D. Crenshaw >>> >>> >>> _______________________________________________ >>> Pauldotcom mailing list >>> [email protected] >>> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom >>> Main Web Site: http://pauldotcom.com >>> >> >> >> >> -- >> "The ability to quote is a serviceable substitute for wit." ~ W. Somerset >> Maugham >> "The ability to Google can be a serviceable substitute for technical >> knowledge." ~ Adrian D. Crenshaw >> >> >> _______________________________________________ >> Pauldotcom mailing list >> [email protected] >> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom >> Main Web Site: http://pauldotcom.com >> > > > > -- > "The ability to quote is a serviceable substitute for wit." ~ W. Somerset > Maugham > "The ability to Google can be a serviceable substitute for technical > knowledge." ~ Adrian D. Crenshaw > > -- "The ability to quote is a serviceable substitute for wit." ~ W. Somerset Maugham "The ability to Google can be a serviceable substitute for technical knowledge." ~ Adrian D. Crenshaw
_______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
