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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
