Ashley Sheridan wrote: > On Wed, 2009-06-10 at 14:40 -0400, Andrew Ballard wrote: >> On Wed, Jun 10, 2009 at 2:26 PM, Ashley >> Sheridan<ash@xxxxxxxxxxxxxxxxxxxx> wrote: >>> On Wed, 2009-06-10 at 14:14 -0400, Eddie Drapkin wrote: >>>> On Wed, Jun 10, 2009 at 2:08 PM, Ashley Sheridan >>>> <ash@xxxxxxxxxxxxxxxxxxxx>wrote: >>>> >>>>> On Wed, 2009-06-10 at 19:03 +0100, Ashley Sheridan wrote: >>>>>> On Wed, 2009-06-10 at 23:17 +0530, Sudheer Satyanarayana wrote: >>>>>>> Ashley Sheridan wrote: >>>>>>>> On Wed, 2009-06-10 at 23:05 +0530, Sudheer Satyanarayana wrote: >>>>>>>> >>>>>>>>>> I've been doing a bit of reading, and I can't really understand why >>>>> XSS >>>>>>>>>> is such an issue. Sure, if a user can insert a <script> tag, what >>>>>>>>>> difference will that make to anyone else, as it is only on their >>>>> own >>>>>>>>>> browser. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> 1. User 1 logs on to the application. Fills up the form with >>>>> malicious >>>>>>>>> JS code in it. The server accepts the input, is stored in the >>>>> database. >>>>>>>>> 2. User 2 logs on to the application. Goes to the view the >>>>> information >>>>>>>>> stored in the database. The JS gets executed on user 2's browser. >>>>> User >>>>>>>>> is attacked by XSS. >>>>>>>>> >>>>>>>>> I hope that clarifies the question. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> It does to a degree. So I shouldn't really worry about it in this >>>>> case, >>>>>>>> as input from one user will never be displayed to any other user. If >>>>> it >>>>>>>> was a forum or something, it would, but the search string is only >>>>> ever >>>>>>>> shown to the user who entered it, and never stored for later display. >>>>>>>> >>>>>>>> >>>>>>> It is easy to slip by. I recall a website was hacked using XSS on the >>>>>>> page the admin views the log entries. Just in case, you or somebody >>>>> else >>>>>>> tries to add the search log feature in the future, keep this at the >>>>> back >>>>>>> of your mind. Having the user to click on a harmful URI is ridiculously >>>>>>> easy. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> With warm regards, >>>>>>> Sudheer. S >>>>>>> Business: http://binaryvibes.co.in, Tech stuff: http://techchorus.net, >>>>> Personal: http://sudheer.net >>>>>>> >>>>>> Yeah, I never realised what a minefield it could be, but I've been doing >>>>>> a lot of reading today! >>>>>> >>>>>> Thanks >>>>>> Ash >>>>>> www.ashleysheridan.co.uk >>>>>> >>>>>> >>>>> So something like this would be acceptable?: >>>>> >>>>> $searchTerms = (isset($_REQUEST['q']))?$_REQUEST['q']:''; >>>>> $searchTerms = htmlentities($searchTerms); >>>>> $dbSearchTerms = mysql_real_escape_string($searchTerms); >>>>> >>>>> Giving me two variables, one for display output to user, the other for >>>>> use in the database? >>>>> >>>>> Thanks >>>>> Ash >>>>> www.ashleysheridan.co.uk >>>>> >>>> >>>> You wouldn't want to insert htmlentity escaped information into your >>>> database. >>>> >>>> This method has always worked well for me: >>>> >>>> Accept input -> db escape -> store; >>>> Retrieve output from db -> html escape -> display; >>>> >>>> So, I'm actually storing (in at least one case that I've seen), human >>>> readable XSS in the database, but I have a consistent approach to escaping >>>> before outputting so that it never gets displayed as XSS and I never >>>> accidentally escape it twice, which depending on a few factors, can have >>>> some pretty ugly results. You wouldn't want to see &amp; anywhere, >>>> would you? Alternatively though, if you are storing it html-escaped in the >>>> database, make sure you don't ever escape it before you output, but I find >>>> that approach a lot less flexible, has problems with searches, isn't easy to >>>> read from the mysql cli console, etc. etc. >>> OK, so I just swapped those last two lines over like so: >>> >>> $searchTerms = (isset($_REQUEST['q']))?trim($_REQUEST['q']):''; >>> $dbSearchTerms = mysql_real_escape_string($searchTerms); >>> $searchTerms = htmlentities($searchTerms); >>> >>> >>> Thanks >>> Ash >>> www.ashleysheridan.co.uk >>> >> I wouldn't self-assign the output of htmlentities to $searchTerms at all. >> >> <?php >> $searchTerms = (isset($_REQUEST['q']))?trim($_REQUEST['q']):''; >> >> // Rather than this: >> $searchTerms = htmlspecialchars($searchTerms); >> echo $searchTerms; >> >> // I prefer this: >> echo htmlspecialchars($searchTerms); >> >> ?> >> >> Escape sequences are not part of the data, so I don't store them. >> >> Andrew >> > > If you'll notice, I'm not storing the escape sequences, I'm displaying > them, hence the $dbSearchTerms variable, which is just for the database, > and outputting the return from the function rather than assigning it to > a variable and then outputting it is probably just down to taste. > > > Thanks > Ash > www.ashleysheridan.co.uk > I normally use and recommend a set of functions that you can use for both cases, display_prep(), store_prep(). You can pass optional args that tell the function whether to htmlentities() or striptags() or both, etc... You can extend them later to do more complex checks or sanitizing. Then you can just use them inline: $searchTerms = (isset($_REQUEST['q']))?trim($_REQUEST['q']):''; echo display_prep($searchTerms); $sql = "SELECT * FROM table WHERE field='" . store_prep($searchTerms) . '"; -- Thanks! -Shawn http://www.spidean.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
