Usually I would support you on this one. In chemistry you always keep your stock "pure" and make any observations or mixtures in clean and other glasses in order to keep it pure.
When it comes to printing an output or hosting it in a variables and then printing it out it is just a matter of taste. On Wed, Jun 10, 2009 at 8:54 PM, Andrew Ballard<aball...@gmail.com> wrote: > On Wed, Jun 10, 2009 at 2:56 PM, Ashley > Sheridan<a...@ashleysheridan.co.uk> wrote: >> On Wed, 2009-06-10 at 14:40 -0400, Andrew Ballard wrote: >>> On Wed, Jun 10, 2009 at 2:26 PM, Ashley >>> Sheridan<a...@ashleysheridan.co.uk> wrote: >>> > On Wed, 2009-06-10 at 14:14 -0400, Eddie Drapkin wrote: >>> >> On Wed, Jun 10, 2009 at 2:08 PM, Ashley Sheridan >>> >> <a...@ashleysheridan.co.uk>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 >> > > You are storing it - in a variable. If I store an escaped value in a > variable, it is a very specifically purposed variable with a very > limited scope. I still prefer to keep a "pure" copy of the variable > somewhere in case I need to use it for a different purpose elsewhere > in the script. > > Andrew > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
