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
