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
_______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
